Why does every app submission ask about encryption?

Every time you send a build to App Store Connect, there's a question waiting for you before it can go to review: does your app use encryption, and is it exempt from export regulations? Most developers click through it the same way every time, without knowing what it's actually asking or who's asking it. It isn't Apple's question. It's the U.S. government's, and Apple is just the one required to relay it.

It's export control law, not app review

The question exists because of the Export Administration Regulations (EAR), enforced by the Bureau of Industry and Security (BIS) at the Department of Commerce. Cryptography has been treated as a controlled technology under U.S. export law since the Cold War, and that classification never fully went away — it just got a lot more permissive for the kind of encryption almost every app uses. When Apple or Google distributes your binary to a device outside the U.S., that's legally an export, and the law requires the developer — not the platform — to classify what's being exported.

That's why the prompt shows up per build on iOS: Apple isn't trying to slow you down, it's declining to accept legal liability for a classification only you can make.

What the plist key actually does

On iOS the question maps to a real Info.plist key: ITSAppUsesNonExemptEncryption. Leave it out and every archive you upload sits in "Missing Compliance" until someone answers the question by hand in App Store Connect — a hold that blocks the build from going to review at all. Set the key once in your plist and you never see the prompt again, because you've already told Apple the answer in code:

Set it to false if your app's only encryption is what the OS gives you for free — HTTPS via URLSession, TLS from a standard networking library, the Keychain, APNs. That covers the overwhelming majority of apps, including anything built with Flutter, React Native, or a typical native networking stack. This isn't a loophole — it's an explicit exemption (5D992(c) in the regulation) for encryption that's "for the sole purpose of protecting" the app's own data, using standard, publicly available algorithms you didn't write yourself.

Set it to true only if you shipped your own cryptographic implementation, or you're bundling encryption whose primary purpose is something other than protecting the app's own operation — a VPN, an end-to-end encrypted messenger, a cryptocurrency wallet doing its own key management. If that's you, the plist key alone doesn't finish the job; keep reading.

The rare case where there's real paperwork

If your app is non-exempt, U.S. exporters of qualifying encryption items are required to file an annual self-classification report with BIS, covering everything exported in the prior calendar year, due by February 1. Some encryption categories need a one-time CCATS (Commodity Classification Automated Tracking System) submission or a self-classification report before you can even answer "exempt" in the first place — the BIS site's encryption controls guidance walks through which category your app falls into.

This is genuinely rare. If you're using TLS to talk to your own API and nothing else, you are not the audience for CCATS filings — you're the audience for the plist key above. Don't let a forum thread about export licenses talk you into filing paperwork you don't need.

The France wrinkle nobody expects

Separately from U.S. export law, France classifies cryptography as a controlled "means of cryptology" under its own decree (n°2007-663), and the threshold is lower than the U.S. one — standard HTTPS, Keychain, or CryptoKit usage can trigger it. If your app is distributed in France, App Store Connect may ask for a declaration filed with the French cybersecurity agency (ANSSI, at [email protected]) regardless of how you answered the U.S. export question. It's a separate government, a separate form, and a separate mailbox — exemption from one doesn't exempt you from the other.

Where Google Play differs

Play Console doesn't gate submission on a per-build encryption prompt the way App Store Connect does. The same U.S. export law still technically applies — downloading from Google's servers outside the U.S. is still an export — but Google doesn't put a compliance hold in your publishing pipeline over it. What Play does require is the Data Safety section, which asks whether data is encrypted in transit; for any app talking to its backend over HTTPS, that's a straightforward "yes." The legal obligation to classify your encryption under EAR sits with you either way — Google's console just doesn't enforce it at upload time.

Answering it doesn't get easier with automation

Tools that publish straight to App Store Connect — ShotCanvas's build manager included — can automate the chunked upload, the metadata, the screenshot sets. Export compliance isn't one of those things: only you know what's actually in your binary, so it's one of the few fields in the submission flow that has to stay a deliberate, one-time answer from the developer, not something a client tool guesses on your behalf.