ITMS error codes explained: a reference for App Store upload failures
An ITMS error is a validation failure produced by Apple's delivery pipeline when you upload a build. It is not a review rejection. No human has seen your app. A machine unpacked your .ipa, checked it against a list of structural rules, and refused it.
The code tells you which rule. The message after it tells you which file. Between them they are almost always enough to fix the problem, provided you read the whole string rather than searching for the number alone. Each code in the table below is anchored, so you can link straight to a row.
What "ITMS" is
The prefix is a leftover from Apple's original content delivery system, and is widely understood to stand for iTunes Music Store. Apple has never documented the expansion, so treat that as received wisdom rather than fact. It identifies the validation layer between your upload and App Store Connect: shared machinery, which is why an app developer occasionally gets a message that reads as though it were written for a record label.
Where they come from
Every route to App Store Connect ends in iTMSTransporter, a Java command line tool that ships with Xcode's command line tools:
- Xcode Organizer, when you distribute an archive
- Transporter, Apple's standalone Mac app, which replaced Application Loader after it was removed in Xcode 11
xcrun altool, wrapped by most CI systems- fastlane, which calls one of the above
So the same build produces the same codes whichever route you use. Trying the Transporter app after Xcode changes only the verbosity, and the extra detail is usually the useful part.
When the tool itself fails rather than your build you get a different class of error. spawn iTMSTransporter ENOENT means the uploader is not installed on the machine, and says nothing about your binary.
ERROR, WARNING, and the ones that arrive by email
Severity decides whether you have a problem right now.
ERROR ITMS-xxxxx blocks the upload. The build does not appear. Apple's email reads "Please correct the following issues, then upload again."
WARNING ITMS-xxxxx blocks nothing. The build lands and is usable. Apple's email reads "Your delivery was successful, but you may wish to correct the following issues in your next delivery."
Codes that arrive only by email, after a successful upload. Some are advisory and some will eventually block you, and the email text is the only way to tell which.
Several codes below have appeared at all three severities in different years, as deprecation deadlines passed.
How to read one
ERROR ITMS-90035: "Invalid Signature. Code object is not signed at all.
The file at path [MyApp.app/Frameworks/InfineaSDK.framework/SDKSetup]
is not properly signed."
The path is the most useful part. Frameworks/InfineaSDK.framework/SDKSetup is a third-party SDK, not your code, which changes the fix from "check my signing settings" to "get a signed build from the vendor". The code is useful for searching and useless alone.
People search the number and skip the path. Same code, different file, different bug.
Apple publishes no index
There is no official, public, maintained list of ITMS codes with causes and fixes. The Transporter user guide describes categories of message without enumerating the app-specific codes, and Apple's documentation covers individual requirements without cross-referencing the codes that enforce them.
The knowledge lives instead in Stack Overflow answers, Apple Developer Forums threads and the issue trackers of cross-platform toolchains. Every reference table you find, including this one, is assembled from reported error strings rather than copied from a specification. So a code missing from a table is not rare or unimportant. It means nobody wrote it down.
The common codes
Signing and provisioning
| Code | What it says | Cause and fix |
|---|---|---|
ITMS-90034 |
"not signed using an Apple submission certificate" | A development or ad hoc identity. Re-export with an App Store distribution certificate. |
ITMS-90035 |
"Invalid Signature. Code object is not signed at all." | Read the path: usually a vendor framework. Get a signed build, or sign it yourself. |
ITMS-90046 |
"Invalid Code Signing Entitlements ... value ... for key 'application-identifier' is not supported" | A stale profile after a capability such as Associated Domains changed. Regenerate it. |
ITMS-90078 |
"entitlements do not include the 'aps-environment' entitlement" | The app registers for push but the profile has no push capability. Enable it on the App ID. Usually a warning. |
ITMS-90161 |
"Invalid Provisioning Profile ... [Missing code-signing certificate]" | The certificate the profile references is expired, revoked, or missing from the signing keychain. |
ITMS-90165 |
"Invalid Provisioning Profile Signature ... until it has a valid signature from Apple" | Not properly signed by Apple. Delete, regenerate, re-download. |
ITMS-90174 |
"must contain a provisioning profile in a file named embedded.mobileprovision" | The export produced an unsigned IPA. Usually a wrong export options plist in CI. |
Bundle structure
| Code | What it says | Cause and fix |
|---|---|---|
ITMS-90167 |
"No .app bundles found in the package" | A malformed IPA from an archive or export that failed silently. Clean and rebuild. |
ITMS-90171 |
"The binary file '...' is not permitted. Your app can't contain standalone executables or libraries" | A static library or loose binary copied in as a resource. Remove it from Copy Bundle Resources. |
ITMS-90206 |
"contains disallowed file 'Frameworks'" | An embedded framework embedding frameworks of its own. Set the inner ones to Do Not Embed. |
ITMS-90207 |
"does not contain a bundle executable" | CFBundleExecutable names a file that is not in the bundle. Often a renamed target. |
ITMS-90535 |
"Unexpected CFBundleExecutable Key ... consider ... using a CFBundlePackageType of BNDL" | An SDK's resource bundle. The fix is in the SDK's plist: update the SDK or patch it in a build phase. |
ITMS-90680 |
"is not contained in a correctly named directory. It should be under 'Frameworks'." Also, separately: "The binary you uploaded was invalid." | One code, two messages. The first is precise; the second is a catch-all needing the other codes in the delivery. |
ITMS-90685 and ITMS-90806 |
"CFBundleIdentifier Collision. There is more than one bundle with the CFBundleIdentifier value ..." and its warning-level sibling "is used in the bundles '[...]'" | The same framework embedded twice, often via two dependency managers, or in both the app and an extension. The warning form lists both paths. |
Info.plist and versioning
| Code | What it says | Cause and fix |
|---|---|---|
ITMS-90057 and ITMS-90056 |
"missing the required key: CFBundleShortVersionString" and "missing the required key: CFBundleVersion" | They usually arrive together. Read the path: it often names an extension or framework, not the app. |
ITMS-90062 |
"must contain a higher version than that of the previously approved version" | Comparison is dotted, not decimal. 1.10 beats 1.9; 1.1 does not beat 1.10. |
ITMS-90713 |
"A value for the Info.plist key 'CFBundleIconName' is missing" | Icons are loose files instead of in an asset catalogue. Very common in Cordova and Capacitor. |
ITMS-90502 |
"Apps that only contain the arm64 slice must also have 'arm64' in the list of UIRequiredDeviceCapabilities" | Add arm64 to the key. It also drops 32-bit devices from your supported list. |
Icons and assets
| Code | What it says | Cause and fix |
|---|---|---|
ITMS-90022 and ITMS-90023 |
"does not contain an app icon for iPhone / iPod Touch of exactly '120x120' pixels", and the same for iPad sizes such as '76x76' and '152x152' | A gap in the asset catalogue, or icons shipped as loose files. If iPad sizes are demanded on an iPhone-only app, check the target's device family. |
ITMS-90704 |
"An app icon measuring 1024 by 1024 pixels in PNG format must be included in the Asset Catalog" | It must be in the binary. Uploading it in App Store Connect does not satisfy this. |
ITMS-90717 |
"The App Store Icon ... can't be transparent nor contain an alpha channel" | Flatten onto an opaque background and strip alpha. Design tools leave it in even when nothing is transparent. |
ITMS-90596 |
"The asset catalog at 'Payload/....app/Assets.car' can't be read. Try rebuilding the app with a non-beta version of Xcode" | Usually exactly that: a beta Xcode compiled it into a format the pipeline cannot read. |
Architecture and binary format
| Code | What it says | Cause and fix |
|---|---|---|
ITMS-90087 |
"contains unsupported architectures '[x86_64, i386]'" | A fat framework still carrying simulator slices. Switch to an XCFramework. Stripping scripts often produce ITMS-90125 next, about a mangled LC_ENCRYPTION_INFO load command. |
ITMS-90209 |
"does not have proper segment alignment. Try rebuilding the app with the latest Xcode version" | A vendor framework from an old toolchain. Apple's advice rarely helps; it is not your binary. Ask the vendor. |
ITMS-90635 |
"The Mach-O in bundle '...' isn't consistent with the Mach-O in the main bundle" | Mixed bitcode and machine code across your app and its frameworks. All must agree. |
Swift runtime
| Code | What it says | Cause and fix |
|---|---|---|
ITMS-90426 |
"The SwiftSupport folder is missing. Rebuild your app using the current public (GM) version of Xcode" | The export left out the Swift runtime, usually from a hand-built IPA or the wrong export method. It happens on pure Objective-C projects when a dependency is Swift. |
ITMS-90429 |
"The files libswiftCore.dylib ... aren't at the expected location /Payload/....app/Frameworks" | Swift dylibs ended up elsewhere, usually from a hand-rolled repackaging step. |
APIs, privacy and deprecation
| Code | What it says | Cause and fix |
|---|---|---|
ITMS-90338 |
"Non-public API usage. The app references non-public symbols in ..." or "non-public selectors in ..." | Name matching against Apple's private API list. Often a false positive from an SDK. Has its own page. |
ITMS-90683 |
"Missing Purpose String in Info.plist ... should contain a NSCameraUsageDescription key" | Add the named NS...UsageDescription key, even if you never use that capability. Has its own page. |
ITMS-90809 |
"Deprecated API Usage. Apple will stop accepting submissions of apps that use UIWebView APIs" | A UIWebView reference in your app or a dependency. Has its own page. |
ITMS-91053 |
"Missing API declaration ... API categories: NSPrivacyAccessedAPICategoryFileTimestamp" | Add a PrivacyInfo.xcprivacy with an NSPrivacyAccessedAPITypes array giving approved reasons. |
ITMS-91061 |
"Missing privacy manifest ... includes [SDK], an SDK ... identified in the documentation as a commonly used third-party SDK" | The SDK's own authors must ship the manifest. Update the dependency; you cannot fix it from yours. |
ITMS-91065 |
"Missing signature ... a privacy-impacting third-party SDK" | The SDK binary must be signed by its authors. Again, update the dependency. |
Toolchain and SDK version
| Code | What it says | Cause and fix |
|---|---|---|
ITMS-90111 |
"Invalid Toolchain. Your app was built with a beta version of Xcode or SDK" | Rebuild with a release Xcode. Whether betas are usable for TestFlight has varied by year, so do not assume. |
ITMS-90725 |
"SDK Version Issue. This app was built with the iOS 14.4 SDK. All iOS apps ... must be built with the iOS 15 SDK or later" | A floor Apple raises roughly annually. Self-diagnosing: it names both the SDK you used and the minimum. |
The ones that are not your fault
Some codes fire on Apple's side and clear on a re-upload with no change to your build. ITMS-90338 is the best-known example: identical binaries accepted one week have been flagged the next.
So re-uploading with a bumped build number is a legitimate diagnostic step rather than superstition. If the code fires twice on two different builds, stop re-uploading and read the path.
When there is no code at all
Sometimes a build lands in INVALID_BINARY with no email, no code and nothing in Resolution Center. That has its own diagnostic route, and the first move is to run the same upload through the Transporter app, which prints the codes in full where Xcode sometimes summarises them away.
AppSubmit keeps the full transporter output on the release timeline and translates the codes it recognises into a sentence and a fix, with the raw string preserved underneath. A translation that loses the original is worse than no translation when the release is on you.