App Store export compliance is one question, and for most apps the answer is yes we use encryption, and yes it is exempt.
App Store export compliance is the question Apple asks before a build goes anywhere, and for most apps it resolves to one Boolean. If your app sends anything over HTTPS then it uses encryption, so the honest answer to does my app use encryption is yes. What saves you is the exemption, not a denial. Set ITSAppUsesNonExemptEncryption to NO in your information property list and App Store Connect stops asking on every upload. That NO does not mean no encryption. It means no encryption that is outside the exemption, which is a narrower and more defensible claim. This is the compliance step inside publishing to the App Store.
Every step, field name, document and timing below was taken from Apple's and Google's own documentation, read on 3 October 2026, with the screens named as they are named today. The two stores are not symmetrical, and that asymmetry is the second useful thing here. Apple turns export law into a field that can hold your build. Google asks nothing about encryption and leaves the law to you.
Work out which answer applies to youThe short version
Say yes to encryption and no to non-exempt encryption.
Those are two different questions, and almost all of the confusion on this topic is people answering the first one when the field is asking the second. Apple's property list key is named for the second: it asks whether you use encryption that is not exempt. An app whose only cryptography is the HTTPS the operating system provides answers NO and uploads nothing.
The answer changes the moment you add cryptography of your own. A library you bundled that implements a standard algorithm, or anything proprietary or unpublished, moves you into the part of the flow where Apple wants documents. That is a real upload with a real wait, so it is worth knowing which side of the line you are on before the evening you planned to ship.
The key, the value, and what NO actually claims
Add ITSAppUsesNonExemptEncryption to your app's information property list as a Boolean. Apple's page on complying with encryption export regulations, read on 3 October 2026, is precise about the value. Set it to NO if your app, including any third-party libraries it links against, either does not use encryption or only uses forms of encryption that are exempt from export compliance documentation requirements. Otherwise set it to YES. The spelling matters, and Apple publishes no alternative key that does the same job.
The phrase doing the work in that sentence is third-party libraries it links against. Your own source can contain no cryptography at all while a dependency three levels down links something that does. The claim covers the whole binary, not the files you wrote, which is why the honest first move is to read your dependency list rather than your own code.
Apple is specific about the common case. It says that typically, the use of encryption built into the operating system, for example when your app makes HTTPS connections using URLSession, is exempt from export documentation upload requirements, whereas the use of proprietary encryption is not. Note the word typically. Apple does not publish a blanket rule that every app using HTTPS is exempt, and the determination stays yours.
Leaving the key out breaks nothing. It just costs you the same minutes on every upload. Apple's page says App Store Connect asks you these questions every time you submit a new version, and that providing the information in the property list bypasses them. If you do end up supplying documents and Apple clears them, Apple returns a code, and that string goes in a second key, ITSEncryptionExportComplianceCode.
Apple Developer, Complying with Encryption Export Regulations, read 3 October 2026
Which of the three cases you are in
Apple's App Store Connect Help splits apps into three cases by what the encryption actually is, and the case decides the paperwork. Its reference table was read on 3 October 2026. First case: encryption limited to what sits inside Apple's operating system. That needs no documentation in App Store Connect at all. Second case: an industry standard algorithm that Apple's operating system does not provide. That needs a French encryption declaration, and only if you distribute in France. Third case: proprietary algorithms not accepted by international standards bodies such as IEEE, IETF or ITU. Those need a US Commodity Classification Automated Tracking System classification, a CCATS, plus the French declaration where France applies.
Apple does not publish a property list value for that middle case, so this page will not supply one. If you bundled a standard crypto library, answer the questions in App Store Connect and use the result rather than copying a value out of a tutorial. The value is a statement about export law with your name on it, and Apple's own overview page puts the liability for misreading the export regulations, or for claiming an exemption you do not have, on you.
Two practical notes. Apple says that if your app uses exempt forms of encryption, you might instead be required to submit a year-end self-classification report to the US government. Apple adds that the report is not necessary if you used non-exempt encryption and gave Apple documentation. None of this is testable on a simulator or on a device, because it is metadata in a web console rather than anything in your build. The one thing worth checking on real hardware is that your network calls really are HTTPS and that nothing is quietly falling back to plain HTTP, which is where app security basics begins.
Work it out
Which export compliance answer applies to you
Pick the strongest cryptography anywhere in the binary, including every library you link against.
ITSAppUsesNonExemptEncryption: NO
Nothing to upload to App Store Connect, and nothing to file with Google. Set the key once and App Store Connect stops asking on every upload.
Where the question lives in App Store Connect today
The export compliance App Store Connect asks about sits in two places, and both were confirmed in Apple's App Store Connect Help on 3 October 2026. The per app route: in Apps, select the app, click App Information in the sidebar, then click the add button next to App Encryption Documentation and answer the questions in the dialogs. The per build route: click Manage beside the build that is missing app encryption information, on either the Distribution tab or the TestFlight tab. Those are the tab names in Apple's help today. If a walkthrough sends you to an App Store tab instead, it predates this layout.
The TestFlight path has its own help page and its own vocabulary. A build with no encryption information is marked Missing Compliance. From the TestFlight tab you pick the platform under Builds, click the build in the Build column, then click Provide Export Compliance Information and answer the questions. If documents are needed there is a Go to App Encryption Page button that takes you there. The required role for both routes is Account Holder, Admin or App Manager, so a developer on someone else's team may not be able to clear this at all.
Apple does not publish the wording of the questions, which is exactly why you answer them in the console instead of from memory. It does publish a timing expectation for the documents: if you provide complete information, Apple expects to review and clear apps in approximately two business days. Apple also says to fill in the App Description and set your app's availability before uploading encryption documents, because without that it cannot judge whether the documents are sufficient. That ordering is easy to miss while working through the rest of the app store requirements.
Google asks you nothing, which is not the same as nothing applying
There is no encryption questionnaire on Google Play and no Android manifest key that answers one. Play Console Help's export compliance page, read on 3 October 2026, explains why the law still reaches you. Your application is hosted on Google servers. Google is a US company, and the US government considers it an export when someone outside the US downloads software from those servers. The page says this holds even if you are not in the US and not a US national, and that an app can be subject to the regulations even if you open sourced it.
Google does two things instead of asking. It takes a one-time acknowledgement of a US export laws declaration in the Declarations section when you create the app in Play Console. And it enforces the embargo itself: the page says Google Play applications may be prohibited from transfers to embargoed countries and that Google blocks downloads to those countries. Beyond that it states plainly that it is up to you to determine your compliance requirements, and points at the US Bureau of Industry and Security rather than collecting anything from you.
The page also makes the point that catches people out on both stores. Even if your app contains no crypto library, it may call crypto functionality in another program. There are separate regulatory categories for publicly available, authentication, digital signature, mass market and ancillary encryption software, each with different rules. Google does not tell you which one you are in. Apple does not either. It only asks you to declare the result.
So the practical shape for a cross-platform app is simple. Do the classification once, for Apple, because Apple is the one with a field that can hold a build. You then already know what you are acknowledging in Play Console. Clearing compliance is one green field among several, and the queue it unlocks, the statuses you will see and the mail that arrives are what happens after you submit.
Google Play Console Help, Export compliance, read 3 October 2026
Export compliance, App Store against Google Play
| What export compliance involves | App Store and TestFlight | Google Play | How often you deal with it |
|---|---|---|---|
| An encryption question at submission | Asked on every new version unless the property list key answers it | Not asked | Every version, or never |
| A key in the app that answers it in advance | ITSAppUsesNonExemptEncryption, a Boolean | No equivalent key published | Set once |
| Documents the store collects from you | CCATS for proprietary crypto, and a French declaration if you distribute in France | None collected | Only when the crypto is not the operating system's |
| A code the store issues back to you | ITSEncryptionExportComplianceCode, after Apple clears your documents | None | About two business days for Apple to clear complete documents |
| An account level declaration | Not part of this flow | US export laws, in Declarations when you create the app | Once, at app creation |
Where this lands if something else uploaded the build for you
Export compliance is metadata, not code, so it does not matter who wrote the app. It matters who holds the App Store Connect account, because the answer has to be given there by an Account Holder, Admin or App Manager. A build nobody answered for sits marked Missing Compliance however it was produced.
Newly is an AI app builder. You describe an app in plain English and it writes a real React Native and TypeScript project you own. It runs the app on cloud iOS and Android simulators while it builds, then ships it to App Store Connect and TestFlight and to Google Play internal testing. It is $25 a month on effort-based credits and there is no free plan. It uploads the build. It does not submit the app for review, because Apple's guideline 4.2.6 puts submission in the hands of the person whose app it is. Export compliance sits on the same side of that line. You answer it, in your own account, under your own name.
Because the project is yours, the property list key is yours to set once and forget. Ask the agent for it, or take the code out as a ZIP from project Settings or through the two-way GitHub sync under Deploy and set it by hand. Either way, set it before the first upload rather than after a build comes back flagged, and read your dependency list first so the value you set is one you can stand behind.
Questions people ask about App Store export compliance
Yes. HTTPS is encryption, so an app that makes any HTTPS request uses encryption. The question that decides your paperwork is narrower. Apple says that typically, encryption built into the operating system, for example HTTPS connections made with URLSession, is exempt from export documentation upload requirements, while proprietary encryption is not. That wording is from Apple's own page, read on 3 October 2026.
Set the key before the first upload
Read your dependency list, then decide which of the three cases your app is in. Set the property list key to match. Leave yourself the two business days if documents are involved, rather than finding out on the evening you planned to ship.
Start building