Will Apple reject my build if I set ITSAppUsesNonExemptEncryption to NO incorrectly?

Apple does not actively audit the value, so a wrong NO usually passes App Review without comment. The real risk sits with the US Bureau of Industry and Security under the Export Administration Regulation. Apple's own documentation states the developer carries all liability for misinterpretation. For an app shipping a custom crypto library, the correct answer is YES with the matching documentation, not a silent NO.

Does TestFlight have the same Waiting for Export Compliance step?

Yes, with one nuance. The status appears on TestFlight builds the same way it appears on App Store builds, because Apple treats internal and external TestFlight distribution as export under US regulation. Adding the ITSAppUsesNonExemptEncryption key to Info.plist clears it for both. Internal-only TestFlight invitations are lower-risk under the regulation, but Apple still asks for the answer per build.

Do I need the French encryption declaration if I distribute everywhere except France?

No. France's requirement applies only when your app is listed on the French App Store. Apple's overview page is explicit that the French declaration covers import and export of encryption apps distributed in France. If you exclude France in the App Pricing and Availability section, the French declaration drops out of the documentation chain entirely for that release.

Does CryptoKit count as exempt encryption?

Yes. Apple classifies CryptoKit, CommonCrypto, and Keychain Services as part of the operating system, and any use of those frameworks falls under the OS-built exemption. Your app can call AES, ChaCha20, HMAC, or SHA functions from CryptoKit and still answer that the app uses only exempt encryption. The exemption breaks once you embed a non-Apple crypto library to do the same work.

Why is my build still Waiting for Export Compliance after two days, even though I set the Info.plist key?

The Info.plist key only takes effect on builds uploaded after the key was added. A build uploaded before the change keeps the old behavior and stays in Waiting for Export Compliance until you answer the dialog manually in App Store Connect. Rebuild, increment the build number, and re-upload; the new build clears the status automatically if the key is set correctly.

Why is my app stuck on Waiting for Export Compliance?

Name: PTKD
Availability: InStock

Your build uploaded fine, the version page in App Store Connect says Ready for Submission, but the build itself sits with a yellow Waiting for Export Compliance label, and the green Submit button is greyed out. The status looks like a bug. In most cases it isn't. App Store Connect noticed your app uses encryption and is holding the build until you answer a one-time question about US export controls, or until Apple approves a document you uploaded.

Short answer

Waiting for Export Compliance appears when App Store Connect detects encryption in your build and you have not answered the encryption questions for that version. Add the ITSAppUsesNonExemptEncryption key to your Info.plist (Boolean) and the status clears on the next upload. If your app uses non-standard cryptography, you also need a CCATS classification from the US Bureau of Industry and Security and, when distributing in France, a separate French encryption declaration. Apple's documentation review takes roughly two business days.

What you should know

The status is encryption-triggered, not a queue position. App Store Connect needs an answer about US export rules before it lets the build move into App Review.
Most iOS apps qualify as exempt. HTTPS via URLSession, Keychain, and CryptoKit all use OS-built encryption, which Apple treats as exempt.
A Boolean Info.plist key removes the prompt for every future build. Set ITSAppUsesNonExemptEncryption once and the dialog stops appearing at submission time.
France has its own rule. Distributing in France adds a separate French encryption declaration even when the app uses standard algorithms.
Non-standard encryption needs CCATS from BIS. Custom AES variants or unpublished protocols require a Commodity Classification Automated Tracking System ruling.
An exempt app may still need an annual report. US developers may be required to file a year-end Self-Classification Report with BIS for encryption items shipped during the previous calendar year.

What does Waiting for Export Compliance actually mean?

The honest answer is that App Store Connect has run a static check on the build, decided your binary contains encryption code, and noticed you have not declared whether that encryption is subject to US export controls. Until you do, the build stays in this status and you cannot submit it for review.

In practice, the trigger is one of two things. Either you uploaded a build with no ITSAppUsesNonExemptEncryption key in the Info.plist, which leaves Apple unable to know your answer, or you uploaded one where the key value combined with your distribution regions requires a document upload before submission. Apple documents this on the Overview of export compliance page in App Store Connect Help, which lists three triggers: standard encryption algorithms, crypto functionality within Apple's operating systems, and proprietary or non-standard encryption algorithms.

The status applies to a specific build, not your app. If you upload a new build to the same version, the question starts over for that build. The decision is yours to make once for each build, until the Info.plist answer is set permanently.

How do I clear it for a build I have already uploaded?

Two paths, depending on what your app actually does.

Path one is the one-time dialog. Inside App Store Connect, open the version, click Manage next to the build, and answer the encryption questionnaire. If your app uses only HTTPS, Keychain, App Transport Security, or standard system frameworks, the correct answer is that your app uses exempt encryption. The build moves out of Waiting for Export Compliance within a few minutes once the answer is saved.

Path two applies when your app uses anything beyond OS-provided encryption. Apple's Complying with Encryption Export Regulations page defines the categories. If your app embeds a third-party crypto library, an end-to-end encrypted messaging layer, or any proprietary scheme, you select the matching answer and upload the required documentation. Apple states that documentation review takes approximately two business days.

The mistake many developers make is selecting Yes to the non-exempt encryption question because the app technically calls into AES somewhere, when in fact it only uses AES through URLSession or CryptoKit. Those calls are exempt. The question is not whether your app touches encryption; it is whether your app introduces encryption that isn't part of the operating system or a recognized public standard.

How do I make this never happen again?

Add the ITSAppUsesNonExemptEncryption key to your Info.plist. Per Apple's documentation for the key, the value is Boolean. Set it to NO if your app uses only exempt forms of encryption, or YES if you have already uploaded approved documentation for non-exempt encryption and want to attach the resulting key value to every future build.

In a native Xcode project, this is two lines in the source Info.plist or a project-level setting in the Signing and Capabilities tab. In React Native, edit ios/<AppName>/Info.plist directly. In Expo managed workflow, set ios.config.usesNonExemptEncryption in app.json or app.config.js. In Flutter and FlutterFlow, the iOS Info.plist is generated under ios/Runner/Info.plist. Capacitor and Cordova both write to a similar path inside the iOS project.

For builds that include non-exempt encryption and an approved CCATS, Apple returns a key value after the documentation is approved. Adding both the Boolean and the key value to the Info.plist tells App Store Connect to attach the approval automatically to every new build without re-prompting.

Which encryption counts as exempt?

This is where developers lose the most time. The table below maps common iOS code paths to whether they qualify as exempt under Apple's published categories. The exempt cases are documented on Apple's export compliance overview page and cross-reference the US Export Administration Regulation.

Encryption in your app	Category	Documentation needed
HTTPS via URLSession or NSURLConnection	Exempt, built into the OS	None
Keychain reads and writes	Exempt, built into the OS	None
CryptoKit or CommonCrypto (AES, SHA, HMAC)	Exempt, built into the OS	None
TLS for WebSocket or gRPC	Exempt, built into the OS	None
Third-party SDK using standard TLS only	Standard algorithm	French declaration if distributing in France
Signal Protocol or libsodium for E2E messaging	Standard algorithm, non-built-in	French declaration if distributing in France
Custom AES variant, white-box crypto, custom DRM	Non-standard cryptography	CCATS from BIS, plus French declaration
Encrypted local database with proprietary scheme	Non-standard cryptography	CCATS from BIS, plus French declaration

The pattern is straightforward in plain terms. If the encryption lives in Apple's frameworks or in a widely recognized public standard, the app is exempt for US purposes. France adds its own filing on top because the French government separately controls import and export of encryption apps, and Apple lists this requirement explicitly.

What about the annual Self-Classification Report?

US developers who answer that their app uses exempt encryption may still owe an annual filing to the Bureau of Industry and Security. The filing is the Self-Classification Report, and it covers all encryption items exported during the previous calendar year. Apple's export compliance documentation reference flags this requirement and points to the BIS encryption policy guidance for the form itself.

In practice, an indie developer shipping a US app with HTTPS and Keychain is unlikely to fall into a category that triggers enforcement, but the obligation is on the developer to read the regulation and decide. Apple is clear that any misinterpretation is on the developer, not on Apple. Treat the Self-Classification Report as a once-a-year checklist item if your app uses any form of encryption beyond the most minimal HTTPS request.

For builders who want a pre-submission read on what their compiled IPA actually links against, including which SDKs introduce non-OS encryption, PTKD.com (https://ptkd.com) is one of the platforms that surfaces SDK-level crypto usage alongside hard-coded secrets and missing privacy manifests in a single OWASP MASVS-aligned report.

What to watch out for

The build status is per build, not per app. Re-uploading triggers the question again unless the Info.plist key is set.
Setting ITSAppUsesNonExemptEncryption to NO when your app actually ships a custom crypto library is a regulatory violation, not just an Apple policy issue. The Bureau of Industry and Security can pursue penalties separately.
France is a common silent trap. If your app is available in France and uses any encryption beyond OS-built, you owe the French declaration even when the US side is fully covered.
Some teams set the key to NO on every project by reflex. Audit it once: if the project ever added libsodium, OpenSSL, BoringSSL, a wallet SDK, or a custom messaging layer, NO is wrong.
Apple's two-business-day estimate for documentation review is directional, based on patterns reported by developers. Threads on the Apple Developer Forums show longer waits around US government holidays.
The status can also linger because of a cache delay between App Store Connect and the build processing system. With the Info.plist key set correctly, give it up to 24 hours before opening a Developer Technical Support ticket.

Key takeaways

Waiting for Export Compliance means App Store Connect needs an encryption answer for the build. It is not a queue position and it is not a rejection.
For most apps using only HTTPS, Keychain, and standard system frameworks, the answer is exempt, and the lasting fix is a single Info.plist Boolean.
Non-standard encryption requires a CCATS from BIS and, in France, a separate French declaration. Apple's documentation review then takes about two business days.
A year-end Self-Classification Report may apply to US developers even when the app uses exempt encryption only; check the BIS guidance once per year.
Some teams use platforms like PTKD.com (https://ptkd.com) to scan the compiled IPA before submission, so they know which SDKs introduce non-OS encryption and whether their export compliance answer matches what the binary actually does.