ITSAppUsesNonExemptEncryption: What to Set Before You Submit

The encryption key that quietly holds your build in Missing Compliance

Every iOS upload triggers one export-compliance question: does your app use encryption? Skip it or answer it wrong and App Store Connect parks the build in Missing Compliance — a hold that blocks you from sending it to review until you resolve it. The whole thing comes down to one Info.plist key, ITSAppUsesNonExemptEncryption, but setting it correctly means knowing which kind of encryption your app actually ships.

What does ITSAppUsesNonExemptEncryption do?

It is a Boolean key in your app's Info.plist that tells App Store Connect whether your app uses encryption that is not exempt from U.S. export regulations (the EAR, administered by the Bureau of Industry and Security).

<!-- Info.plist: most apps that only use HTTPS can set this to false -->
<key>ITSAppUsesNonExemptEncryption</key>
<false/>

• Set it to false, and App Store Connect stops asking on every upload and lets the build move straight to review.
• Set it to true, and you confirm non-exempt encryption, which can trigger documentation requirements.
• Omit it, and App Store Connect asks manually for each build — and holds it in Missing Compliance until you answer.

Can you set it to false?

Most apps can. Apple treats several common categories of encryption as exempt:

Encryption in your app	Exempt?	Typical value
HTTPS / TLS to your backend	Yes	false
Apple's built-in crypto via system APIs	Yes	false
Authentication, signing, integrity checks only	Yes	false
Standard, mass-market encryption	Usually	false
Custom or proprietary cipher you implemented	No	true
Bundled crypto library with its own algorithms	No	true
End-to-end encryption you built yourself	No	true

If your app only uses encryption from the exempt rows — true for most apps that just talk to a backend over HTTPS — you can set the key to false.

When does "true" mean more paperwork?

If your encryption is genuinely non-exempt, U.S. rules may require an annual self-classification report to BIS, and in some cases a CCATS classification. Apple surfaces this through a second key, ITSEncryptionExportComplianceCode, where you enter the export code Apple issues once your documentation for the year is on file. This is a legal classification, not a technical one — if you ship custom cryptography and you are unsure, get export-compliance advice rather than guessing.

Why is this a pre-submission problem, not a review problem?

ITSAppUsesNonExemptEncryption never reaches a human reviewer — it gates the build before review. A wrong or missing value does not come back as a polite rejection days later; it silently parks your build in Missing Compliance the moment you upload, usually discovered when someone goes to submit and can't. On a release day, that is exactly the kind of small, technical, avoidable delay that resets your timeline.

Because the key lives in the compiled Info.plist and the cryptography lives in the linked binary, this is detectable before you ever upload. Binary analysis can confirm three things:

1. The ITSAppUsesNonExemptEncryption key is present and set.
2. Its value is consistent with the cryptographic libraries actually linked into the binary.
3. You are not declaring false while shipping a non-exempt crypto SDK — the mismatch that turns into a problem later.

AppCompliance checks the encryption declaration as part of its iOS binary scan, alongside privacy manifest validation and SDK inventory, and can gate it in CI before upload. It tells you which cryptographic code is in your binary and whether the declaration is missing or inconsistent — it does not make the legal export-classification decision for you.

Summary

• ITSAppUsesNonExemptEncryption answers Apple's export-compliance question in the Info.plist.
• Only HTTPS and standard Apple crypto? Set it to false.
• Custom or proprietary encryption? Set it to true and keep your export documentation current.
• Make sure the value matches the crypto actually linked in the binary.
• Set it once, set it correctly, and the encryption question stops being a release-day surprise.