Submit to the App Store Now, Stay iPhone Duo-Ready

# 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:" <raw log>`). 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 <DerivedData>/Build/Intermediates.noindex/<Pkg>.build/Debug-iphonesimulator/<Target>.build/Objects-normal/arm64/<File>.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/<App>Main` are app-tree code, not covered by the parity gates (`tools/duet scope <path>` confirms). They need the test suite and a build, not `tools/duet verify`.
- Run the repo's commit-confirmation step before committing.