Export compliance and the App Store

Export compliance and the App Store

When you submit an app for publication in the App Store you are uploading your app to servers located in the United States. Downloads of your app outside the United States and Canada are treated as exports from the United States — and as of 2026, U.S. Department of Commerce encryption export administration regulations (EAR) continue to apply in full. If your app uses encryption in any form, you need to understand your obligations before you ship.

TL:DR – Apps distributed via the App Store are U.S. exports. If they use encryption, they need either an export licence or a qualifying exemption. Most apps qualify for an exemption, but you still have to file an annual self-classification report with the U.S. government.

Summary

• Apps downloaded from the App Store outside the United States and Canada are considered by the U.S. government to be an export from the United States.
• If your app uses encryption in any form — including standard HTTPS calls — you are subject to U.S. export laws.
• Many common encryption patterns in mobile apps qualify for an exemption from obtaining a formal export licence, but you must verify this carefully for your specific app.
• Even with an exemption, you are still required to submit an annual self-classification report to the U.S. government, listing each qualifying app.
• The underlying regulations (Title 15 of the eCFR, Part 742) are actively maintained — the most recent amendment was dated May 26, 2026 — so it pays to check for updates at least once a year.

What's changed in 2026

The core framework governing encryption exports — the Export Administration Regulations (EAR), administered by the Bureau of Industry and Security (BIS) — remains in place and continues to apply to App Store submissions. Title 15 of the eCFR (which houses the EAR) is actively updated; as of late May 2026 it had been amended as recently as May 26, 2026. This means the regulations are a living document, not a static archive. If you set up your compliance process a couple of years ago and haven't revisited it, now is a good time to re-read the relevant sections.

Practically speaking, the annual self-classification report requirement has not been relaxed. Apple continues to ask encryption-related questions during every new app submission and every app update in App Store Connect. The questions themselves have remained broadly consistent, but Apple's underlying guidance links now point to updated documentation — make sure you are reading the current version when you work through your answers.

For Flutter and FlutterFlow developers in particular: the ecosystem has continued to deepen its reliance on Firebase, Supabase, and other cloud back-ends, all of which communicate over encrypted channels. If anything, the proportion of apps that unambiguously "use encryption" has grown. Assume your app uses encryption unless you have a specific reason to believe otherwise.

Why does this apply to me?

Uploads to App Store Connect land on Apple infrastructure hosted in the United States. When a user in, say, Germany or Japan downloads your app, that download is legally an export from the United States to a foreign country. It does not matter where your company is incorporated, where you live, or where your development team is based. The relevant fact is that the binary travels from U.S.-hosted servers to a device in another country.

This applies equally to TestFlight distribution. If you invite beta testers outside the U.S. and Canada, those downloads are also exports and the same rules apply.

Do you use encryption?

If you are building with FlutterFlow — which relies heavily on Firebase, Supabase, REST APIs, and other cloud services — you are almost certainly using encryption. Use of encryption includes, but is not limited to:

• Making calls over secure channels (e.g. HTTPS, TLS/SSL). This alone is enough to bring your app within scope.
• Using standard encryption algorithms for authentication and authorisation — for example, Firebase Authentication, OAuth 2.0 flows, or JWT handling.
• Using cryptographic functionality provided by iOS, macOS, or Android at the operating-system level.
• Using proprietary or non-standard encryption algorithms. The U.S. government defines "non-standard cryptography" as any implementation involving cryptographic functionality that has not been adopted or approved by a recognised international standards body such as IEEE, IETF, ISO, ITU, ETSI, 3GPP, TIA, or GSMA, and has not otherwise been published.

The first two categories apply to virtually every FlutterFlow app built today. If your app makes a single HTTPS call — and it almost certainly does — you are using encryption.

Exemptions from compliance obligations

Several exemptions within the EAR release apps from the requirement to obtain a formal export licence, provided the app's use of encryption falls within specific, defined categories. Determining whether your app qualifies is your responsibility. All liability for misclassification sits with you, not with Apple or your framework vendor.

Start by reading the U.S. Department of Commerce Bureau of Industry and Security (BIS) website and at minimum work through the BIS encryption FAQ. The full regulatory text lives in Title 15 of the eCFR, Part 742, which is updated regularly — check you are reading the current version.

If your app qualifies for an exemption under Licence Exception ENC (Section 740.17), you are still required to submit a year-end self-classification report for items exported under 740.17(b)(1), unless a Commodity Classification (CCATS) has been issued for the item. Note that Licence Exception ENC covers two authorisation types — ENC and MMKT — which have different criteria and different reporting implications.

When you submit a new app or an update in App Store Connect, you will be asked a series of questions about your app's use of encryption. Revisit these answers whenever your app's encryption posture changes — for example, if you add a new authentication provider, integrate a new SDK, or implement in-app payment flows.

App Store encryption questions

Does your app use encryption?

• Select Yes even if your app only uses the encryption built into Apple's operating system — for example, making calls over HTTPS or TLS.
• Export laws require that products containing encryption be properly authorised for export. Answering No when the answer should be Yes is a compliance failure, not a shortcut.
• Failure to comply can result in significant penalties, including removal from the App Store.

Does your app qualify for any of the exemptions provided in Category 5, Part 2 of the U.S. Export Administration Regulations?

• Select No unless you have verified that your app meets the criteria of a specific exemption. You are responsible for the correct classification of your product.
• Incorrectly claiming an exemption may put you in violation of U.S. export law and could result in your app being removed from the App Store.
• You may select Yes if the encryption in your app is: (a) specially designed for medical end-use; (b) limited to intellectual property and copyright protection; (c) limited to authentication, digital signature, or the decryption of data or files; (d) specially designed and limited for banking or money transactions; or (e) limited to fixed data compression or coding techniques. You may also select Yes if your app meets the criteria in Note 4 to Category 5, Part 2 of the EAR.

Does your app implement any encryption algorithms that are proprietary or not accepted as standards by international standards bodies (IEEE, IETF, ITU, etc.)?

• Select No if you have not implemented any proprietary encryption algorithms. Most apps built on standard frameworks and platform APIs will answer No here.

Does your app implement any standard encryption algorithms instead of, or in addition to, using the encryption within Apple's operating system?

• Select No if you rely solely on the standard encryption provided by the Apple operating system and do not bundle or implement your own cryptographic libraries.

Annual self-classification report

Even if your app qualifies for an exemption, you must submit an annual self-classification report to the BIS by February 1 each year, covering exports made during the previous calendar year. The report is submitted as a CSV file by email to two BIS addresses (check the current BIS guidance for the exact addresses, as these can change). No web portal exists for this — email with the CSV attached remains the accepted method.

Below is an example row based on the BIS sample report, adapted for a typical mobile app. This is illustrative only — verify all fields against the current Supplement 8 to Part 742 before filing.

PRODUCT NAME,MODEL NUMBER,MANUFACTURER,ECCN,AUTHORIZATION TYPE,ITEM TYPE,SUBMITTER NAME,TELEPHONE NUMBER,E-MAIL ADDRESS,MAILING ADDRESS,NON-U.S. COMPONENTS,NON-U.S. MANUFACTURING LOCATIONS
XtraGood Client App,N/A,PDQ123 Software Services LLC,5D992,MMKT,mobility and mobile applications n.e.s.,Jane Smith,(202) 555-0000,This email address is being protected from spambots. You need JavaScript enabled to view it.,555 Elm St. Washington DC 20032,NO,Shenzhen China Amsterdam Netherlands

Refer to the BIS sample annual self-classification report for the full field definitions and instructions. Key points:

• The first line must contain exactly these 12 column headers: PRODUCT NAME, MODEL NUMBER, MANUFACTURER, ECCN, AUTHORIZATION TYPE, ITEM TYPE, SUBMITTER NAME, TELEPHONE NUMBER, E-MAIL ADDRESS, MAILING ADDRESS, NON-U.S. COMPONENTS, NON-U.S. MANUFACTURING LOCATIONS.
• No field may be left blank — use N/A or NONE where a field does not apply.
• PRODUCT NAME and ECCN are mandatory. Most consumer mobile apps use 5D992 for ECCN.
• For AUTHORIZATION TYPE, enter ENC or MMKT. Apps whose encryption is limited to standard HTTPS/TLS typically use MMKT.
• For ITEM TYPE, mobile apps generally fit mobility and mobile applications n.e.s. (not elsewhere specified), per Supplement 8 to Part 742(a)(6).
• The submitter columns (SUBMITTER NAME through NON-U.S. MANUFACTURING LOCATIONS) describe your company as a whole and should be identical across every row in the report.
• The only commas permitted in the file are the field delimiters. Do not include commas within any field value — this will corrupt the CSV structure.
• 5D992 is the correct ECCN for mass-market encryption software. You may encounter references to 5A992 — that classification applies to hardware, not software.
• Once classified or self-classified under §740.17(b), mass-market encryption software meeting the eligibility requirements is released from EI and NS controls and is designated 5D992.c.

Staying compliant going forward

Export compliance is not a one-time checkbox. The EAR is amended regularly — sometimes multiple times in a single year — and your app's encryption profile can change with every dependency update or new feature. Build a short annual review into your release calendar: re-read the BIS FAQ, confirm your ECCN and authorisation type still apply, update your self-classification report, and re-check your App Store Connect answers before your first submission of the new year.

If you are uncertain about any aspect of your classification, the BIS offers a formal commodity classification process (CCATS) and has published extensive guidance. For complex situations, consulting a lawyer with U.S. export control experience is worthwhile — the cost is modest compared to the penalties for non-compliance.