Before iOS uploads, verify Xcode 26 and the iOS 13 deployment target

A mobile app can pass its own release checklist and still be built with an older toolchain or target an operating system that no longer meets the App Store upload floor. Apple now has two separate checks in effect: the build must use the required Xcode and platform SDK, and iOS or iPadOS apps must set a high enough minimum deployment target.

If you are preparing an iOS submission, verify both against the archive you will upload. A green simulator run or a recent build on your laptop does not establish which toolchain produced a cloud-built archive. Check the actual release artifact and keep the evidence with the build.

The two requirements are independentCopy Anchor Link

Apple’s current upload requirements list these dates:

• Since April 28, 2026, apps uploaded to App Store Connect must be built with Xcode 26 or later and use an SDK for iOS 26, iPadOS 26, tvOS 26, visionOS 26, or watchOS 26.
• Since September 9, 2026, iOS and iPadOS apps uploaded to App Store Connect must target iOS 13 or later.

Both dates have passed. Treat the requirements as current checks for a new app or an update, rather than future work to schedule later.

They solve different problems. The Xcode and SDK rule concerns the tools used to compile the submitted app. The deployment target is the oldest operating system version the app declares it can run on. An app can use the required SDK while declaring an older minimum target; it can also declare a new minimum target while being built with an older toolchain. Verify each one separately.

Verify the toolchain that built the archiveCopy Anchor Link

Start with the release archive, not a developer’s memory of which Xcode was installed. Record the Xcode version, platform SDK, build number, and source revision beside the artifact. The record should identify the actual environment that ran the archive build.

For a build made on a Mac you control, inspect the selected Xcode installation and available SDKs in that build environment. For example:

xcodebuild -version
xcodebuild -showsdks

These commands describe the local toolchain. They are useful only when run in the environment that creates the archive. If the app was built by a hosted runner or another managed service, inspect that build’s logs and configuration instead. Do not infer the Xcode version from the service name, the project’s source files, or a successful build from last month.

For an iOS app, confirm the archive build used Xcode 26 or later and an iOS 26 SDK. If the app also ships to another Apple platform, check the relevant SDK requirement for that platform: Apple’s current page names iPadOS 26, tvOS 26, visionOS 26, and watchOS 26 as well.

Keep the evidence tied to one release candidate. A useful record includes:

• The commit or immutable source revision.
• The app version and build number.
• The Xcode version and SDK shown in the build environment.
• The build profile or configuration used.
• The archive file that was uploaded.
• The person or job that produced and submitted it.

This makes a later discrepancy easier to resolve. If a build machine changed between the last successful archive and today’s submission, the recorded version tells you whether to inspect the build environment before debugging app code.

Check the minimum deployment targetCopy Anchor Link

Next, inspect the app’s iOS deployment target. In an Xcode project, check the target’s deployment information and build settings for every configuration used by the release. If the project generates native files during a build, inspect the generated project or the final build log too; the value in a source template may not be the value used by the archived target.

For an iOS or iPadOS upload, the declared minimum must be iOS 13 or later. You can choose a higher minimum, but make that a deliberate product decision. Raising it can reduce the number of older devices that can install or update the app. Before changing it, estimate which users would lose support and check whether your analytics or support reports show meaningful use on those systems.

The upload floor does not mean every feature works on every supported operating system without checks. If the app uses APIs introduced after its minimum target, guard those calls and provide a sensible fallback. Test the oldest operating system version you still intend to support, not only the newest simulator. A deployment target is a compatibility promise; it does not replace runtime testing.

If you support several targets, do not assume they all share one setting. Check the app target, extensions, and any separately submitted app targets that contribute to the release. Resolve conflicting values before archiving so the setting you validated is the one used by the uploaded build.

A pre-upload sequence for a small teamCopy Anchor Link

Use a short release sequence that makes the checks repeatable:

1. Choose the source revision. Freeze the code and configuration for the release candidate. Record the commit before starting the archive.
2. Build in the intended release environment. Use the environment that will produce the submitted archive. Save its Xcode and SDK details.
3. Inspect the deployment target. Confirm the release configuration declares iOS 13 or later for iOS and iPadOS apps. Review any separate extension targets.
4. Install the archive-derived build. Test launch, sign-in, the primary flow, permissions, and update behavior on devices or simulators that match the supported range.
5. Upload that exact archive. Do not rebuild from an unrecorded checkout after validation. If you must rebuild, preserve the new evidence and repeat the checks.
6. Keep the submission record. Store the archive identifier, build number, toolchain details, and upload outcome together.

The order matters because the app’s project settings and the actual archive can diverge. A checklist that only records the intended Xcode version or the value in a source template can create false confidence. The release record should answer: which revision was built, which toolchain built it, which minimum target was compiled, and which archive went to App Store Connect?

If an upload check failsCopy Anchor Link

First identify which requirement is failing. If the error concerns the SDK or Xcode version, correct the release build environment and create a new archive with the required toolchain. If it concerns the minimum target, update the relevant target configuration, rebuild, and test the compatibility change. Do not change both settings blindly; a focused fix makes the result easier to verify.

If you use a managed build environment and cannot confirm its Xcode or SDK from the build record, pause that submission and get the version from the provider’s current documentation or build logs. Do not claim support based on an assumption. The question to resolve is specific: what Xcode and SDK produced this archive?

For the broader store-readiness work, use the AI-built app submission checklist. If you are preparing an Android release too, check the separate Google Play API 36 deadline and the closed-testing requirement; Apple’s toolchain and deployment-target rules do not replace Google Play’s requirements.

A concise release gateCopy Anchor Link

Before submitting, verify two independent facts from the release candidate:

• Build tools: Xcode 26 or later and the applicable platform SDK are shown in the environment that created the archive.
• Compatibility floor: The iOS or iPadOS deployment target is iOS 13 or later, unless you intentionally choose a higher minimum.
• Traceability: The uploaded archive matches the recorded source revision, build number, and toolchain.
• Testing: The app still works on the oldest operating system version you plan to support.
• Recovery: If the archive was built with the wrong toolchain or target, create a corrected archive and repeat the checks before upload.

Apple’s requirements page is the authority for these upload floors. Recheck it when planning future submissions because platform requirements can change. Then keep the project’s build settings, build environment, and submitted archive aligned.

SourcesCopy Anchor Link

• Apple Developer: Upcoming Requirements
• AI-built app submission checklist
• Google Play API 36 deadline
• Google Play closed testing