AI AI Tools Guidebook
Troubleshooting

Fix ITMS-90426 Invalid Swift Support on App Store Upload

App Store Connect rejects your IPA with ITMS-90426 Invalid Swift Support when the SwiftSupport folder is missing. The fast fix plus six root causes, diagnosis commands, and a clean rebuild.

Published: Updated: Author: AI Productivity Guide Team 🌐 查看中文版本

Your archive validates locally, you hit Upload to App Store Connect, watch the progress bar finish, and minutes later an email lands: “ITMS-90426: Invalid Swift Support — The SwiftSupport folder is missing. Rebuild your app using the current public (GM) versions of Xcode and resubmit it.” Re-archiving and re-uploading produces the same error. The Frameworks folder looks fine, the project compiles cleanly, and Xcode says the archive is valid.

TL;DR (fastest fix first): This error means the SwiftSupport directory was not bundled into your .ipa. The single most common reason, by a wide margin, is that the IPA was exported with the wrong distribution method. Ad Hoc, Development, and Enterprise exports strip the Swift runtime libraries by default; only an App Store Connect distribution export includes SwiftSupport. Re-export your existing .xcarchive from Xcode → Window → Organizer → Distribute App → App Store Connect (or set export_method: "app-store" in fastlane), and re-upload. If you are already using an App Store export, the cause is a third-party framework that was packaged wrong — work through the table below.

Which bucket are you in

Symptom you can checkMost likely causeJump to
You exported via Ad Hoc / Development / Enterprise, or fastlane export_method is not app-storeWrong export method strips Swift libsCause 0
A vendored .framework/.xcframework shows an old DTXcodeBuilt with an older Swift toolchainCause 1
No .swiftinterface next to the framework’s .swiftmoduleBuilt without library evolutionCause 2
lipo -info lists x86_64/i386 on a frameworkSimulator slice leaked into device archiveCause 3
Framework appears under Link Binary but not Embed FrameworksManually copied instead of Embed & SignCause 4
Archive machine and upload machine differ on xcode-select -pXcode version mismatchCause 5
find shows multiple nested SwiftSupport/.swiftmoduleConflicting bundled Swift payloadCause 6

As of June 2026, Apple requires every iOS upload to be built with Xcode 26 / the iOS 26 SDK or later (enforced since April 28, 2026). “Current public (GM) Xcode” in the rejection email now means Xcode 26.x, not a beta and not Xcode 16/17. Confirm with xcodebuild -version; the SDK must report iOS 26 with xcodebuild -showsdks.

Common causes

0. Wrong export method (the most common cause)

This is the first thing to rule out and the reason most ITMS-90426 reports get resolved. An IPA exported as Ad Hoc, Development, or Enterprise has the Swift runtime support files stripped out — the SwiftSupport folder only ever gets assembled during an App Store Connect distribution export. The binary is identical; the wrapper layout is not.

How to spot it: Unzip the IPA and look for the folder: unzip -l YourApp.ipa | grep -i SwiftSupport. If nothing prints, the SwiftSupport directory is absent and you exported with the wrong method. In fastlane, check that gym/build_app uses export_method: "app-store", not "ad-hoc" or "development".

Common framework causes

Ordered by likelihood.

1. Embedded framework was built with a different Swift version

You pulled in a vendored .xcframework or .framework (binary distribution) that was compiled with an older Swift toolchain. App Store Connect compares the framework’s SwiftSupport metadata to the public GM Xcode and rejects the mismatch.

How to spot it: otool -L YourApp.app/YourApp shows the binary’s Swift libs path; the framework’s Swift libs were compiled against libswiftCore.dylib from an older Xcode. Check Frameworks/<Framework>.framework/Info.plist for DTXcode version less than your current Xcode.

2. The framework was built without BUILD_LIBRARY_FOR_DISTRIBUTION

For a Swift framework to be safe to ship across Xcode versions, it must be built with BUILD_LIBRARY_FOR_DISTRIBUTION = YES. Without it, the framework’s ABI is non-stable and the archive’s SwiftSupport folder cannot be reconciled.

How to spot it: Inspect the vendored framework — if there is no .swiftinterface file alongside .swiftmodule, the framework was not built for distribution.

3. Pod / SPM pulled an x86_64 simulator slice into the device archive

When a .xcframework is missing or a .framework was built as a “fat” Mach-O including simulator slices, the App Store upload step rejects the SwiftSupport folder for the simulator architectures.

How to spot it: lipo -info YourApp.app/Frameworks/<Framework>.framework/<Framework> shows x86_64 or i386 slices alongside arm64. App Store binaries must contain device slices only.

4. Manually copied dynamic frameworks instead of using Embed Frameworks

If you drag-dropped a .framework into the project without checking Embed & Sign under Frameworks, Libraries, and Embedded Content, Xcode does not call the Run Script: Strip Invalid Architectures phase, and the SwiftSupport folder is not assembled correctly.

How to spot it: Open Build Phases → Embed Frameworks. If your framework is not listed there but appears in Link Binary With Libraries, that is the cause.

5. Uploaded with a different Xcode than you archived with

The upload step uses the calling Xcode’s tools to assemble SwiftSupport. If your CI machine still has Xcode 16 active but your dev machine archived with Xcode 26, the upload step pulls the wrong Swift support files. Since April 28, 2026 anything older than Xcode 26 is also rejected outright with an SDK-too-old error, so a stale CI image is now doubly likely to fail.

How to spot it: xcode-select -p on the upload machine differs from the archive machine, or xcodebuild -version on either is below 26.

6. The framework ships an old swiftsupport payload that conflicts

Some old frameworks bundle their own SwiftSupport directory inside the framework. App Store Connect deduplication can pick the wrong copy.

How to spot it: find YourApp.app/Frameworks -name "SwiftSupport" -o -name "*.swiftmodule" lists multiple module locations across nested frameworks.

Before you start

  • Save the exact ITMS-90xxx error number from the rejection email — different numbers mean different fixes.
  • Make a copy of the failing .xcarchive to ~/Desktop/ArchiveDebug.xcarchive — you will run a few inspections on it.
  • Identify which framework is the culprit; the rejection email sometimes names it, sometimes only says “SwiftSupport.”

Information to collect

  • Output of ls -la YourApp.xcarchive/Products/Applications/YourApp.app/Frameworks/.
  • Output of lipo -info <each framework binary>.
  • Output of otool -L <each framework binary> | grep -i swift.
  • Xcode version: xcodebuild -version on the archiving machine.
  • Each framework’s Info.plist DTXcode and DTSDKBuild values.
  • Pod / SPM declarations from Podfile and Package.resolved.

Step-by-step fix

Step 1: Identify the offending framework

Inspect every framework in the archive:

cd YourApp.xcarchive/Products/Applications/YourApp.app/Frameworks
for fw in *.framework; do
  echo "=== $fw ==="
  lipo -info "$fw/$(basename $fw .framework)"
  /usr/libexec/PlistBuddy -c "Print :DTXcode" "$fw/Info.plist" 2>/dev/null
  ls "$fw/Modules/$(basename $fw .framework).swiftmodule/" 2>/dev/null
done

Look for: simulator architectures, missing .swiftinterface files, or DTXcode significantly older than your archive Xcode.

Step 2: Replace fat frameworks with XCFrameworks

If a vendored framework includes simulator slices, ask the vendor for an .xcframework, or convert yourself:

# Extract device-only slice
lipo -extract arm64 \
  Path/To/Old.framework/Old \
  -o Path/To/Old.framework/Old-device

mv Path/To/Old.framework/Old-device Path/To/Old.framework/Old

# Or build an XCFramework from device + sim archives
xcodebuild -create-xcframework \
  -framework Path/To/Device.framework \
  -framework Path/To/Simulator.framework \
  -output Path/To/Combined.xcframework

Replace the project reference with the .xcframework — Xcode auto-selects the right slice per build.

Step 3: Rebuild any in-house Swift framework with library evolution

In the framework target’s Build Settings:

BUILD_LIBRARY_FOR_DISTRIBUTION = YES
SWIFT_INSTALL_OBJC_HEADER = YES
SKIP_INSTALL = NO

Then archive the framework target:

xcodebuild archive \
  -scheme MyFramework \
  -destination "generic/platform=iOS" \
  -archivePath ./build/iOS.xcarchive \
  SKIP_INSTALL=NO \
  BUILD_LIBRARY_FOR_DISTRIBUTION=YES

Repeat for simulator with -destination "generic/platform=iOS Simulator", then xcodebuild -create-xcframework.

Step 4: Ensure every framework is Embed and Sign in the app target

App target → General → Frameworks, Libraries, and Embedded Content. Every dynamic framework should show Embed & Sign. Static libraries are Do Not Embed. If a framework shows Do Not Embed but should be dynamic, switch it.

Step 5: Match Xcode versions across machines and CI

Pin Xcode 26 (the current minimum) in your CI config:

xcode_version: "26.0"

On dev: sudo xcode-select -s /Applications/Xcode_26.0.app/Contents/Developer. Mismatched Xcode between the archive step and the upload step causes the SwiftSupport stripper to use the wrong source; anything below 26 also fails the App Store SDK minimum as of April 28, 2026.

Step 6: Clear DerivedData and rebuild cleanly

Cached Swift modules cause stale SwiftSupport payloads:

rm -rf ~/Library/Developer/Xcode/DerivedData/*
rm -rf ~/Library/Caches/org.swift.swiftpm
xcodebuild clean -workspace YourApp.xcworkspace -scheme YourApp

Then re-archive from clean state. Skipping this step is the single most common reason a “fixed” project still uploads the old broken framework.

Step 7: Upload via the right tool

The most reliable path is Xcode’s Organizer (Window → Organizer → Archives → Distribute App → App Store Connect), because it re-runs the App Store export that assembles SwiftSupport. If you script it, xcrun altool --upload-app still works for App Store uploads and must run from the same Xcode you archived with:

xcrun altool --upload-app -f YourApp.ipa -t ios \
  --apiKey "$ASC_KEY_ID" --apiIssuer "$ASC_ISSUER_ID"

Note: altool is deprecated for notarization only (rejected by the notary service since Nov 1, 2023) — App Store uploads still go through it, and Apple now recommends the standalone Transporter app or App Store Connect API keys over the old -u/-p password flow. Watch the upload log; the SwiftSupport processing step prints which frameworks it processed.

Verify

  • New archive’s Frameworks/ contains only arm64 binaries.
  • Each Swift framework’s module folder contains .swiftinterface files alongside .swiftmodule.
  • App Store Connect upload completes without ITMS-90426 / 90427.
  • The processed build appears in TestFlight within 5-30 minutes.
  • Validate Xcode → Window → Organizer → Validate App → no warnings about Swift support.

Long-term prevention

  • Prefer .xcframework for every binary dependency; fat frameworks are deprecated and will keep biting you.
  • Ask vendors for distribution-built frameworks; if they refuse, build from source where possible.
  • Lock Xcode version in CI and on every dev machine via .xcode-version file or nvm-style switcher.
  • Add a pre-upload script that runs lipo -info on every framework in the archive and fails the build if simulator slices appear.
  • Track which Swift / Xcode version each vendored framework was built against; recompile on Xcode major upgrades. See TestFlight Build Stuck Processing for the downstream symptom.
  • Avoid drag-dropping .framework files into the project; use Swift Package Manager or Pods which handle the embed step correctly.

Common pitfalls

  • Re-uploading the same .ipa after “fixing” Xcode settings — without re-archiving, your IPA is unchanged.
  • Mixing static and dynamic versions of the same framework; the App Store sees duplicate symbols and rejects.
  • Setting BUILD_LIBRARY_FOR_DISTRIBUTION = YES on the App target instead of the Framework target.
  • Forgetting that CocoaPods uses use_frameworks! to decide static vs dynamic; switching this requires deintegrate + reinstall.
  • Submitting from a Mac with a beta Xcode while the archive was built with GM Xcode — Apple Beta Xcode archives are not accepted for production submission.
  • Assuming xcrun altool always matches the active Xcode — xcode-select setting is what determines it.

FAQ

Q: My app has no third-party frameworks at all. Why is SwiftSupport missing?

Then it is almost certainly Cause 0: the .ipa was exported with a non-App-Store method. Tools like fastlane, Expo/EAS, Unity, and Qt frequently default to an Ad Hoc or Development export, which strips SwiftSupport. Run unzip -l YourApp.ipa | grep -i SwiftSupport — if it prints nothing, re-export the same .xcarchive via Organizer → Distribute App → App Store Connect, or set the build tool’s export method to app-store. No rebuild of code is required.

Q: The vendor says their framework supports App Store. Why does Apple reject it?

Most likely the framework was built with BUILD_LIBRARY_FOR_DISTRIBUTION = NO or shipped as a fat framework including simulator slices. Ask for an .xcframework built with the latest Xcode GM. If they refuse, your only remedies are to build from source or drop the dependency.

Q: Will Bitcode help here?

Bitcode is deprecated since Xcode 14 — disable it in Build Settings (ENABLE_BITCODE = NO). Keeping it on with modern Xcode adds risk without benefit and can intersect with Swift support errors in obscure ways.

Q: I am using Swift Package Manager. Can this still happen?

Yes, if the SPM package vends a binary target (.binaryTarget(name:url:)) pointing to a problematic XCFramework. Inspect the binary in ~/Library/Developer/Xcode/DerivedData/<proj>/SourcePackages/artifacts/.

Q: Apple says rebuild with GM Xcode but I used GM Xcode. What now?

First confirm your toolchain actually meets the current floor: xcodebuild -version must report Xcode 26 or later (the minimum since April 28, 2026). If your app is fine, check the DTXcode and DTSDKBuild keys in each vendored framework’s Info.plist. If any one of them was built with an older Xcode, that is the framework Apple is rejecting; you need a new build of that framework, not of your app.

Q: Can I just delete the framework’s SwiftSupport folder manually?

No. Xcode regenerates the archive’s SwiftSupport during export; manual edits get overwritten. Fix the framework’s build settings instead.

Tags: #Troubleshooting #ios #xcode #swift #archive

Related Articles