Missing Compliance in App Store Connect: How to Fix It Once in Your Expo App

Missing Compliance is a build status App Store Connect assigns when it has no export compliance answer on file for that build. Apple's own build status reference describes it as your build missing export compliance documentation, with action needed. It is not a rejection, and no human has reviewed anything. Your upload succeeded, processing finished, and then the build stopped at a question you have not answered yet.

The question is about encryption. Apple states that if your app uses, accesses, contains, implements or incorporates encryption and you intend to upload, test and distribute it, you need to determine your export compliance requirements in App Store Connect. Encrypted software is export-controlled, so Apple cannot distribute the binary until it knows which side of that line you are on.

It blocks both paths, which is why it catches people out. Apple documents that if you select a build with the Missing Compliance status, you must answer the export compliance questions before submitting for review. On the beta side, Apple's guidance is to specify encryption use for your build to avoid the beta being marked Missing Compliance, because the build cannot go to testers until you do.

For an indie shipping a first app, this shows up as a build you uploaded, invited testers to, and then watched go nowhere. Nobody gets the notification. Nothing is wrong with your code and nothing is wrong with the binary. The build is parked behind a form. If you are still wiring up beta distribution, [the TestFlight beta testing guide for Expo apps](/blog/testflight-beta-testing-guide-for-expo-apps) covers the rest of that path.

Answer it once in your app config and every future build carries the answer with it. Expo exposes the setting as ios.config.usesNonExemptEncryption, a boolean, and its documented behaviour is to set the ITSAppUsesNonExemptEncryption key in the built app's Info.plist to that value. Apple reads the key on upload and stops asking.

In app.json the block goes under the ios key, as ios, then config, then usesNonExemptEncryption set to false. In app.config.js or app.config.ts the same nested object goes in the same place on the config you export. Expo's own answer to a build stuck on this status is exactly that snippet, framed as answering the question once instead of on every upload.

Then rebuild. The value is compiled into the Info.plist of the binary, so it only takes effect in a new build. The next one you upload arrives with the declaration already attached and the status never appears.

Most Expo apps that talk to an API over HTTPS and store nothing encrypted themselves do qualify for the exemption, which is why false is the common answer. It is still a declaration you are making, not a checkbox you are clearing. Treat it as a statement you would be comfortable defending, because that is what it is.

Expo's guidance is to set usesNonExemptEncryption to false only when your app uses no encryption beyond what Apple exempts, such as HTTPS through the operating system, and it notes that the declaration also covers third-party libraries your app links against. That second clause is the one people miss. You are declaring for your whole dependency tree, not only the code you wrote.

Apple is direct about where the liability sits. Its export compliance page states that it is your responsibility to review the Export Administration Regulation to determine whether your app's use of encryption requires a formal classification from the Bureau of Industry and Security, and that you are responsible for all liabilities associated with misinterpretation of export regulations or claiming exemption inaccurately.

The definition is wider than most builders assume. Apple lists apps using standard encryption algorithms, apps using crypto functionality within Apple's operating system, and apps using proprietary or non-standard encryption algorithms as examples that need an export compliance determination. Using the platform's own crypto counts as using encryption.

That is the point people get backwards. Needing a determination is not the same as failing it. Nearly every modern app needs a determination because nearly every modern app makes an HTTPS request. The common outcome of that determination is that you are exempt from providing documentation, which is the thing the config value records.

Apple also quotes the US Government definition of non-standard cryptography: any implementation involving proprietary or unpublished cryptographic functionality, including algorithms or protocols that have not been adopted or approved by a duly recognized international standards body and have not otherwise been published. Apple names IEEE, IETF, ISO, ITU, ETSI, 3GPP, TIA and GSMA as examples of those bodies.

The Encryption Inventory is our name for the short pass we run before the first iOS build of any app. The goal is to make the declaration deliberately once, write down the reasoning, and stop re-litigating it at every release. It takes about ten minutes on a young codebase.

Ask Claude Code in the desktop app to read your package.json and lock file and list every dependency that implements cryptography rather than calling the system. That is a good use of it, because the tedious part is walking the dependency tree, not making the judgement. You still make the call yourself.

You do not need a new binary to clear a build already sitting at Missing Compliance. The answer lives in App Store Connect and you can attach it to the build that is already uploaded, which is the fastest route when testers are waiting.

Apple documents the same Manage control beside the build on the Distribution tab, so you can clear it from the submission side as well as the TestFlight side. If you have not spent time in these screens yet, [how to set up App Store Connect for your first app](/blog/how-to-set-up-app-store-connect-for-your-first-app) walks the layout.

Some answers lead Apple to ask for documentation rather than accept a simple declaration. That is handled in the App Encryption Documentation section of App Store Connect, and Apple documents that it should be completed before submitting a build for review on either App Review or TestFlight App Review.

Apple asks you to populate the App Description field and manage availability for your app before providing the documentation, because without that information it cannot determine whether the documents are sufficient. That ordering trips up anyone who leaves store metadata until the end.

On timing, Apple states that it evaluates export compliance reviews on a case-by-case basis, and that if you provide complete information it expects to review and clear apps in approximately two business days. Treat that as Apple's stated expectation rather than a guarantee about your submission, and do not stack it against a launch date you have already announced.

Once your documentation is approved, Apple provides a key value that removes the need to answer encryption questions with each submission, and it appears next to the approved documentation in that same section. In an Expo project you add that value through the ios.infoPlist section of your app config rather than opening Xcode.

Apple's export compliance page notes that the import and export of encryption apps distributed in France are also controlled by the French Government. It names the main items of control as Secure Storage, Secure Communications and Security Anti-Virus applications, and notes that exemptions include Banking and Medical applications, pointing to the French national cybersecurity agency for the detail.

This matters because App Store Connect determines your requirements partly from where you plan to make the app available. A worldwide release is the default for most first apps, and it is the answer that pulls in every territory's rules at once. For an ordinary utility or content app this changes nothing. For a genuine secure-messaging or secure-storage product it is the part to read properly rather than skim.

Missing Compliance should be a one-time event in the life of an app. Once the config value is set and the reasoning is written down, the status stops appearing, and the only thing that can bring it back is a change you made on purpose.

This belongs to the same class of quiet pre-submission paperwork as the privacy questionnaire and the review information fields, and it fails the same way, which is silently. [App Privacy details in App Store Connect](/blog/app-privacy-details-app-store-connect) covers the privacy form line by line, and [the guideline 2.1 Information Needed breakdown](/blog/guideline-2-1-information-needed-rejection) covers what happens when App Review needs something from you. The wider path is in [how to pass Apple App Review](/blog/how-to-pass-apple-app-review).