Since 28 April 2026, every app uploaded to App Store Connect must be built with Xcode 26 or later using the iOS 26, iPadOS 26, tvOS 26, visionOS 26 or watchOS 26 SDK, and from 9 September 2026 iOS and iPadOS apps must also target iOS 13 or later. A build made with an older Xcode is rejected at upload, before review, so the requirement shows up as a failed delivery rather than a rejection email. The rebuild is usually straightforward, but it pulls in the iOS 26 design changes, new compiler warnings and a newer macOS for the build machine, which is where most of the real work sits.
Short answer
Apple's upcoming requirements page lists two dates that matter this year. From 28 April 2026, uploads must be built with Xcode 26 or later against a 26 SDK. From 9 September 2026, iOS and iPadOS apps must have a deployment target of iOS 13 or later. Neither rule affects apps already live on the App Store; both apply to every new build you upload, including urgent bug fixes. Upgrade the build machine and CI to Xcode 26, rebuild, fix what the new SDK changes, test the app on iOS 26 and on the oldest iOS you support, then submit.
| Date | Requirement | What breaks if you ignore it |
|---|---|---|
| 31 January 2026 | Answer the updated age rating questions in App Store Connect | Interruptions when submitting updates |
| 28 April 2026 | Build with Xcode 26+ and a 26 SDK | Uploads are rejected by App Store Connect |
| 9 September 2026 | iOS and iPadOS apps must target iOS 13 or later | Uploads with an older deployment target are rejected |
What the requirement does and does not change
The SDK requirement concerns how a build is made, not which devices it runs on. You can build with Xcode 26 and still support older iOS versions: according to Apple's Xcode system requirements, every Xcode 26 release supports iOS deployment targets from iOS 15 upward. Your users on older iPhones keep receiving updates as long as your deployment target covers them.
What does change is the toolchain. Xcode 26 ships newer Swift versions, from Swift 6.2 in the first release to Swift 6.3 in Xcode 26.4 and later, new warnings, and SDK behaviour that applies when your app is linked against the 26 SDK. Code that compiled cleanly under Xcode 16 may produce new warnings or, in a few cases, errors.
The build machine changes too. Apple lists macOS Sequoia 15.6 as the minimum for Xcode 26 through 26.3, and macOS Tahoe 26.2 for Xcode 26.4.1 and later. A CI runner or a developer laptop on an older macOS cannot run the required Xcode, so the upgrade often starts with the operating system.
Where the work actually is
For most teams, three areas take the time.
The iOS 26 design
Apps linked against the iOS 26 SDK pick up the new system design for standard controls, navigation bars, tab bars and sheets. Screens built from standard UIKit or SwiftUI components usually adapt well. Heavily customised navigation, hard-coded colours behind system bars, and custom tab bars are where layout surprises appear. Apple provides an Info.plist key, UIDesignRequiresCompatibility, that lets an app built with the new SDK keep the earlier appearance while you adapt; check its documentation for how long it remains supported before relying on it as more than a bridge.
Dependencies
Every third-party SDK, CocoaPod, Swift package and binary framework is now compiled or linked with the new toolchain. Most maintained dependencies have released Xcode 26-compatible versions; abandoned ones may not build at all, or may produce warnings you cannot fix in code you do not own. Cross-platform frameworks such as React Native, Flutter and Unity need a release that supports Xcode 26, and their native plugins need checking individually.
New compiler diagnostics
Each Swift release tightens its checks, and the Swift 6 language mode in particular brings strict concurrency checking that reports data races the compiler can prove are possible. Projects that adopt the Swift 6 mode see these as errors; projects that stay in Swift 5 mode see many as warnings. Treat them as a to-do list rather than noise. A warning about a mutable value shared across tasks is often a real, intermittent crash that users have been reporting as "random".
Privacy manifests and third-party SDKs
Since 1 May 2024, Apple has required privacy manifests that declare approved reasons for required-reason APIs, including those used by third-party SDKs. Updating dependencies for Xcode 26 usually brings newer SDK versions with their own manifests, which can change what your app declares. Check the aggregated privacy report Xcode generates for the archive, and make sure it still matches the privacy details you give in App Store Connect.
Build infrastructure
CI images, signing setups, fastlane or Xcode Cloud workflows and any scripts that parse Xcode output need updating. Teams that pin a specific Xcode version in CI should update the pin and confirm the runner's macOS is new enough.
A safe upgrade sequence
- Upgrade a branch, not main. Install Xcode 26 alongside the current version, open the project on a branch, and let Xcode suggest settings updates. Review each one rather than accepting them all.
- Update dependencies first. Bump packages and pods to versions that support Xcode 26 before fixing your own warnings, so you do not fix the same issue twice.
- Build and triage warnings. Separate new deprecations, which can wait, from new errors and concurrency warnings, which often point at real bugs.
- Test on iOS 26 and on your oldest supported iOS. The SDK change affects behaviour on new systems; your deployment target decides what still has to work on old ones.
- Review the visual changes screen by screen, especially navigation, tab bars, sheets and anything drawn behind system chrome.
- Update CI and archive from it. The upload that matters is the one CI produces, so confirm the archive step uses Xcode 26.
- Upload to TestFlight first. A successful TestFlight upload confirms App Store Connect accepts the build before you are under release pressure.
The 9 September deployment target rule
The second requirement is smaller but easy to miss. From 9 September 2026, iOS and iPadOS apps uploaded to App Store Connect must target iOS 13 or later. Few actively maintained apps still support iOS 12 or earlier, but older projects, enterprise apps moving to the store and long-lived apps that never raised their minimum can trip over it.
Raising the deployment target is also a chance to remove compatibility code. Branches written for very old iOS versions often hide outdated APIs and security workarounds, and deleting them reduces both maintenance and attack surface.
Why a rebuild is a good moment for a security review
A forced rebuild touches every dependency and every build setting, which makes it the cheapest moment to check what the app actually contains. Three things tend to surface.
Outdated dependencies. Updating everything for Xcode 26 shows which libraries have been quietly abandoned. An abandoned SDK is a compatibility risk now and a security risk later.
Settings inherited from old templates. App Transport Security exceptions, broad entitlements, debug flags and logging left on in release builds often date from an early prototype. The OWASP Mobile Application Security Verification Standard treats network security, storage and platform interaction as core control groups, and old exceptions in those areas are common.
Secrets in the bundle. API keys compiled into the app, configuration files with credentials and leftover test endpoints are easy to spot once you look at the built IPA rather than the source.
A scanner like PTKD.com analyses the built IPA and reports issues such as exposed secrets, App Transport Security exceptions and risky third-party components by severity, mapped to OWASP MASVS. It does not rebuild the app or decide whether App Store Connect accepts a build; that depends on the Xcode and SDK used. It answers a different question: what the rebuilt binary exposes.
Common upload problems after the switch
"This build was made with an unsupported SDK"
The archive was produced by an older Xcode, usually because CI still runs the previous version while a developer's machine runs Xcode 26. Check which Xcode the archive step uses and confirm with the build's metadata in App Store Connect.
Builds that run locally but fail in CI
Usually a macOS or Xcode version mismatch on the runner, or a cached dependency built with the old toolchain. Clear derived data and package caches on CI and pin the runner image explicitly.
A dependency that will not compile
Check for a newer release first. If none exists, look for a maintained fork or replace the library. Patching vendored code locally works as a stopgap, but every future update becomes manual.
Signing and provisioning errors after the upgrade
A new Xcode sometimes surfaces signing problems that older versions tolerated: expired certificates, provisioning profiles missing a capability the app now declares, or entitlements that no longer match the App ID. Read the full error in the Organizer rather than the summary, regenerate the affected profile in the developer portal, and confirm that automatic signing on developer machines and manual signing on CI point at the same team and bundle identifier.
An app extension or widget that fails validation
Extensions, widgets and watch apps are separate targets with their own deployment targets and settings. A main app that builds cleanly can still fail upload because one extension was left on an old deployment target or links an outdated framework. Check every target, not just the app.
Layout changes nobody expected
Usually custom navigation or tab bars interacting with the new system design. Compare screens side by side on iOS 26 and an earlier iOS, fix the custom components, and use the compatibility key only as a temporary bridge.
Planning for next year
Apple has raised the minimum Xcode and SDK on a roughly annual rhythm, and the upcoming requirements page is where each new date appears. Teams that upgrade Xcode within a few months of each major release spend a day or two on it; teams that wait until the deadline spend a frantic week with a blocked release queue. Put the next upgrade in the plan as soon as a new Xcode leaves beta, and keep a test device on the newest iOS so behaviour changes are seen early. Subscribing to the Apple Developer news feed is the simplest way to see each new requirement the day it is announced rather than the week it takes effect.
If your app comes from a cross-platform framework or app builder
React Native, Flutter, Unity and app builders each need a release that supports Xcode 26 before your app can be rebuilt. Check the framework's release notes for Xcode 26 support, upgrade the framework before touching your own code, and then check each native plugin. If a builder platform produces your iOS build, confirm that its pipeline uses Xcode 26; the upload requirement applies to your app whoever runs the build.
What to take away
- Since 28 April 2026, App Store Connect only accepts builds made with Xcode 26 or later against a 26 SDK, and older builds fail at upload.
- From 9 September 2026, iOS and iPadOS apps must target iOS 13 or later; Xcode 26 itself supports deployment targets from iOS 15.
- The work is usually in the iOS 26 design changes, dependency updates and build machines that need a newer macOS, not in the rebuild itself.
- Upgrade on a branch, update dependencies first, test on iOS 26 and your oldest supported iOS, and confirm CI archives with Xcode 26 before a release is urgent.
- Use the rebuild to review what the binary contains, with a scan from a tool such as PTKD.com alongside your own testing.
