ITSAppUsesNonExemptEncryption: do you need it, and what to set

Last reviewed 24 July 2026.

What App Store Connect is actually asking

Apps distributed through the App Store are legally “exported” from the United States, so they fall under the US Export Administration Regulations (EAR). When your build uses encryption, App Store Connect has to know whether it is the ordinary kind (exempt) or the kind that needs paperwork (non-exempt). That is the entire meaning of the question.

The catch: almost every app uses encryption today, because any HTTPS call does. So “does your app use encryption?” is nearly always yes — but the answer that unblocks you is about whether that encryption is exempt, and for the vast majority of apps it is.

Decision tree: do you use non-exempt encryption?

Walk these in order. The first one that matches decides your answer.

1. Does your app use no encryption at all, or none beyond what iOS itself provides? → Exempt. Answer NO (ITSAppUsesNonExemptEncryption = false).
2. Is all your encryption limited to HTTPS/TLS, or the standard crypto APIs Apple ships in iOS/macOS (CryptoKit, Keychain, Secure Enclave, etc.)? → Exempt. Answer NO. This covers the overwhelming majority of apps.
3. Do you only use encryption for authentication — hashing passwords, signing tokens — and not to encrypt user content? → Exempt. Answer NO.
4. Do you ship your OWN encryption algorithm, or use crypto to protect user data beyond the above (e.g. a proprietary end-to-end scheme, a custom cipher, encrypting files with your own key management)? → Potentially non-exempt. Answer YES and complete self-classification (see below).

Reusing standard crypto through your own convenience wrapper does not make it non-exempt — what matters is the underlying algorithm, not that you wrapped it. Inventing or embedding a non-standard algorithm is what tips you into non-exempt.

The two ways to answer — and why the plist wins

There are exactly two places to answer this. They are not equivalent: one asks you every single release, the other answers once and stays answered.

The exact plist snippet

Add this to your app target's Info.plist (or via the Info tab / xcconfig). It is a Boolean:

<key>ITSAppUsesNonExemptEncryption</key>
<false/>

Then Clean Build Folder (⇧⌘K), archive again, and upload. Setting it to false is only correct if your app is exempt per the tree above — it is a legal declaration, not a mute button. One subtlety: a build already sitting in App Store Connect will not retroactively pick up the key. Answer that one build's question manually to unblock it now, and ship the key in your next archive so it never asks again.

When you actually DO need the exemption / self-classification

If step 4 of the tree matched — you ship non-standard or proprietary encryption — answering YES is not the end. You take on real obligations under the EAR:

• Self-classification: determine your app's ECCN (typically 5D002) and confirm it qualifies for License Exception ENC under EAR §740.17.
• Annual self-classification report: for most mass-market encryption apps you must email a self-classification report to BIS and the ENC/NSA encryption request coordinator once a year (the year-end report).
• CCATS: some products need a formal classification (CCATS) from the Bureau of Industry and Security before they qualify — App Store Connect will then ask for that authorization.
• Documentation in App Store Connect: you provide your exemption basis or CCATS/ERN details in the encryption section, per release, unless you've supplied a compliance code.

This is genuinely rare for consumer apps. If you are using CryptoKit, Keychain, TLS and nothing exotic, you are exempt and none of this applies — answer NO and move on.

Not sure whether your crypto is exempt? Apple links to the US Bureau of Industry and Security; the practical test is “did I implement an encryption algorithm, or just call Apple's / use HTTPS?” The latter is exempt.

The common failure: the key missing entirely

The most frequent way this bites is not a wrong value — it is no value. With the key absent:

• Every TestFlight build lands in “Missing Compliance,” and your testers cannot install it until you answer the question in App Store Connect — invites silently don't arrive.
• An App Store submission build won't move forward to review until compliance is resolved, so it sits idle while you think it's queued.
• Because the prompt returns on every upload, a CI/CD pipeline that auto-submits builds gets blocked on every run — a classic “why is TestFlight stuck”.

The fix is the same as above: set ITSAppUsesNonExemptEncryption once in Info.plist (if exempt) so no build ever enters the Missing Compliance state again.

FAQ

Related: Apple privacy manifest (PrivacyInfo.xcprivacy) · App Store submission checklist

Sources

• Apple Developer — Complying with encryption export regulations
• Apple Developer — Export compliance overview
• US Bureau of Industry and Security — Encryption and export administration regulations (EAR §740.17)