Error ITMS-90482 means the build you uploaded contains bitcode, which the App Store no longer accepts. Apple deprecated bitcode in Xcode 14 and stopped accepting bitcode submissions, so any executable that still embeds it is rejected at upload. The fix has two parts: set Enable Bitcode to No in your own build settings, which is already the default in Xcode 14, and remove bitcode from any third-party framework that still contains it, either by updating the SDK to a version built without bitcode or by stripping it. Then bump your build number and upload again.
Short answer
ITMS-90482 is a delivery error, not a review rejection, and it clears once no part of your app embeds bitcode. Per Apple's Xcode 14 release notes, bitcode is deprecated and the App Store no longer accepts bitcode submissions from Xcode 14, so an executable that still contains it fails at upload. Set ENABLE_BITCODE to NO, which Xcode 14 does by default, and, as the Apple developer forums note is the usual cause, update or strip any third-party framework that still contains bitcode. Then upload a new build with an incremented build number.
What ITMS-90482 means
ITMS-90482 is App Store Connect telling you, at upload time, that the binary you submitted contains bitcode and therefore cannot be accepted. Bitcode was an intermediate representation Apple once used to re-optimize apps on its side, but Apple deprecated it in Xcode 14 and the App Store stopped accepting bitcode submissions from that version onward. So a build that still embeds bitcode is refused during delivery or processing, before it ever reaches App Review.
That timing is worth understanding, because it changes how you think about the fix. This is not a reviewer judging your app; it is an automated validation catching a build that does not meet the current format. So there is no appeal to write and no review to wait out. The moment you produce a build with no bitcode anywhere in it, the error stops happening, which makes ITMS-90482 a build-configuration problem to solve rather than a submission to argue.
Set Enable Bitcode to No
The first thing to check is your own project, because if your build settings still enable bitcode, your app embeds it. In Xcode 14 and later, the Enable Bitcode setting defaults to No and Apple removed it from the standard build settings interface, so most modern projects are already correct. But a project migrated from an older Xcode, or one with a lingering configuration, can still carry ENABLE_BITCODE set to YES.
So confirm ENABLE_BITCODE is NO across your targets. Check the build settings on every target, not just the app, and look in any xcconfig files and CI build scripts for an ENABLE_BITCODE value or a -fembed-bitcode flag that turns it back on. If you use CocoaPods, a Podfile post-install hook is a common place where bitcode gets forced on the pods, so make sure it is not setting ENABLE_BITCODE to YES. Once your own build embeds no bitcode, you have handled half the problem.
The usual culprit: a third-party SDK
In Xcode 14 the most common cause of ITMS-90482 is not your app but a third-party framework that was compiled with bitcode, because a bundled binary can still contain bitcode even when your app has it disabled, and that mix is what the App Store rejects. So you can have Enable Bitcode set to No everywhere in your own project and still fail, simply because one vendored framework or SDK inside your app carries bitcode from how it was built.
The clean fix is to update the offending SDK to a version its maintainer compiled without bitcode, since most vendors shipped bitcode-free builds after Xcode 14. So check each third-party framework for an update, and prefer that route because it keeps the dependency in a supported state. When an update is not available, you can remove the bitcode from the framework binary yourself, which is the next section. Identifying which framework carries bitcode is the key step, and the upload error message often names the executable involved.
How to strip bitcode from a framework
When you cannot update a framework, you can strip the bitcode out of its binary using the bitcode_strip tool that ships with Xcode. Running xcrun bitcode_strip on the framework's binary with the remove option produces a copy with the bitcode section removed, which you then use in place of the original. This is a legitimate build step for your own app's dependencies, and it targets only the bitcode marker, leaving the framework's actual code intact.
The other place to intervene is the build flags. If a framework is built as part of your project and picks up bitcode from a -fembed-bitcode flag, removing that flag from the build script stops the bitcode being embedded in the first place. Between updating the SDK, stripping the binary, and removing the embed flag, you have a route for every situation. The goal in all of them is the same: produce a final app where no binary, yours or a dependency's, contains bitcode.
Common causes and fixes
Matching where the bitcode comes from to its fix is the whole task. The table below maps the common cases.
| Cause | Where it lives | Fix |
|---|---|---|
| Enable Bitcode set to YES | Your target build settings | Set ENABLE_BITCODE to NO |
| Podfile forces bitcode | CocoaPods post-install hook | Remove the ENABLE_BITCODE YES line |
| Vendored framework has bitcode | A third-party SDK binary | Update the SDK or strip with bitcode_strip |
| Build script embeds it | A -fembed-bitcode flag | Remove the flag from the script |
Read the third row as the most likely: in Xcode 14 a third-party framework that still contains bitcode is the usual reason a correctly-configured app still fails.
Do I need to upload a new build?
Yes. Because ITMS-90482 rejects the binary at upload, the failed build never enters App Review, so there is nothing to reset there; you simply fix the bitcode and upload a fresh build. That build must have a new, incremented build number, since App Store Connect will not accept a second upload with the same version and build number as one it already processed. Re-uploading the same binary without changing anything just reproduces the error.
So the sequence is to make the change, bump the build number, archive, and upload again. There is no review timeline to worry about here and no support case to open, because this is a validation error you resolve entirely on your side. If you fixed your own settings and stripped or updated the third-party framework, the new build should pass validation and move on to processing normally, at which point you continue with your submission as usual.
Cross-platform and no-code builds
If you build with a cross-platform or managed toolchain, the good news is that bitcode is off by default in current versions, so a fresh build rarely hits this. Expo EAS, React Native, and Flutter produce bitcode-free iOS builds now, so you usually only see ITMS-90482 from an older configuration or an outdated native dependency carried along. So updating your toolchain and native modules is often the whole fix.
The one thing to watch across these stacks is a pinned or aging native dependency that was built with bitcode before the Xcode 14 change. The symptom is the same, an ITMS-90482 at upload, and the fix is the same, update the dependency to a current version or strip the bitcode from its binary. So even in a managed build, the resolution comes down to ensuring no native framework in the final app still embeds bitcode.
Fix checklist
Working through these steps clears the error. The checklist below covers them.
| Step | Action | Done? |
|---|---|---|
| Disable in your project | Set ENABLE_BITCODE to NO on all targets | [ ] |
| Check build scripts | Remove any -fembed-bitcode flag | [ ] |
| Check CocoaPods | Ensure the Podfile does not force bitcode | [ ] |
| Update third-party SDKs | Move to bitcode-free framework versions | [ ] |
| Strip stubborn frameworks | Use bitcode_strip where no update exists | [ ] |
| Upload a new build | Bump the build number and re-upload | [ ] |
The step teams skip most is checking third-party SDKs, since a single vendored framework with bitcode fails the upload even when the app's own settings are correct.
Where a scan fits
Fixing ITMS-90482 is a build-configuration task, but it does put a spotlight on your third-party frameworks, which are worth understanding beyond just their bitcode.
A scanner like PTKD.com analyzes your app build and reports on the third-party code inside it, along with issues such as exposed keys and over-broad permissions, by severity and mapped to OWASP MASVS. To be clear about the boundary: PTKD does not change your build settings or strip bitcode for you, which you do in Xcode and your dependencies. It helps you see what third-party frameworks your app actually ships, which is useful context while you are already auditing them for this error.
What to take away
- ITMS-90482 means your uploaded build contains bitcode, which the App Store no longer accepts after Apple deprecated bitcode in Xcode 14.
- It is a delivery validation error caught at upload, not an App Review rejection, so there is nothing to appeal and no review to wait out.
- Set ENABLE_BITCODE to NO in your project, which is the Xcode 14 default, and check build scripts and any Podfile hook that might force it back on.
- The usual cause in Xcode 14 is a third-party framework that still contains bitcode, so update the SDK to a bitcode-free version or strip it with bitcode_strip.
- Upload a fresh build with an incremented build number, and a tool like PTKD.com helps you see which third-party frameworks your app ships.
