App Store Compliance
ITSAppUsesNonExemptEncryption: App Store export compliance, decoded
Fix the "Missing Compliance" status: when to set ITSAppUsesNonExemptEncryption to false, the HTTPS/standard-crypto exemption, and when you need docs.
You uploaded your first build, opened App Store Connect to submit, and the build sits in TestFlight or the version page with a yellow “Missing Compliance” status — or App Store Connect interrupts you with this:
Missing Compliance — Provide export compliance information for the
build before you can submit it for review. Does your app use
encryption? Select Yes even if your app only uses the standard
encryption within Apple's operating system.
Nothing is wrong with your binary. App Store Connect is asking a US export-control question: does your app use encryption, and if so, is it the kind that requires you to file paperwork? Until you answer, the build can’t be submitted. This is one of the most common things that stalls a first upload, because nothing in Xcode warns you it’s coming.
This is the systematic walkthrough: what export compliance is, the one Info.plist key that makes the prompt disappear, and exactly when you can declare yourself exempt versus when you actually need documentation.
For the full picture of everything submission needs beyond the binary, see shipping your first app after WWDC.
What export compliance actually is
The US government regulates the export of encryption technology under the Export Administration Regulations (EAR). Because the App Store distributes your app worldwide, Apple is legally required to collect a declaration about the encryption your app uses. That’s the entire reason this prompt exists — it has nothing to do with privacy, App Review quality, or your data practices.
The good news: the overwhelming majority of apps qualify for an exemption and never have to file anything. The bad news: App Store Connect’s default behavior is to ask you every single upload until you tell it, in your project, what the answer is.
The question, decoded
“Does your app use encryption?” trips people up because the honest answer is almost always technically yes. If your app makes a single HTTPS request — to your own API, to a third-party SDK, to fetch anything — it uses encryption. TLS is encryption. So you can’t just answer “No.”
The real question Apple is asking is whether your app uses non-exempt encryption: encryption beyond the standard, well-understood algorithms that ship in the operating system and are used in standard ways. Three categories of encryption are exempt:
- HTTPS / TLS calls to fetch or send data (the iOS networking stack).
- Standard system cryptography — Apple’s own APIs (
CryptoKit, Keychain,CommonCrypto,Security.framework) used for their intended purpose. - Encryption you don’t author that’s limited to authentication, digital signatures, or copy protection (DRM).
If your encryption use falls entirely inside those categories, your app is exempt and you declare it — no documentation required.
The Info.plist key that ends the prompt
Rather than answering the “Missing Compliance” question by hand on every upload, set it once in your project. Add this to your target’s Info.plist:
<key>ITSAppUsesNonExemptEncryption</key>
<false/>
Or in a modern Xcode project that uses the generated Info.plist (build settings → Info → Custom iOS Target Properties), add App Uses Non-Exempt Encryption and set it to NO.
With this key present and set to false, App Store Connect stops asking — the build comes through with compliance already satisfied. This is the correct, supported way to clear the status for an app that only uses exempt encryption.
Apple documents the key in Complying with Encryption Export Regulations.
When false is correct vs. when you need documentation
The decision tree:
| Your app… | ITSAppUsesNonExemptEncryption |
Documentation needed |
|---|---|---|
| Only makes HTTPS/TLS calls | false |
None |
| Uses only Apple’s crypto APIs in standard ways | false |
None |
| Uses encryption only for auth, signatures, or DRM | false |
None |
| Implements its own/custom encryption algorithm | true |
Usually yes |
| Uses non-standard crypto for proprietary purposes | true |
Usually yes |
Set it to false when every use of encryption in your app — including in your dependencies — is one of the exempt categories. That covers the vast majority of apps: a typical app that talks to a REST API over HTTPS and stores a token in the Keychain is exempt.
Set it to true if you ship custom or proprietary encryption — for example, a messaging app implementing its own end-to-end protocol, or an app bundling a non-standard cryptographic library. When the key is true, App Store Connect will ask follow-up questions and, in most cases, require you to provide export compliance documentation (often a self-classification report and an annual self-classification report submitted to the US government). If you’re in this bucket, talk to a compliance specialist — don’t guess.
Note that even some true cases are exempt from filing under specific EAR provisions, but the mechanics are beyond what you should resolve from a blog post. The clean, common path is: standard crypto only → false → done.
Don’t set false blindly — audit your dependencies
The same trap that produces surprise ITMS-90683 purpose-string rejections applies here: a third-party SDK can introduce non-exempt encryption you didn’t write. An SDK that ships its own cryptographic implementation (rather than calling Apple’s) can technically move you out of the simple exemption.
In practice, the well-known SDKs (analytics, networking, auth) use standard system crypto or plain HTTPS and stay within the exemption. But if you bundle anything that advertises “custom encryption,” “proprietary security,” or its own crypto engine, confirm what it does before declaring false. The declaration is yours to stand behind, not the SDK vendor’s.
A note on TestFlight
The prompt also appears for TestFlight builds, not just App Store submission — often this is the first place a new developer hits it, before they’ve even thought about the public listing. Setting ITSAppUsesNonExemptEncryption in Info.plist clears it for TestFlight and App Store distribution at the same time, so you only have to decide once.
Re-archive after adding the key
Like purpose strings, this key is read from the archive. Adding it means:
- Add
ITSAppUsesNonExemptEncryptiontoInfo.plist. - Clean build folder (
⇧⌘K). - Archive again (
Product → Archive). - Upload the new build.
The build already sitting in App Store Connect won’t retroactively pick up the key — but you can answer the “Missing Compliance” question manually for that existing build to unblock it immediately, then ship the key in your next archive so it never asks again.
Where OrbitKit fits
OrbitKit doesn’t set this Info.plist key for you — it lives in your Xcode project, and it’s a one-line change. What OrbitKit handles is the other half of a first submission: the web URLs Apple requires before App Review will look at your binary — your privacy policy, your App Store support page, your data-deletion page, and your privacy nutrition label — generated and hosted on your own domain. Build and preview everything free; pay $5/mo per app to take a site live. Start free.
Related
- The full non-code submission checklist: shipping your first app after WWDC.
- The other thing that stalls first uploads: ITMS-90683 missing purpose string.
- Everything Apple requires to submit: every URL and file for an iOS App Store submission.