In this article

Verify the Xcode selected by the job and the SDK used by the archive before diagnosing an App Store Connect toolchain rejection. A runner containing the required Xcode is insufficient if the job selects another installation.

As checked on October 8, 2026, Apple’s upcoming requirements list Xcode 26 or later and the corresponding listed platform SDKs for uploads since April 28, 2026. The same page separately says iOS and iPadOS apps must target iOS 13 or later since September 9, 2026. Recheck that page before uploading; requirements change.

Keep three questions separate#

  1. Which Xcode runs this command?
  2. Which SDK builds this archive?
  3. What operating-system versions does the app support?

The SDK and deployment target serve different purposes. Updating Xcode does not mean your product must support only the newest iOS release. Conversely, lowering the deployment target does not fix an archive built with an ineligible SDK.

Inspect the job, not your laptop#

Run a read-only preflight inside the actual CI job:

sh
xcode-select -p
xcodebuild -version
xcodebuild -showsdks

Also inspect whether the workflow defines DEVELOPER_DIR. A per-job selection can differ from the machine’s default. Record the relevant path without dumping the complete environment, which may contain secrets.

Use the installed Xcode’s command help and Apple’s build-upload guidance for the supported upload path. These command examples are diagnostic documentation, not a test performed on your runner.

Tie the evidence to the archive#

Keep the commit, workflow run, selected Xcode, SDK and archive identity together. If the build happens in one job and upload in another, trace which artifact was downloaded. An uploader running under a newer toolchain does not prove an older archive was rebuilt.

For example, a hypothetical pipeline may successfully select a new Xcode but retrieve yesterday’s archive from an unrelated artifact. The useful fix is to correct artifact provenance, not to keep changing runner labels.

Avoid a “newest archive” rule based only on filename or modification time. Use the exact artifact produced by the intended build run and configuration.

Check project settings without broad upgrades#

Review the app and extension targets’ deployment settings, supported SDK and relevant build configuration. A host app and an extension can have different settings. Resolve the specific incompatibility instead of changing every target’s minimum version without evaluating your users.

When dependencies impose a minimum operating-system version, record the dependency and its documented requirement. That is a separate product decision from Apple’s upload-toolchain policy.

Rebuild once the cause is identified#

After correcting selection or configuration, make a new archive and repeat the preflight in the same job. Verify its bundle identifier and build metadata before upload. Keep the previous rejection text so you can establish whether the same condition remains.

If it still fails, an escalation note should include the exact rejection, selected Xcode/SDK, archive identity and relevant settings. Remove signing material and credentials from shared logs.

This checklist addresses upload eligibility. Signing errors, reviewer access and beta availability need their own evidence. The CascadeCI introduction shows how execution and store outcomes fit into a release record.