The workflow

  1. 01Which versions must stay separate?
  2. 02What did the test contain?
  3. 03What did the reviewer report?
  4. 04What happened after editing the fixtures?

Guard a symbol at the OS version where it becomes available, then verify the older-system fallback and any separate runtime readiness requirements. This article ran the published availability reviewer against synthetic files, but did not compile or execute iOS 27 APIs because the installed toolchain is Xcode 26.6.

Which versions must stay separate?

A toolchain version, the SDK it contains, and an application's minimum deployment target answer different questions. The repository's compatibility matrix distinguishes them because a newly installed SDK should not automatically remove support for older devices. A guard must describe the API being used, not simply repeat the newest version number in the project documentation.

There are two useful review failures to look for. An unguarded newer API can prevent supporting an older deployment target. An unnecessarily restrictive guard can send supported devices down an older fallback path. The latter may be invisible if every local test runs on the newest OS.

Apple's Private Cloud Compute integration guide supplies a concrete iOS 27 example and discusses falling back on earlier systems. Treat that documentation as the API authority. The table below is instead a record of what this review tool detected.

What did the test contain?

I created four separate Swift source fixtures. Card.swift uses glassEffect() inside an iOS 27 guard. Three additional files contain bare symbol references for PrivateCloudComputeLanguageModel, DynamicProfile, and OCRTool. The latter files are explicitly labeled lexical fixtures: they exercise the reviewer's matching rules and are not compiling examples of those APIs.

The distinction is especially important for nested types or APIs that require framework-specific setup. A token appearing in a source file is enough to test a lexical check, but not enough to teach correct API usage. I have kept the synthetic source downloadable so a reader can see exactly what was tested.

I called check_availability_guards through the published server's stdio MCP connection, passing the fixture directory. The before response reported three blocker findings and one serious finding across four files.

What did the reviewer report?

Fixture location Matched item Reported result
Cloud.swift:2 PrivateCloudComputeLanguageModel missing iOS 27 guard
Profile.swift:2 DynamicProfile missing iOS 27 guard
Tools.swift:2 OCRTool missing iOS 27 guard
Card.swift:6 glassEffect() iOS 27 guard stricter than the reviewer's iOS 26 entry

This table is a reproducible analyzer result, not a complete iOS 27 availability index. Before adopting any symbol, check its current Apple declaration, enclosing type, platform, and minor-version requirements. A short maintained pattern table cannot enumerate every API in an SDK.

For the card, the proposed change is deliberately small:

if #available(iOS 26.0, *) {
    Text("Reading").glassEffect()
} else {
    Text("Reading")
}

The corresponding Apple API reference remains the source for the modifier's contract. The fallback here preserves readable content; a production design may require more deliberate visual treatment.

What happened after editing the fixtures?

I changed the card guard from 27.0 to 26.0. For the lexical iOS 27 fixtures, I placed the references inside functions annotated with @available(iOS 27.0, *). These changes test the rule's response to the relevant annotation; they do not turn placeholder references into complete Foundation Models features.

The same tool then returned zero findings across the four files. The after response preserves that result. The before and after sources are included beside the JSON, allowing another reviewer to check that the experiment changed guards rather than removing the matched names entirely.

The clean result answers a narrow question: did the tool stop flagging these patterns? It does not answer whether the surrounding app compiles, whether every call site is guarded, or whether a selected model is available at runtime.

Which checks belong in the real review?

First identify the application's oldest supported OS. Then inspect the introduction version of each newly adopted symbol. Check the scope of the guard around the use, including helper methods and initializers; finding an unrelated guard elsewhere in a file is insufficient.

Next inspect the fallback as product behavior. Does the same action remain possible? Is disabled functionality explained? Does a view still have meaningful content? An empty branch can be syntactically acceptable while leaving an older device with a broken experience.

For model-backed features, separate API presence from model readiness. Apple's generation guide documents checking availability before starting a session. An OS-version check alone does not establish that the model can answer a request.

Limits

The reviewer uses source heuristics and can miss scope, target settings, and minor-version distinctions. It is not an SDK parser or a compiler. This draft demonstrates its current behavior, including that limitation, and does not certify iOS 27 compatibility. Runtime fallback testing on supported OS versions is still required. Never replace a compiler diagnostic with a more convenient zero-findings report.

Last verified

September 16, 2026, local time. Published ios-agent-mcp 2.7.0; Node.js 24.15.0; host Xcode 26.6 build 17F113. No Xcode 27 build performed. Repository sources: docs/compatibility-matrix.md and docs/apple/ios-27-release-verification.md.

Example project: ios-agent-skill.