Your app uses HTTPS, so it already triggers an export-compliance question

Every upload to App Store Connect ends with a legal question developers click through on muscle memory: does the app use cryptography. The instinctive answer is "no, it is just a finance app," and the legally correct answer is yes. HTTPS is cryptography, the operating system's Keychain is cryptography, and the question exists because uploading a binary is, under US law, an export.

Why a file upload is an export

Apple's documentation states it without hedging: "When you submit your app to TestFlight or the App Store, you upload your app to a server in the United States. If you distribute your app outside the U.S. or Canada, your app is subject to U.S. export laws, regardless of where your legal entity is based." And encryption counts broadly: an app that "uses, accesses, contains, implements, or incorporates encryption" is an export of encryption software, subject to US rules and the import rules of every country you sell in. That is the whole reason the questionnaire exists: "Every time you submit a new version of your app, App Store Connect asks you questions to guide you through a compliance review," and providing the answer inside your app's Information Property List file makes it stop asking.

The one key that ends the questionnaire

The required information is one Boolean. ITSAppUsesNonExemptEncryption set to NO declares that your app, "including any third-party libraries you link against," uses no encryption or only encryption that is exempt from documentation requirements. Apple's own guidance on what is exempt: encryption "built into the operating system," with HTTPS connections through URLSession as the given example, is "exempt from export documentation upload requirements, whereas the use of proprietary encryption is not." Apple opens that sentence with "typically," and the hedge matters: the determination is yours, not Apple's. An app that does HTTPS through the platform APIs, stores credentials in the Keychain, and signs in users sits on the exempt side for the ordinary case.

<key>ITSAppUsesNonExemptEncryption</key>
<false/>
<!-- and when the answer is YES, the companion key carries
     the code apple issues after reviewing your documents -->
<key>ITSEncryptionExportComplianceCode</key>
<string>xxxx-xxxx-xxxx</string>

Set it to YES and Apple expects a second key, ITSEncryptionExportComplianceCode, carrying a code issued after it reviews the export documentation you upload to App Store Connect. Missing the key entirely does not stop the submission; it just re-asks the same questions on every single upload, forever.

When exempt stops being enough

Three cases climb out of the Boolean's comfortable world:

• Encryption beyond the OS. A standard algorithm you implemented or vendored yourself (a bundled OpenSSL doing the work URLSession would have done) can still be exempt, but the claim shifts from "OS crypto" to the Category 5 Part 2 exemption list: medical end-use, intellectual-property protection, authentication and digital signatures and decryption, banking and money transactions, and "fixed" data compression or coding techniques.
• Proprietary encryption. The US government defines "non-standard cryptography," a definition App Store Connect's help quotes, as any implementation of cryptography "involving the incorporation or use of proprietary or unpublished cryptographic functionality, including encryption algorithms or protocols that have not been adopted or approved by a duly recognized international standards body." If you invented a cipher, you are in non-exempt territory: a CCATS classification from the Bureau of Industry and Security, uploaded to Apple, and the code key above.
• France. Apple's own help page singles France out: imports and exports of encryption apps distributed there are controlled by the French government, with secure storage, secure communications, and antivirus tools as the main controlled items and banking and medical apps exempt. ANSSI's regime treats use of cryptology as free but puts formalities on the supplier or first importer: a declaration for providing, importing, or transferring a means of cryptology within the EU (and for exports to the EU001 countries), an authorization request for exports to other third countries, and a "grand public" classification that frees export once ANSSI validates it. Distributing a crypto-carrying app on the French storefront means a declaration exists somewhere in your filing.

The year-end report, and who actually owes it

Apple's docs warn that exempt encryption "might alternatively be required" to file a year-end self-classification report with the US government. The regulation behind that warning is narrower than it reads. The report rule, 15 CFR 740.17(e)(3), sets a February 1 deadline for self-classification reports covering applicable encryption items exported the prior calendar year, filed as CSV to BIS and the NSA's ENC coordinator. But since the March 29, 2021 amendment, finished mass-market products classified under 5A992.c or 5D992.c are exempt from that reporting; the surviving obligation covers mass-market components and executable software plus self-classified items that stay at 5x002. A consumer app that meets the mass-market criteria, "generally available to the public" via electronic transactions, with crypto the user cannot easily change, does not owe the February filing. A CCATS also ends the duty. This is a "read the rule, do not assume" corner: when in doubt the annual email costs little and the statute is the authority, not this post.

Our position

Set the key, answer the question honestly, and treat crypto provenance as a dependency question. The checklist is small because the hard cases are rare: an app that uses OS cryptography for HTTPS, storage, and auth is done after one plist entry. The moment a third-party SDK or vendored library does its own crypto, the question reopens, and the declaration covers every library you link. France is the trap that catches shipping teams by surprise because it is an import rule disguised as a storefront setting: if the app goes live on the French store and carries anything beyond OS encryption, the ANSSI declaration is owed by the publisher, not by Apple. And proprietary crypto is the bright line: if the algorithm is yours, stop, because the CCATS path is paperwork on a timeline measured in weeks, not a checkbox.

The takeaway

Declarations like this are part of submission scope in our custom software work, the same class of paperwork we clear on CashTaq releases and cover in the privacy manifest every SDK needs. If your export answers are guesses, send us the plist.

← the journal