````markdown Agent prompt wrap theme={null}
# Task: make an iOS project build with the iOS 27.0 SDK (Xcode 27.0) without losing its iOS 27.1-SDK code
## Why the build fails
- The code was written against the Xcode 27.1 beta (iOS 27.1 SDK). App Store submission needs Xcode 27.0 final, and its SDK doesn't declare the 27.1 APIs.
- `if #available(iOS 27.1, *)`, `guard #available` and `@available(iOS 27.1, *)` only choose a path **at run time**. The compiler still has to find every symbol in the SDK it builds against, so these checks can't hide a missing API.
- Typical errors (the last one is a knock-on error that the same fix removes):
- `value of type 'GeometryProxy' has no member 'reservedRegions'`
- `cannot find 'ArrangementView' in scope`
- `cannot infer key path type from context` on the following `.map(\.frame)` lines
- iOS 27.1-only APIs seen so far:
- **SwiftUI** (declared in SwiftUICore, re-exported by SwiftUI): `ArrangementView`, `.arrangementViewStyle(_:)`, `.split` / `.overlay` (`SplitArrangementViewStyle`, `OverlayArrangementViewStyle`), `ArrangementViewStyleConfiguration`, `GeometryProxy.reservedRegions(kind:options:layoutDirectionBehavior:)`, `ReservedRegion` (`.occlusion`, `.division`, `QueryOptions.includeInactive`)
- **UIKit**: `UIView.reservedRegions(kind:options:)`, `UIView.ReservedRegion`
## What can tell the two SDKs apart (verified)
- `#if compiler(>=…)` / `#if swift(>=…)` **cannot**. Xcode 27.0 and 27.1 beta ship the identical compiler, Apple Swift 6.4 (swiftlang-6.4.0.34.1).
- The framework module versions **do** differ. Each is the `-user-module-version` in the header of the framework's `.swiftinterface`:
| Module | iOS 27.0 SDK | iOS 27.1 beta SDK | Guard |
|---|---|---|---|
| SwiftUI / SwiftUICore (same version) | 8.0.84.1.104 | 8.0.85.27 | `#if canImport(SwiftUI, _version: 8.0.85)` |
| UIKit | 9127.0.84.1.116 | 9127.0.85.28 | `#if canImport(UIKit, _version: 9127.0.85)` |
## The pattern: compile-time guard outside, run-time guard inside
```swift
#if canImport(SwiftUI, _version: 8.0.85) // iOS 27.1 SDK or newer
if #available(iOS 27.1, *) { newPath } else { fallback }
#else
fallback // built from the 27.0 SDK
#endif
```
Keep the `#available` check. The deployment target doesn't change, and older OSes still need the fallback.
### How to apply it
1. **Function returning a value**:
```swift
private func divisionWidth(in proxy: GeometryProxy) -> CGFloat {
#if canImport(SwiftUI, _version: 8.0.85)
guard #available(iOS 27.1, *) else { return 0 }
return proxy.reservedRegions(kind: .division).map(\.frame)
.filter { $0.height >= $0.width }.map(\.width).max() ?? 0
#else
return 0
#endif
}
```
2. **A `ViewBuilder` body choosing between a new view and a fallback**: move each branch into its own property so the fallback is written once.
```swift
var body: some View {
#if canImport(SwiftUI, _version: 8.0.85)
if #available(iOS 27.1, *) { arrangement } else { fallback }
#else
fallback
#endif
}
#if canImport(SwiftUI, _version: 8.0.85)
@available(iOS 27.1, *)
private var arrangement: some View { ArrangementView { … } secondary: { … } }
// put helpers that only the new path uses here too, so the 27.0 build has no dead code
#endif
private var fallback: some View { … }
```
`#if` is resolved at compile time. Unlike `if #available`, it adds no conditional content and doesn't change view identity at run time.
3. **Types, extensions or stored properties that name new types**: wrap the whole declaration in the same `#if` and keep its `@available`.
4. Explain the guard once, in a doc comment on the main type, and point the other sites to it (e.g. `// The 27.1 SDK guard: see AdaptiveSplit`). Always use exactly the same condition text so the guards are easy to grep and remove later.
### Pitfalls
- If `canImport(M, _version:)` can't read the module's version, it **ignores the version and evaluates to true** (the compiler warns "cannot find user version number"). The 27.0 build is the test: if the guard were ignored, the same errors would come back.
- The compiler keeps only the first 4 parts of a version (8.0.84.1.104 → 8.0.84.1). Use the newer SDK's first three parts as the threshold (`8.0.85`), not the beta's full build number, which a final release could fall below.
- Check against the module the file imports (`SwiftUI`). SwiftUI and SwiftUICore always carry the same version.
- **What ships:** an App Store binary built with the 27.0 SDK always takes the fallback, even on iOS 27.1 devices. Make sure the fallback is acceptable and check it on a device. It comes back automatically once you archive with Xcode 27.1.
- The compiler stops at the first module that fails, so the log may not list every problem. Search the **whole** tree (all packages, extensions/widgets, test targets) for the symbols and for `#available(iOS 27.1`.
## Procedure
1. **Collect the errors** from the failed build/archive log (`grep -n "error:"
`). List the symbols and files, then search the whole source tree as above.
2. **Find the installed Xcodes:** `ls /Applications | grep -i xcode`; `xcode-select -p`.
3. **Find which module declares each missing symbol** in the newer SDK:
```sh
NEW=/Applications/Xcode_27_1_beta.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk
grep -lE "ArrangementView|reservedRegions" \
$NEW/System/Library/Frameworks/*/Modules/*.swiftmodule/arm64-apple-ios-simulator.swiftinterface
```
4. **Compare the compilers and module versions** of both Xcodes:
```sh
for x in Xcode_27_0 Xcode_27_1_beta; do
D=/Applications/$x.app/Contents/Developer
$D/Toolchains/XcodeDefault.xctoolchain/usr/bin/swift --version 2>&1 | head -1
F=$D/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk/System/Library/Frameworks
for m in SwiftUI SwiftUICore UIKit; do
echo "$x $m $(grep -m1 -o 'user-module-version [0-9.]*' $F/$m.framework/Modules/$m.swiftmodule/arm64-apple-ios-simulator.swiftinterface)"
done
done
```
Different compiler versions: `#if compiler(>=…)` also works. Same compiler: use `canImport(_version:)` with the newer SDK's first three version parts.
5. **Apply the guards** at every site.
6. **Verify with both SDKs:**
- Build and run the tests with **Xcode 27.0**. This must succeed.
- Build and run the tests with **Xcode 27.1 beta**, without changing `xcode-select`: set `DEVELOPER_DIR=/Applications/Xcode_27_1_beta.app/Contents/Developer` and use a **separate** derived-data directory.
- Confirm that each build compiled the path you expect: the 27.1 build's object files must reference the new API, the 27.0 build's must not.
```sh
nm -u /Build/Intermediates.noindex/.build/Debug-iphonesimulator/.build/Objects-normal/arm64/.o | grep -c ArrangementView
```
- Delete the temporary derived data afterwards.
7. **Commit.** In the message, say which build takes which path. Once the app ships from the 27.1 SDK, delete the guards (grep for the condition).
## If the repo is a Modaal / Duet project
- Build with the `run_target` MCP tool. It uses the Xcode currently selected (`xcode-select` / Modaal's Xcode settings). Never call `xcodebuild` or `xcodegen` directly.
- Run tests with `scripts/run_tests.sh`. It respects `DEVELOPER_DIR` and `DERIVED_DATA_PATH`, so this compiles the 27.1 branch without touching the selected Xcode:
`DEVELOPER_DIR=/Applications/Xcode_27_1_beta.app/Contents/Developer DERIVED_DATA_PATH=/tmp/dd-27-1 scripts/run_tests.sh`
- The mock generator fingerprints every source file it scans. After editing any Swift file, `run_tests.sh` fails with `content differs from the recorded hash`. Run `scripts/generate-mocks.sh` and commit the `Generated/` files; the diff should be fingerprints only. Never hand-edit `Generated/`.
- Files under `src-ios/Libraries/Main` are app-tree code, not covered by the parity gates (`tools/duet scope ` confirms). They need the test suite and a build, not `tools/duet verify`.
- Run the repo's commit-confirmation step before committing.
````
With a build from Xcode 27.1 beta, the upload in step 1 goes through and step 2 fails: App Store Connect refuses to add the build for review.
The same project built with Xcode 27.0 stops with compile errors, shown in [step 4](#step-4). Steps 1–7 below produce a build from Xcode 27.0 that App Store Connect accepts for review, in which the iPhone Duo code is left out at compile time and kept in the source.
***
Expand each `.xip` and move both apps into `/Applications` under different names. The prompt in [step 5](#step-5) uses `/Applications/Xcode_27_0.app` and `/Applications/Xcode_27_1_beta.app`. If yours are named differently, the agent finds them with `ls /Applications | grep -i xcode`, which is the first thing the prompt tells it to run.
Open each Xcode once and download its iOS platform in **Xcode → Settings… → Components**. [Set up Xcode](/guides/setup-xcode#step-2) covers the first launch and the license prompt.
Simulator runtimes are shared between Xcode installations on the same Mac, which is why Modaal lists both the iOS 27.0 and iOS 27.1 runtimes under each Xcode in the next step.
***
***
***
Open **Signing & TestFlight** and click **Archive & Upload**. The first archive fails:
Building the same project in Xcode 27.0 directly gives the same errors, so the cause is the SDK and not the way Modaal archives:
The errors are of three kinds:
* `Value of type 'GeometryProxy' has no member 'reservedRegions'`
* `Cannot find 'ArrangementView' in scope`
* `Cannot infer key path type from context; consider explicitly specifying a root type`, on the `.map(\.frame)` line after each `reservedRegions` call. It is caused by the first error, and the same fix removes it.
Every error is in code that uses an iOS 27.1 API. The failure dialog's **Fix with agent** button sends the build log to the agent. A request to fix the build errors without further instructions can be met by deleting the iPhone Duo code. Use the prompt in step 5 instead: it tells the agent to keep that code and exclude it from the Xcode 27.0 build.
***
Review the diff and commit it. In a Duet project, include the files under `Generated/`: without their updated fingerprints, `scripts/run_tests.sh` and the CI `codegen` job fail. Then click **Archive & Upload** again.
In App Store Connect, add the build to a new version and submit it for review. Select **Manually release this version** if the approved version should wait until you release it.
The prompt already has the agent check both paths without changing the active Xcode: it builds a second time with `DEVELOPER_DIR` set to Xcode 27.1 beta and a separate derived-data directory, then uses `nm -u` on the object files to confirm that only the Xcode 27.1 build references `ArrangementView`.
***