The Export Compliance Information Required prompt appears because your build did not declare how it uses encryption, and App Store Connect needs that answer before the build can go to review or to external TestFlight. The question is not really whether your app uses encryption, since almost every app does through HTTPS, but whether that encryption is exempt. HTTPS and the encryption provided by Apple's operating system are exempt, so most apps answer that they qualify for the exemption. You answer that you use non-exempt encryption only if you added your own proprietary cryptography, such as a custom algorithm or a VPN tunnel, which brings a documentation obligation. Declaring it once with the ITSAppUsesNonExemptEncryption key stops the prompt from returning on every submission.
Short answer
This prompt is a required declaration, not a rejection, and you clear it by correctly answering whether your app uses non-exempt encryption. Per Apple's encryption export documentation, encryption that is standard and provided by the operating system, including HTTPS handled by the system, is exempt, while proprietary or non-standard cryptography you add yourself is non-exempt. So an app that only relies on HTTPS and Apple's built-in crypto answers that it qualifies for the exemption. You can record the answer permanently with the ITSAppUsesNonExemptEncryption key in Info.plist, set to NO for exempt or no encryption, so App Store Connect stops asking on each build.
Where you see this prompt and what it blocks
You encounter Export Compliance Information Required in App Store Connect, on the build itself, when you try to submit it for review or make it available to external TestFlight testers. Until you answer the encryption question for that build, it cannot move forward, so the prompt is a gate on the build rather than a problem with your app as a whole. The field lives in the build's export compliance section, and App Store Connect surfaces it as a required step during submission.
It helps to know what it does and does not affect. The prompt holds the specific build until answered; it does not remove or penalize an already-live version of your app, and answering it is a form-filling step, not a review outcome. So the pressure it creates is only that a build you want to test or ship is waiting on a declaration, which you can supply directly in App Store Connect or, better, bake into the build so the gate never appears.
The real question: is your encryption exempt?
The reason this prompt confuses people is that they read it as does your app use encryption and answer yes in a panic, when the question that matters is whether the encryption is exempt. Practically every modern app uses encryption, because any network call over HTTPS is encrypted, so a plain yes or no about encryption is not the useful distinction. Apple's framework is built around exemptions: certain common, standard uses of encryption are exempt from the documentation that non-standard cryptography requires.
So reframe the decision. The question is not whether encryption is present but whether your app relies only on the exempt kinds, mainly HTTPS and the cryptography the operating system provides, or whether it also includes non-exempt cryptography that you brought yourself. Once you frame it that way, most apps fall clearly on the exempt side, and the small number that added their own encryption know they did. Answering correctly is a matter of identifying which of those two situations you are in.
HTTPS and OS encryption are exempt
If your app only encrypts through HTTPS and the standard cryptography Apple's system provides, it qualifies for the exemption, and this covers the large majority of apps. HTTPS handled by the system, for example through URLSession, is exempt, and so is the encryption built into iOS that you call through standard APIs, such as Keychain, the Data Protection classes, and standard algorithms exposed by the platform. Using these is not what the export documentation is aimed at, so relying on them means you answer that you do not use non-exempt encryption.
This is why HTTPS usage on its own does not make you non-exempt. An app that logs in over HTTPS, calls an API over HTTPS, and stores a token in the Keychain is using only exempt encryption, so it qualifies for the exemption and you set ITSAppUsesNonExemptEncryption to NO. The practical test is whether every bit of encryption in your app comes from the system or standard algorithms rather than from a custom scheme, and for most apps the honest answer is yes.
What counts as non-exempt encryption
Non-exempt encryption is cryptography you add beyond what the operating system provides through standard means, and it is what actually triggers the documentation obligation. Examples include implementing your own encryption algorithm, shipping a custom or proprietary cryptographic protocol, building end-to-end encrypted messaging with your own crypto, an on-device password vault using non-standard encryption, or a VPN tunnel your app implements. In these cases you are doing more than calling HTTPS and the system libraries, so the exemption does not automatically apply.
If that describes your app, you answer that you use non-exempt encryption and set ITSAppUsesNonExemptEncryption to YES, and you take on the extra compliance step that comes with it. The line to watch is standard versus proprietary: using a well-known algorithm through Apple's own APIs is generally exempt, while implementing encryption yourself or using non-standard cryptography is what pushes you into non-exempt territory. Being honest here matters, because the declaration is a legal statement about your app.
How to answer at a glance
Matching what your app actually does to the right answer is the whole task. The table below maps it.
| Your app's encryption | Exempt? | How to answer |
|---|---|---|
| Only HTTPS network calls | Yes | Qualifies for exemption; key set to NO |
| Keychain and standard iOS crypto | Yes | Qualifies for exemption; key set to NO |
| No encryption at all | Yes | No non-exempt encryption; key set to NO |
| Your own or proprietary algorithm | No | Uses non-exempt encryption; key set to YES |
| Custom end-to-end or VPN crypto | No | Uses non-exempt encryption; key set to YES |
Read the exempt column as the deciding factor: only proprietary or non-standard cryptography you add yourself makes you non-exempt.
Set ITSAppUsesNonExemptEncryption to stop the prompt
Answering the prompt once per build is tedious, so the durable fix is to declare your encryption use in the build itself with the ITSAppUsesNonExemptEncryption key in your Info.plist. Set it to NO if your app uses no encryption or only exempt encryption, which is the common case, and App Store Connect no longer shows the export compliance prompt for those builds. Set it to YES if your app genuinely uses non-exempt encryption, which keeps the correct declaration attached and routes you to the documentation step.
Build tools make this easy to apply consistently. Whether you set the key by hand in Xcode, through your project configuration, or in a managed build with a tool like Fastlane or Expo EAS, the key travels with every build so the answer is recorded before upload. That removes the recurring prompt and, more importantly, makes your compliance answer a deliberate, version-controlled decision rather than a rushed click during submission.
If you use non-exempt encryption: the documentation
Answering yes carries an obligation beyond the toggle, because non-exempt encryption is subject to U.S. export documentation. In that case you either provide the appropriate compliance documentation to Apple, or you file the annual self-classification report to the U.S. Bureau of Industry and Security, which is due at the start of the year, by February 1. Apple lets you upload export compliance documentation in App Store Connect, and once your documentation is on file you are not prompted for it on every build.
The point is to plan for this if you ship your own cryptography, rather than discovering it at submission. Gather what your encryption is and confirm whether it needs a self-classification report or a specific authorization, and keep the documentation with your release process. For the exempt majority, none of this applies, which is exactly why answering the exemption question correctly matters: it separates the apps that owe paperwork from the many that do not.
Fix checklist
Working through these steps clears the prompt correctly. The checklist below covers them.
| Step | Action | Done? |
|---|---|---|
| Identify your encryption | List every place the app encrypts data | [ ] |
| Check the exemption | HTTPS and OS crypto are exempt | [ ] |
| Answer honestly | Non-exempt only if you added proprietary crypto | [ ] |
| Set the Info.plist key | ITSAppUsesNonExemptEncryption NO or YES | [ ] |
| Prepare documentation | If YES, plan the self-classification report | [ ] |
| Automate it | Set the key in your build so the prompt stops | [ ] |
The step teams skip most is setting the Info.plist key, which is what turns a repeated submission prompt into a one-time, version-controlled answer.
Where a scan fits
Answering correctly depends on knowing what cryptography your app actually contains, and that is easier to see when you can inventory it rather than guess.
A scanner like PTKD.com analyzes your build and reports where and how it uses cryptography, along with issues such as weak or hardcoded keys and over-broad permissions, by severity and mapped to OWASP MASVS. To be clear about the boundary: PTKD does not file your export declaration or set your Info.plist key. It helps you see whether your app relies only on standard, exempt encryption or ships something proprietary, so your answer to the export compliance question is based on what the app really does.
What to take away
- Export Compliance Information Required is a declaration that gates the build, not a rejection, and it does not affect an already-live version of your app.
- The real question is whether your encryption is exempt, not merely whether encryption is present, since almost every app encrypts through HTTPS.
- HTTPS and the standard cryptography Apple's system provides are exempt, so most apps answer that they qualify for the exemption.
- You use non-exempt encryption only if you added proprietary or non-standard cryptography, such as a custom algorithm or a VPN tunnel, which requires export documentation or an annual self-classification report.
- Set ITSAppUsesNonExemptEncryption in Info.plist to stop the prompt recurring, and a tool like PTKD.com helps you see what cryptography your app actually contains.
