How do you bypass Export Compliance in App Store Connect?

If App Store Connect keeps flagging your TestFlight build with a Missing Compliance warning, the fastest path out is not in the web form. It is a single line in Info.plist. You answer the question once at build time, the build reaches your testers without manual intervention, and every later submission carries the same answer.

Short answer

The Export Compliance prompt asks every new build whether your app uses encryption that falls under U.S. export controls. You skip the prompt by adding the ITSAppUsesNonExemptEncryption key to your Info.plist, set to false if your app only uses operating system encryption such as HTTPS via URLSession, or true if your app ships its own cryptography. The declaration is binding, not a UI bypass. Apple still expects accurate answers, and a wrong false is a regulatory issue rather than a review issue.

What you should know

• The Export Compliance prompt blocks TestFlight first, not the binary upload. Without an answer, the build sits in App Store Connect under Missing Compliance and external testers cannot install it.
• ITSAppUsesNonExemptEncryption is the Info.plist key that answers the prompt upfront. Apple's documentation on encryption export regulations lists the key as the supported way to declare your status at build time.
• HTTPS via URLSession counts as exempt encryption. Apple states that encryption built into the operating system, including HTTPS connections handled by URLSession, is exempt from export documentation requirements.
• Apps that ship their own cryptography are not exempt by default. Custom AES routines, end-to-end messaging libraries, on-device password vaults, and VPN tunnels typically need a true value plus an annual self-classification report to the Bureau of Industry and Security.
• The declaration is binding under 15 CFR Part 740.17. A false answer that should have been true is a regulatory exposure, not just a build setting error.

How do you add ITSAppUsesNonExemptEncryption to Info.plist?

Open your Xcode project, select your app target, click the Info tab, and add a new key. The raw key name is ITSAppUsesNonExemptEncryption and the value type is Boolean. Set it to NO if your app uses only operating system encryption, or YES if it uses anything beyond that.

If you maintain Info.plist as source-controlled XML, the entry looks like this:

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

For Expo apps, add the value under ios.config in app.json or app.config.js, then run prebuild so the native Info.plist is regenerated. For FlutterFlow, set it inside the iOS Custom Settings section of the project so each export carries the key. For Capacitor, edit the generated Info.plist in ios/App/App/Info.plist before each build. Apple's Help page on export compliance confirms that an Info.plist value overrides the App Store Connect prompt, which is why the question disappears for every later upload.

The key is read at upload time, so a change requires a fresh archive and a new build number. Editing the plist after Apple has accepted a build does not retroactively change the prior declaration.

What does the Export Compliance prompt in App Store Connect actually ask?

The short answer is whether your app contains, accesses, or implements encryption that requires U.S. export documentation. The prompt sits in App Store Connect under the build details for any newly uploaded binary, and it must be answered before the build can flow to external TestFlight testers or to the public App Store.

Apple's overview of export compliance explains that any app you submit for distribution outside the United States and Canada counts as a U.S. export under federal regulations. The Bureau of Industry and Security treats encryption inside an exported app as a controlled commodity, which is why the question exists at all.

In practice, three answers are possible. The app uses no encryption at all. The app uses encryption that qualifies for the export exemption under 15 CFR Part 740.17. The app uses encryption that requires a self-classification report or a Commodity Classification Automated Tracking System (CCATS) ruling. The first two answers map to the same Info.plist value (false). The third maps to true and pulls in the annual report obligation.

When is false the correct value and when is it not?

The honest answer is that false is correct for most consumer apps built on standard iOS APIs. If your code calls URLSession, makes HTTPS requests, uses Sign in with Apple, accepts payments through Apple Pay, or talks to Firebase, Supabase, Stripe, or AWS through TLS handled by the system, the encryption you rely on is exempt.

False stops being correct when your build does any of the following: implements its own symmetric or asymmetric cryptography (custom AES, ChaCha20, RSA), ships an end-to-end messaging layer with key exchange controlled by your code (Signal Protocol, MLS, custom Diffie-Hellman), acts as a VPN endpoint or tunnels traffic through proprietary cipher logic, encrypts data at rest using a routine you wrote rather than CryptoKit or Keychain, or embeds a third-party SDK that does any of the above.

The App Store Connect export compliance overview lists standard encryption algorithms inside Apple's operating system as exempt and proprietary or non-standard encryption algorithms as non-exempt. Both can sit inside the same build, which is why the rule is binary rather than scoped per feature.

Does the key cover TestFlight, App Store, and Mac Catalyst the same way?

Yes, the key applies to every distribution channel App Store Connect handles, including TestFlight internal, TestFlight external, the App Store, and Mac Catalyst builds promoted into the Mac App Store. The same Info.plist value carries through because App Store Connect reads it from the build's plist at upload time. Apple's App Store Connect Help on export compliance confirms the value persists across submissions for the same build.

This matters because the Missing Compliance flag is most painful at TestFlight. App Store binaries can sit in the review queue for days, so a missing answer only delays a release window. External TestFlight, in contrast, blocks immediately. Testers cannot install the build, the issue surfaces hours before a demo, and the founder is left filling out a web form during a customer call. Adding the key once removes that friction permanently from the project.

The limit is Mac apps distributed outside the Mac App Store. Notarization through Developer ID does not read ITSAppUsesNonExemptEncryption. Export compliance for those builds is the developer's direct responsibility under federal regulations, not handled by the App Store Connect prompt at all.

What annual report does Apple still require if your app uses non-exempt encryption?

If you answer true, U.S. regulations require an annual self-classification report filed with the Bureau of Industry and Security (BIS) under the Encryption Registration Number (ERN) framework. Apple's encryption export regulations page describes the obligation. The report is due by February 1 each year for builds distributed in the previous calendar year, and it lists product information, the encryption used, and the export classification numbers.

For most consumer apps in this lane, the ERN path is enough. Apps that ship cryptography beyond the standard mass-market thresholds may need a Commodity Classification Automated Tracking System (CCATS) review from BIS, which is a more formal classification process that can take weeks. The Apple Developer Support contact for export compliance questions is [email protected], which is the right address when you genuinely cannot decide whether the false answer is safe.

Setting true in Info.plist also prompts App Store Connect to ask for a year-end report on your first submission of each calendar year. The form accepts an upload of the BIS confirmation or a reference number. Skipping it triggers a build hold that is harder to clear than a Missing Compliance flag, because Apple treats the regulatory side as a U.S. legal issue and will not release the build until the form is complete.

What to watch out for

The biggest mistake is treating ITSAppUsesNonExemptEncryption as a UI hack rather than a regulatory declaration. Adding false to silence the prompt feels like ticking a checkbox, but the answer is logged against your developer account and your distributed binary. If a customs or BIS audit later finds custom encryption in a build that declared false, the developer is on the hook, not Apple.

The second mistake is forgetting third-party SDKs. A build that uses only HTTPS in your own code can still ship non-exempt encryption inside a vendor SDK. Real-time messaging libraries, payment gateways with on-device encryption, VPN client SDKs, and DRM frameworks change the answer. Audit every SDK on its own merits, not just your code.

The third mistake is assuming the prompt will reappear if you ever change the answer. It will not. Once Info.plist sets the value, App Store Connect honors that build's declaration silently. If your app started as a pure HTTPS client and later added a custom Signal Protocol layer, you must update the plist value before the next upload. The previous build's answer does not carry forward when the cryptography changes.

For builders who want an independent automated check of what their compiled IPA actually contains before they hit upload, PTKD.com is one of the platforms focused specifically on pre-submission scanning aligned with OWASP MASVS, and its reports surface the encryption libraries linked into the bundle, which is the same input regulators care about.

Key takeaways

• Use the Info.plist key, not the App Store Connect prompt. A single ITSAppUsesNonExemptEncryption entry answers the question once for every future build.
• False is correct for most builds that rely on URLSession and Apple cryptographic primitives. True is correct for custom cryptography, end-to-end messaging, VPNs, and DRM.
• A true answer pulls in the annual BIS report by February 1. Apple's prompt does not replace the BIS filing, it sits on top of it.
• Audit third-party SDKs before declaring exemption. A vendor library can change the right answer without changing your code.
• Some teams run an independent build scan with platforms like PTKD.com before submitting, which lists the encryption libraries actually linked into the binary so the Info.plist value matches reality.