Every time we push a build to App Store Connect, the export compliance questions appear before the submission can move forward. For the first few apps we shipped at Olnesta Ltd, we clicked through them slowly, re-reading the same wording on each release and hoping we were answering consistently. Eventually we sat down with the actual rules, worked out what our apps do, and set the answer in Info.plist so we stop being asked. That's the piece we want to write down here, because it's one of those recurring friction points that has a clean resolution once you understand what's being asked.
The questions exist because apps distributed from the U.S. are subject to U.S. export regulations on encryption. Apple asks on Apple's behalf and on yours. The relevant point for almost everyone reading this: standard HTTPS and TLS count as encryption. If your app talks to any backend, loads remote images, uses a third-party analytics SDK, or hits a JSON endpoint over https://, you are using encryption for the purposes of this question. The answer to "does your app use encryption" is yes, even though nothing in your own source code performs a cryptographic operation.
Exempt versus non-exempt
The useful distinction is between encryption that's exempt under U.S. export law and encryption that isn't. In broad terms, apps that only use encryption that's already built into the operating system, or that only use standard protocols like HTTPS/TLS for things like authentication and secure transport, generally fall into the exempt category. Apps that implement their own cryptography, or use encryption for purposes beyond what the exemption covers, are the ones that need to look more carefully.
When an app qualifies as exempt, the practical outcome is that you can self-classify and proceed without filing a separate report. When it doesn't, the path typically involves a French declaration (France has its own encryption import rules that apply to apps distributed there) and, depending on the case, an annual self-classification report submitted to the U.S. Bureau of Industry and Security. Apple's own documentation on export compliance walks through the categories and links to the underlying regulations, and it's the source we go back to whenever we're uncertain about a specific app. If the app is doing anything more interesting than standard transport encryption, that documentation is where the decision should be made, not a blog post.
For our own apps so far, every one has fallen into the exempt bucket because none of them do anything more than talk to services over HTTPS. That's the common case for a small studio shipping utility and content apps, and it's worth confirming rather than assuming.
Setting the Info.plist key once
The part that saves real time on every submission is ITSAppUsesNonExemptEncryption. It's a Boolean in Info.plist. When it's set, App Store Connect stops asking you the top-level encryption question on each build, because you've already declared the answer as part of the app itself.
For an app that only uses standard HTTPS and qualifies as exempt, we set it to false. For an app that uses non-exempt encryption, you set it to true and then work through the additional documentation flow on the App Store Connect side, which is where the French declaration and any annual reporting comes in.
One detail worth naming: false here does not mean "the app uses no encryption at all." It means the app does not use non-exempt encryption. That wording tripped us up the first time. If your app makes HTTPS calls and nothing else cryptographically interesting, false is the correct value, and Apple's documentation explicitly treats standard transport encryption as covered by the exemption.
We add the key when the target is first created, alongside the other keys that never really change over the life of a project. After that, the export compliance step at submission is silent for that build, which removes one place where a tired human can click the wrong radio button on a Friday afternoon.
Where this gets less clear cut is with apps that pull in SDKs whose cryptographic behaviour you don't fully control. In our experience the honest move there is to read what the SDK actually does, not to assume, and to widen the answer if the app has genuinely moved out of the exempt category. The Info.plist key is a declaration, and it should reflect the app as it currently ships, not the app as it shipped two years ago before you added a feature that changed the answer. Reviewing it at the start of any release that touches networking or security is a small habit that keeps the paperwork honest.