Apple requires Xcode 26 for uploads: what it means for your app (2026)

By Sigsten Gustavii· 27 October 2026· 8 min read

Apple's Xcode 26 requirement means that every new build you upload to App Store Connect, whether a new app or an update, must be made with Xcode 26 or later and an iOS 26 SDK or newer.

Apple raises this bar every year or so, and each time it catches people with older Macs, older projects or tools built on older toolchains. This guide explains what the 2026 rule says, from Apple's own upcoming requirements page, what it does and does not affect, which Macs can run the Xcode you need, and what your options are if yours cannot.

What the rule says

According to Apple, since April 28, 2026, apps uploaded to App Store Connect must be built with Xcode 26 or later using an SDK for iOS 26, iPadOS 26, tvOS 26, visionOS 26 or watchOS 26. It replaced the previous rule, Xcode 15 or later, which applied from April 29, 2024.

A second rule arrived on September 9, 2026: iOS and iPadOS apps uploaded to App Store Connect must target iOS 13 or later. Apple is explicit that this is about the deployment target, not the build tools.

SDK and deployment target: two different numbers

These two rules are easy to mix up, and they control different things:

• The SDK is the version of Apple's frameworks your app is built against, and it comes with Xcode. The 2026 rule requires iOS 26 or newer.
• The deployment target is the oldest iOS your app will install on. The September 2026 rule says it cannot be below iOS 13.

So an app can be built with the newest SDK and still run on older iPhones, as long as its deployment target is iOS 13 or later and its code checks for features that older versions lack. Raising the deployment target is a choice you make; raising the SDK is one Apple makes for you.

What it does not affect

• Apps already on the App Store stay there and keep working. The rule applies to new uploads.
• Apps you install on your own iPhone for testing are not uploaded to App Store Connect, so the upload rule does not apply to them.
• The iOS versions your app supports are set by the deployment target, not by the Xcode version.

But the next time you update an app, the update must meet the rule. An app that has not been touched for two years will need its project opened in a current Xcode before you can ship even a small fix, so it is worth doing that move calmly, before an urgent bug forces it on you.

Which Macs can run the Xcode you need

If your Mac cannot run macOS Sequoia 15.6 or later, it cannot run any Xcode that uploads today. Apple's list of Macs that run macOS Tahoe covers Apple silicon Macs from the M1 models of 2020 onward and a few 2019 and 2020 Intel models. Our post on the cheapest Mac for iOS development goes through current prices.

What to check when you move to Xcode 26 or 27

1. Open the project and build it. New SDKs bring new warnings and occasionally errors where APIs changed.
2. Check the deployment target is iOS 13 or later; raise it if your code no longer needs older versions.
3. Run the app on the Simulator and a real iPhone. A new SDK can change how standard controls look and behave, especially since the iOS 26 design update.
4. Update dependencies that ship their own compiled code; old ones may not build with the new SDK.
5. Check your app icon in Apple's newer appearances; see iOS app icon sizes.
6. Upload to TestFlight before release, so a build problem shows up before your release day.

If you cannot run Xcode 26

What it means for you, by situation

The common thread is that an app is never quite finished with its tools. Even with no new features, an app that is updated once a year will usually meet a new Xcode along the way.

Why Apple does this

Each new SDK brings Apple's newest frameworks, privacy rules and design. Requiring recent tools keeps the App Store's apps up to date with them, and lets Apple retire old behaviour. The trade-off is that developers have to keep their tools moving, roughly once a year, and plan for an afternoon of fixes each time. Apple's page lists earlier rounds too: Xcode 14.1 from April 25, 2023, and Xcode 15 from April 29, 2024.

How Borel handles Apple's toolchain, step by step

If you build with Borel, the toolchain is Borel's job. Its Mac was running macOS 27, Xcode 27 and iOS 27 when last measured on October 17, 2026, so every build already meets the upload rule.

1. Describe your app to Borel; it writes it in Swift and SwiftUI.
2. Xcode builds it on Borel's Mac with the current SDK, and the app targets iOS 17 or later, well above Apple's iOS 13 floor.
3. Try it on the live iPhone in your browser and on your own iPhone with Borel Companion on Pro.
4. Publish with Pro and Apple's Developer Program: Xcode archives, signs and uploads the app on Borel's Mac. That build is free.
5. Update it later by asking for changes; each new build uses whatever Xcode Borel's Mac runs then, so you never install or upgrade Xcode yourself.

Rebuild my habit tracker for the App Store: keep the data model, check every screen looks right on the current iOS, and make sure the icon works in dark mode.

For the rest of the route, see publishing to the App Store without a Mac, and the submission checklist for everything Apple checks besides the build.

The bottom line

Since April 28, 2026, App Store uploads need Xcode 26 or later and an iOS 26 SDK, and since September 9, 2026 apps must target iOS 13 or later. Existing apps keep working, but every update has to meet the rule, which means a Mac on macOS Sequoia 15.6 or later, or a service that builds for you. If you would rather not track Apple's toolchain at all, build on Borel: its Mac keeps current, and you never install Xcode.

I think keeping up with Apple's toolchain is the least fun part of making apps, which is why Borel's Mac carries it for you. If you hit a version error elsewhere, tell me what it said.

– Sigsten

Make your iPhone app in Borel

Describe the app you want and see its first screens before you pay anything.