App Store Minimum SDK Requirement: Xcode Version Calendar

Apple sets a minimum SDK version requirement every year for apps uploaded to App Store Connect, and teams that miss the date see their builds rejected. The rule, effective from April 28, 2026, defines which SDK iOS, iPadOS, tvOS, visionOS, and watchOS apps must be compiled with. This post covers how to track the App Store Xcode SDK requirement calendar, pin the Xcode version in your CI/CD pipeline, and merge it with Google Play's own target-SDK calendar into a single compliance timeline.

💡 Pro Tip: If you want to keep track of Xcode version requirements in one place, put the App Store's SDK requirement and Google Play's target API level requirement on the same calendar (a shared team calendar, for example) — the two take effect in different months of the year, and tracking them separately means one can slip through unnoticed.

Table of Contents

• How the requirement works
• Today's minimum and how to check it
• Rejection scenarios and catching it early
• Pinning the Xcode version in CI/CD
• Third-party libraries tied to an old SDK
• Building a single calendar with Play's target-SDK schedule
• FAQ
• Which Xcode version is required for uploading to the App Store?
• Will I get rejected if I build with an old Xcode?
• How should I pin the Xcode version in CI/CD?
• When does the minimum SDK requirement change each year?
• Update (September 2026)
• Conclusion
• Sources

How the requirement works

Apple announces minimum SDK requirements for apps and games uploaded to App Store Connect via Developer News. According to the February 3, 2026 announcement: "Starting April 28, 2026, apps and games uploaded to App Store Connect need to meet the following minimum requirements." This announcement lays out the SDK requirement that takes effect from that date in a four-item list (iOS and iPadOS share one item).

Here is how the requirement works: some time after Apple releases a new major OS version (iOS 26, for example), compiling with that version's SDK becomes a requirement for uploading to App Store Connect. Developers get a few months between announcement and effective date to transition — time meant for large teams to update CI infrastructure, re-run regression tests with the new SDK, and verify third-party dependency compatibility. Leaving it to the last week is risky even for small teams, since build warnings or API changes after an Xcode update rarely get resolved on the first try.

Apple also links this rule to the canonical "submitting your app" page — so the requirement isn't a one-off announcement, but an official, continuously updated part of the App Store Connect submission process. Watching that page shows the current minimum requirement without searching Developer News for each new wave separately.

You can put this table at the top of your pre-upload checklist for App Store Connect; if your Xcode version doesn't include one of these SDK families, the upload gets rejected.

Today's minimum and how to check it

In practice, this rule is about your Xcode version. As 9to5mac put it while assessing Apple's announcement: "In practice, this also means that developers will need to build their apps using Xcode 26 or later." In other words, check not your OS version, but which SDK family your compiling Xcode contains.

You can see which SDKs are installed from the terminal like this:

1# Show installed Xcode version and build number
2xcodebuild -version
3 
4# Show installed SDK list for a specific platform
5xcodebuild -showsdks | grep -i ios

There's a key distinction worth clarifying here: this requirement covers which SDK the app is built with; it does not automatically raise the app's minimum runtime iOS version (deployment target). Apple's statement, as reported by 9to5mac, is clear: "this does not mean that apps will automatically require iOS 26 or later to run. This decision will still be up to the developer. This change affects only the SDK version used to build apps." So you can keep your deployment target low — the only requirement is that the compiling SDK be current.

One side effect is worth noting: apps compiled with the iOS 26 SDK get the Liquid Glass look applied to native UI components by default; if you don't want that, you can disable it with the UIDesignRequiresCompatibility key — see our Liquid Glass and SwiftUI adaptation post for a detailed adaptation guide.

Rejection scenarios and catching it early

Apple's announcement ties the requirement to the moment of upload: uploads that don't meet the currently effective minimum SDK requirement are not accepted by App Store Connect. In practice, the most common trigger for this is having archived with an old Xcode version — if your CI machine hasn't been updated, or your local dev environment is still on the previous major Xcode version, the xcodebuild archive step can complete without issue, but you'll hit a rejection at the App Store Connect upload step (Transporter or xcodebuild -exportArchive + upload).

That's why it's cheaper to catch this risk at the CI stage, before ever submitting to App Store Connect: a pipeline validation step that compares the Xcode version in use against the required minimum, halting the build on mismatch, gives far faster feedback than waiting days for a rejection.

Pinning the Xcode version in CI/CD

The most robust way to pin the Xcode version is to put a .xcode-version file at the project root and have your CI tools read that file. fastlane's xcversion action supports this as its default behavior — the official docs say: "Defaults to the value specified in the .xcode-version file." But note: the same docs also say the xcode-install gem the action depends on is no longer maintained, and recommend migrating to the xcodes action: "The xcode-install gem, which this action depends on, has been sunset. Please migrate to xcodes."

1# Fastfile — select Xcode version by referencing the .xcode-version file
2lane :build_release do
3  xcversion # called with no parameters: reads the version from .xcode-version
4  build_app(scheme: "MyApp")
5end

On GitHub Actions, you can track which Xcode versions macOS hosted runners include from GitHub's own image repository. GitHub Docs explains it this way: "GitHub maintains our own set of VM images... The software tools included in our GitHub-owned images are updated weekly." All you need to do in your workflow is switch to the correct version with xcode-select:

1# .github/workflows/build.yml
2- name: Select Xcode version
3  run: sudo xcode-select -switch /Applications/Xcode_26.app
4- name: Build
5  run: xcodebuild -scheme MyApp -destination "generic/platform=iOS" archive

For a step-by-step guide to setting up the whole CI/CD pipeline, see iOS CI/CD Pipeline: GitHub Actions and Fastlane; for workflow-based version management on the Xcode Cloud side, see Xcode Cloud pipeline optimization.

The same discipline is needed on local developer machines too — to make sure everyone on the team archives with the same Xcode version, you can quickly list the installed Xcode versions and which one is currently selected by default:

1# Find installed Xcode.app copies
2mdfind "kMDItemCFBundleIdentifier == 'com.apple.dt.Xcode'"
3 
4# Show the path of the currently active (xcode-select selected) Xcode
5xcode-select -p

Turning these two commands into a pre-check script and putting it in a commit hook or the first step of CI lets you catch "it worked on my machine" version mismatches before a PR is even opened.

Third-party libraries tied to an old SDK

Updating your own project's Xcode version isn't enough — the Swift Packages or CocoaPods dependencies in your project also need to build with the current toolchain. If a dependency's own CI is still tested against an old Xcode version, it may produce warnings or errors once you switch SDKs; minimize this risk by reviewing the swift-tools-version in each dependency's Package.swift and its last commit/release date before updating.

Dependencies untouched for a year or two carry particular risk — the maintainer may never have tested against the new SDK. Once you spot one, you have three options: open an issue asking whether it's been tested with the current Xcode, bump swift-tools-version in your own fork and test locally, or switch to an alternative that supports the current toolchain. Whichever you choose, doing this check weeks ahead of the deadline greatly reduces the risk of a surprise build error at upload time.

1# List swift-tools-version for all SPM dependencies in the project
2find . -name "Package.swift" -exec grep -H "swift-tools-version" {} \;

Adding this check as a pre-step in your CI lets you see early which dependency will hold you back during the move to the current Xcode.

Building a single calendar with Play's target-SDK schedule

There's a similar requirement on the Android side too, with different dates. According to Google Play Console Help: "New apps and app updates must target Android 16 (API level 36) or higher to be submitted to Google Play" — this requirement takes effect from August 31, 2026. The same page also defines a grace period: "You will be able to request an extension to November 1, 2026 if you need more time to update your app." For existing apps already live, a lower threshold applies: "Existing apps must target Android 15 (API level 35) or higher to remain available to new users on devices running Android OS higher than your app's target API level."

If you're running a cross-platform team, it makes sense to merge these two calendars into a single compliance timeline; the two stores' effective dates don't land in the same month (in 2026, App Store is April 28, Play is August 31), so keeping them side by side in a single document reduces the risk of missing one of the two. For the detailed workings and deadline strategy on the Google Play side, see our Google Play API 36 deadline guide post.

FAQ

Which Xcode version is required for uploading to the App Store?

From April 28, 2026, iOS and iPadOS apps uploaded to App Store Connect must be compiled with the iOS 26 & iPadOS 26 SDK or later; in practice this means you need to use Xcode 26 or a later version. For tvOS, visionOS, and watchOS apps, each platform's own 26 SDK family applies.

Will I get rejected if I build with an old Xcode?

Yes — uploads that don't meet the currently effective minimum SDK requirement are not accepted by App Store Connect. Adding an Xcode version check to your CI pipeline to catch this risk ahead of time gives you much earlier feedback than getting a rejection from App Store Connect.

How should I pin the Xcode version in CI/CD?

Put a .xcode-version file at the project root; fastlane's xcversion action reads this file by default (migrating to the xcodes action is recommended over xcode-install, whose maintenance has been sunset). On GitHub Actions, you can switch to the Xcode version you want on the hosted runner with xcode-select -switch; GitHub's image repository is updated weekly.

When does the minimum SDK requirement change each year?

There's no official "same month every year" guarantee as a fixed calendar item; in the 2026 cycle, Apple made the announcement on February 3 and set the effective date at April 28, meaning the transition window in between was about three months. So following every Apple Developer News announcement is more reliable than counting on a fixed month.

Update (September 2026)

When this article was first written (May 6, 2026), the rule in effect was the iOS/iPadOS/tvOS/visionOS/watchOS 26 SDK requirement starting April 28, 2026. A new announcement published on Apple Developer News on September 9, 2026 officially revealed the next wave: "Starting April 2027, apps and games uploaded to App Store Connect need to meet the following minimum requirements: iOS and iPadOS apps must be built with the iOS 27 & iPadOS 27 SDK or later..." So the next mandatory transition date is April 2027, with the minimum SDK family being 27.

The same announcement had two more practical details: the Xcode 27 Release Candidate shipped that same day, and it was confirmed that macOS 27 will drop Intel Mac and Rosetta support entirely — "macOS 26 is the final release supporting Intel Mac computers and Rosetta — macOS 27 will be Apple silicon only." When pinning your Xcode version on the CI/CD side, you now also need to add runner architecture (Apple silicon required) to your checklist.

On September 16, 2026, iOS/iPadOS/macOS/tvOS/visionOS/watchOS 27.2 betas and the Xcode 27.2 beta shipped, with Apple emphasizing that testing should move to Xcode 27.2 beta. The same announcement noted the iPhone Duo, going on sale October 23, 2026, ships with iOS 27.1; Xcode 27.1 support for simulating its new poses and orientations shipped as a beta on September 18, 2026 (27A9269). So when updating your CI calendar, watch not only "which Xcode is required" but also "which Xcode can simulate the new hardware" — features needing new device support may push you past the minimum, to intermediate versions like Xcode 27.1/27.2. Track this 27.x wave via our current guide: iOS 27 / Xcode 27 developer guide.

Conclusion

The App Store Xcode SDK requirement calendar isn't a one-time task — Apple opens a new minimum SDK wave with every major OS cycle, and each wave comes with its own announcement-to-effective-date window. The way to make tracking it easier is to start updating your CI the moment the announcement lands, pin the version with single-source-of-truth files like .xcode-version, and keep this calendar in a single document alongside Google Play's own target-SDK requirement.

If you want to go deeper on the topic: iOS CI/CD Pipeline: GitHub Actions and Fastlane, Xcode Cloud pipeline optimization, Google Play API 36 deadline guide, and App Store Connect API automation.

Sources

• Apple Developer News — App Store submissions require new SDKs — the primary source for the April 28, 2026 minimum SDK requirement (iOS/iPadOS/tvOS/visionOS/watchOS 26 SDK).
• Apple Developer News — April 2027 SDK requirement announcement — dated September 9, 2026, the official source announcing the 27 SDK family requirement and the Xcode 27 RC.
• Apple Developer — Submitting your app — the canonical reference page for App Store Connect submission requirements.
• fastlane docs — xcversion action — the .xcode-version file reading behavior and the note on migrating to the xcodes action.
• GitHub Docs — About GitHub-hosted runners — hosted runner image update frequency.
• Google Play Console Help — Target API level requirements — the Android 16 (API 36) requirement and extension date.
• 9to5mac — Apple to update minimum SDK requirements — 9to5mac's assessment of Apple's announcement on the Xcode version vs. deployment target distinction.