Update iOS builds to Xcode 26.2 / iOS 26 SDK#441
Conversation
- Update runner from macos-latest-xlarge to macos-26-xlarge for both mobile-build and testflight-on-comment workflows - Update Xcode version from 16.4 to 26.2 (includes iOS 26 SDK) - Resolves ITMS-90725 SDK version warning from App Store Connect requiring iOS 26 SDK by April 28, 2026 Co-Authored-By: unknown <>
🤖 Devin AI EngineerI'll be helping with this pull request! Here's what you should know: ✅ I will automatically:
Note: I can only respond to comments from users who have write access to this repository. ⚙️ Control Options:
|
Deploying maple with
|
| Latest commit: |
dfd3d2c
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://7b1d01fd.maple-ca8.pages.dev |
| Branch Preview URL: | https://devin-1772052170-update-xcod.maple-ca8.pages.dev |
Check warning
Code scanning / CodeQL
Workflow does not contain permissions Medium
Show autofix suggestion
Hide autofix suggestion
Copilot Autofix
AI 2 months ago
In general, the problem is fixed by explicitly setting a permissions: block in the workflow to restrict the GITHUB_TOKEN to the minimal required scopes, instead of relying on potentially broad repository defaults. This can be done at the workflow root (affecting all jobs without their own permissions) or per job.
For this specific workflow, the build-ios job only needs to read repository contents (for actions/checkout and cache key hashing). None of the steps push commits, create releases, or modify issues/PRs. Therefore, the safest and simplest fix is to add a permissions: block at the workflow root level (just under name: or under on:) that sets contents: read. This documents the intended usage and constrains the GITHUB_TOKEN for all current and future jobs unless they override it.
Concretely, in .github/workflows/mobile-build.yml, add:
permissions:
contents: readat the top workflow level, e.g., between name: Mobile App CI and on:. No imports or other changes are required.
| @@ -1,5 +1,8 @@ | ||
| name: Mobile App CI | ||
|
|
||
| permissions: | ||
| contents: read | ||
|
|
||
| on: | ||
| push: | ||
| branches: [ master ] |
Include Xcode version in cache key to avoid reusing stale binaries compiled with the old iOS 18 SDK (Xcode 16.4). Co-Authored-By: unknown <>
Xcode 26.2 no longer ships Swift back-deployment compatibility libraries (swiftCompatibility56, swiftCompatibilityConcurrency, swiftCompatibilityPacks) needed for iOS < 16. Bumping the minimum deployment target to iOS 16.0 resolves the undefined symbol linker errors. Updated in project.yml, project.pbxproj (all 3 build configs), and Podfile. Co-Authored-By: unknown <>
|
@coderabbitai review |
✅ Actions performedReview triggered.
|
|
Important Review skippedBot user detected. To trigger a single review, invoke the You can disable this status message by setting the Use the checkbox below for a quick retry:
📝 WalkthroughWalkthroughTwo GitHub Actions workflow files are updated to target newer macOS and Xcode environments. The macOS runner is changed from Changes
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~3 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 2✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
The Rust/Cargo build process compiles Swift bridge code (via swift-rs) using a deployment target derived from the Rust target triple, which defaults to a very old iOS version. This causes the Swift compiler to emit references to swiftCompatibility back-deployment libraries that Xcode 26.2 no longer ships. Setting IPHONEOS_DEPLOYMENT_TARGET=16.0 in the build environment ensures the Swift bridge code is compiled without these back-deployment references. Co-Authored-By: unknown <>
…loyment target Co-Authored-By: unknown <>
Co-Authored-By: unknown <>
When cargo config overrides ort-sys link metadata, the build script's cargo:rustc-link-lib=c++ is suppressed. This adds explicit libc++ linking to resolve C++ stdlib symbol errors from ONNX Runtime. Co-Authored-By: unknown <>
rustc-link-lib is only valid under [target.<triple>.<links>] sub-tables, not directly under [target.<triple>]. Moved c++ into the existing .onnxruntime sections. Co-Authored-By: unknown <>
|
@TestFlight build |
|
🚀 TestFlight deployment triggered! Check the Actions tab for progress. |
|
❌ TestFlight deployment failed. Check the workflow logs for details. |
Update iOS builds to Xcode 26.2 / iOS 26 SDK
Summary
Addresses the ITMS-90725 App Store Connect warning requiring all iOS/iPadOS apps to be built with the iOS 26 SDK (Xcode 26+) by April 28, 2026.
CI/CD changes (both
mobile-build.ymlandtestflight-on-comment.yml)macos-latest-xlarge→macos-26-xlarge(pinned to macOS 26 Tahoe, which ships with Xcode 26.2)16.4→26.2(latest stable Xcode with iOS 26 SDK)xcode26.2to force a clean rebuild against the new SDKxcode26.2to avoid restoring stale build products from Xcode 16.4IPHONEOS_DEPLOYMENT_TARGET: '16.0'env var to Tauri build steps (belt-and-suspenders for swift-rs)rustc-link-lib = ["c++"]for iOS targets in the generated cargo config (required because the cargo config override for ort-sys suppresses its build script'scargo:rustc-link-lib=c++, leaving C++ stdlib symbols from ONNX Runtime unresolved)iOS deployment target: 13.0 → 16.0
Xcode 26 no longer ships the Swift back-deployment compatibility libraries (
swiftCompatibility56,swiftCompatibilityConcurrency), which are needed when targeting iOS < 16. Without bumping the deployment target, the linker fails with undefined symbols for these libraries.Updated in:
project.pbxproj(all 3 build configurations)project.ymlPodfiletauri.conf.json— added"minimumSystemVersion": "16.0"to the iOS bundle config so Tauri CLI correctly propagates the deployment target to swift-rs during the Cargo buildNo changes to
release.ymlordesktop-build.ymlsince those don't include iOS build jobs.Review & Testing Checklist for Human
macos-26-xlargerunner availability for the org — if your GitHub plan doesn't include macOS 26 large runners, jobs will queue indefinitely. Fallback would bemacos-15-xlargewithxcode-version: '26'.testflight build) to confirm the full pipeline succeeds end-to-end with Xcode 26.2. CI is still running — the ONNX Runtime source build takes ~90 min on cache miss.Notes
release.ymlbuild-taurijob only builds macOS desktop + Linux, not iOS, so it was intentionally left unchanged.Link to Devin run: https://app.devin.ai/sessions/fc1cbb39e9d44ab68e16b78e917d46fe
Requested by: @AnthonyRonning
Summary by CodeRabbit