⬆️ Bump deployment targets to iOS 15 / macOS 12 / tvOS 15 / watchOS 9

[Jidoml]

Why

Xcode 27 raised the minimum supported deployment target. Our current values sit below its floor, so xcodebuild does not warn — it refuses to load the project at all:

error: The iOS Simulator deployment target 'IPHONEOS_DEPLOYMENT_TARGET' is set to 12.0,
       but the range of supported deployment target versions is 15.0 to 27.0.x.

Worth knowing: Xcode 26 does not force this. The current targets sit exactly on its floor, so the forcing function is Xcode 27 specifically — Xcode 26 builds the old values quite happily.

This branch also carries an unrelated CI fix. The first run here went red for reasons that had nothing to do with deployment targets: macos-latest drifted and no longer ships the iOS/tvOS/watchOS 26.1 simulator runtimes that the pinned Xcode 26.1.1 needed, nor the iPhone 16 Pro / Apple Watch Ultra 2 (49mm) devices the destinations named. The 🔧 Repair CI after macos-latest runner image drift commit moves the pin to Xcode 26.6 and the destinations to devices that exist. It is a separate concern and can be split out if you would rather it landed on its own.

What changed

Platform	Before	After	Xcode 27 floor
iOS	12.0	15.0	15.0
macOS	10.13	12.0	12.0
tvOS	12.0	15.0	15.0
watchOS	5.0	9.0	9.0

One trap worth flagging: the intuitive "iOS 15 era" mapping for watchOS would be 8.0, but Xcode 27's watchOS floor is 9.0 — watchOS 8 fails identically to watchOS 5. Every value above sits exactly on the floor, none is needlessly higher.

This also bumps the ACKategoriesExample target, which carried its own 13.2 override that would otherwise have sat below the new project floor.

Verification

Locally on Xcode 27.0 (27A5252f):

Check	Before	After
xcodebuild build × iOS / macOS / tvOS / watchOS	exit 65 ×4	exit 0 ×4
xcodebuild test iOS	—	83 passed, 0 failed
xcodebuild test macOS	—	63 passed, 0 failed
swift build / swift test	exit 0	exit 0 / 63 passed
swiftlint	exit 0	exit 0

tvOS and watchOS are build-verified only — those simulator runtimes aren't installed locally, so their test runs are left to CI, which covers all four platforms.

Note that swift build passes even before this change: SPM does not enforce the SDK floor, only xcodebuild and Carthage do. SPM-only consumers never saw the failure.

Deliberately not in this PR

• No version bump. Per @olejnjak we hold the version and cut a major once the whole cleanup lands, so MARKETING_VERSION is untouched and entries just accumulate under ## Next.
• The availability cleanup. The new floor makes 52 @available attributes and 5 #available runtime branches permanently true. That is 🔥 Remove availability checks made dead by the iOS 15 floor #159, stacked on this branch, so this one stays a pure config change and can be reverted on its own.
• Module pruning — yours.
• CI stays on Xcode 26.x. Moving it to Xcode 27 would mean the xcode-27 runner label, which is arm64-only and still in public preview tracking betas. Worth revisiting once that image goes GA. Until then, be aware this floor is not guarded by CI at all — Xcode 26.6 accepts iOS 12 / macOS 10.13 just as happily, so nothing would stop the targets being lowered again by accident.
• The README install snippets still pin ~> 6.15.0 / .upToNextMajor(from: "6.15.0"), which now reads oddly directly under the new Requirements block, since 6.15.0 does not require iOS 15. Left alone on purpose — they can only be corrected once the next version actually exists.
• The macOS CI destination is still platform=OS X,arch=x86_64 while the runner is arm64, so that slice is validated under Rosetta. Pre-existing; I did not want to widen the CI fix further. Worth a follow-up.

Note for whoever cuts the next release

This is source-breaking: every consumer below iOS 15 / macOS 12 / tvOS 15 / watchOS 9 stops resolving the package. No version is cut here, per @olejnjak — just make sure that eventual tag is 7.0.0 and not a 6.x, otherwise anyone on .upToNextMajor(from: "6.x") silently picks up a package they cannot build, with no opt-out.

[Copilot]

🟡 Changes recommended

The README change includes an incorrect UIKit symbol reference (UIControl.primaryActionTriggered) that should be corrected to avoid misleading users.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Pull request overview

Updates the project/package configuration to align minimum supported OS deployment targets with Xcode 27’s enforced floor, and adjusts GitHub Actions CI to keep building successfully after macos-latest image drift.

Changes:

• Raise deployment targets across SPM (Package.swift) and the Xcode project (project.pbxproj) to iOS 15 / macOS 12 / tvOS 15 / watchOS 9.
• Repair CI by pinning Xcode 26.6 and updating simulator destinations in the test workflow.
• Document the new requirements and record the change in CHANGELOG.md.

File summaries

File	Description
README.md	Adds a Requirements section reflecting new minimum OS versions.
Package.swift	Bumps SPM platform deployment targets to the new floors.
CHANGELOG.md	Adds “Next” entries for the deployment-target bump and CI repair.
ACKategories.xcodeproj/project.pbxproj	Updates Xcode project deployment targets, including the example target override.
.github/workflows/tests.yml	Pins Xcode 26.6 and refreshes iOS/watchOS/tvOS simulator destinations.
.github/workflows/docbuild.yml	Pins Xcode 26.6 for DocC builds.
.github/workflows/build.yml	Pins Xcode 26.6 for Carthage/SPM build workflows.

Review details

• Files reviewed: 7/7 changed files
• Comments generated: 1
• Review effort level: Lite

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Copilot]

🟢 Approval recommended

The changes are coherent, narrowly scoped to configuration/CI, and consistently apply the new Xcode 27 deployment-target floors across the documented integration surfaces.

Review details

Suppressed comments (3)

Previously missed (3) — in code that hasn't changed since the last review.

.github/workflows/build.yml:10

• This workflow duplicates the same hardcoded DEVELOPER_DIR pin as other workflows; when the runner image drifts, it requires coordinated edits across files. Centralizing the Xcode version (reusable workflow input or composite action) would reduce the chance of inconsistent pins and CI breakage.
  .github/workflows/docbuild.yml:18
• Like the other workflows, this uses a hardcoded DEVELOPER_DIR path. To make CI more resilient to macos-latest image changes, consider selecting Xcode via a setup action/step instead of relying on /Applications/Xcode_*.app being present.
  .github/workflows/tests.yml:6
• Hardcoding DEVELOPER_DIR to an absolute Xcode app path is brittle on macos-latest (runner image drift can remove/rename that path again). Consider switching to a dedicated Xcode setup step (e.g., maxim-lobanov/setup-xcode) and/or centralizing the Xcode version in a single reusable workflow input to avoid having to update multiple workflows in lockstep.

• Files reviewed: 7/7 changed files
• Comments generated: 0 new
• Review effort level: Lite