Open the TestFlight tab in App Store Connect right after uploading a Rork-built iOS binary and you will almost certainly see a yellow Missing Compliance marker. Click Manage and Apple asks whether your app uses encryption. Almost every developer hits this on their first iOS submission. As an indie developer who has been shipping iOS apps since 2014 and running on AdMob revenue, I used to answer that dialog by hand for years before I realized it can be defused permanently with a single line in Info.plist.
Leaving the flag in place blocks external TestFlight distribution and any App Store submission, so for someone with 50M+ cumulative downloads across a Dolice catalog of wallpaper and utility apps, this is the kind of pothole you want to fill on the very first release. Here is how the warning is generated, how to add the right Info.plist key from a Rork project, and how to clean up the builds that already shipped with the flag attached.
Why Missing Compliance keeps appearing
iOS apps fall under the US Export Administration Regulations because they ship encrypted communication around the world. App Store Connect's Manage panel is Apple's front end for collecting the information they need on your behalf.
The form really asks two questions. Does your app use encryption at all? And if it does, does that encryption fall into one of the exemptions defined by the regulation? Hitting Skip does not answer either question, it only defers them, so the same panel comes back for the next build, the next tester invite, and every submission attempt.
The important nuance is that HTTPS, iOS system APIs, and basic local hashing for credentials are all on the exempt side of Apple's published guidance. A Rork project that talks to your backend over fetch(), lets AdMob fetch ads over TLS, or pulls Remote Config from Firebase falls comfortably inside the exempt bucket. Most Rork wallpaper apps, utility apps, and AI chat apps end up in that same category, which means we can declare the exemption mechanically in Info.plist instead of clicking through the dialog every release.
The one key that ends the loop
The Info.plist key Apple provides for the permanent answer is ITSAppUsesNonExemptEncryption. The phrasing is slightly backwards from intuition, so read it carefully.
falsemeans "I do not use any non-exempt encryption." The dialog disappears.truemeans "I use non-exempt encryption." You then have to register an ECCN and file annual reports.- Omitting the key forces the manual prompt every time.
The decision rule is simple. If your app does not bundle a custom encryption library and does not sell encryption as a feature, false is the right answer for the vast majority of Rork apps. Wallpaper apps, utilities, lightweight AI chat front ends, and most AdMob-monetized apps fall into this bucket because everything they do flows through standard HTTPS or Apple's CryptoKit. I usually double check the export compliance FAQ for any new SDK before flipping the switch, just to keep my own house clean.
Setting it from a Rork project
Rork builds iOS through Expo's app.json (or app.config.js), so you never have to touch the Xcode Info.plist file directly. The right place is the ios.infoPlist block:
{
"expo": {
"name": "MyApp",
"slug": "my-app",
"version": "1.4.0",
"ios": {
"bundleIdentifier": "com.example.myapp",
"buildNumber": "1",
"infoPlist": {
"ITSAppUsesNonExemptEncryption": false
}
}
}
}Write the value as the JSON literal false, not the string "false". Plist generators preserve string values verbatim, and Apple's checker only treats the actual boolean as a valid answer. This is the first thing I trip on whenever I copy a snippet from somewhere, and I have watched several friends doing indie dev hit exactly the same wall.
If you prefer app.config.js, the equivalent is straightforward:
export default {
expo: {
name: "MyApp",
ios: {
infoPlist: {
ITSAppUsesNonExemptEncryption: false,
},
},
},
};After saving, kick off your next build (eas build --platform ios --profile production for EAS, or just rerun the Rork cloud build) and the new binary will carry the key.
Clearing builds already on App Store Connect
The Info.plist change only affects future builds, so any binary that is already sitting in TestFlight with a yellow flag needs to be cleared manually before you can hand it to external testers or submit it to the store.
Open the build in TestFlight, click Manage next to Export Compliance Information, and answer:
- "Does your app use encryption?" — Yes
- "Does your app qualify for any of the exemptions?" — Yes
- "Does your app implement any standard encryption algorithms instead of, or in addition to, using or accessing the encryption within Apple's operating system?" — No
That combination matches what an HTTPS-only Rork app is actually doing, and it removes the flag from that specific build. If you genuinely ship custom cryptography, this is the place to switch to Yes and start the ERN and annual self-classification process instead.
Annual self-classification, in one paragraph
The yearly BIS self-classification report only becomes relevant if you flip the key to true. The Apple-side guidance is that a false answer means you do not need to file. I keep two streams in my own catalog: HTTPS-only apps go straight to false and never see the dialog again, while the small number of apps that ship custom encryption get the annual filing as a separate workflow. The mistake I want to avoid is leaving everything at Skip out of caution, because then every release waits on manual approval.
Verifying the fix
Build, upload, and check the new build under Activity or the TestFlight tab. The right-side flag should not appear, and you should be able to assign the build to an external testing group without a Manage prompt. If you upload from Xcode directly, you can open ios/MyApp/Info.plist and look for ITSAppUsesNonExemptEncryption written as <false/> to confirm. When Rork or Expo build caches make the change look like it has not taken effect, a single expo prebuild --clean will rebuild the native project cleanly.
Once the key is in your app.json, Manage drops out of your release workflow for good. In my own pipeline across six wallpaper apps, that one removal alone shaved off a chunk of manual clicking every week. The more often you ship, the more this single line pays off.
If you have an iOS build planned today, add ITSAppUsesNonExemptEncryption: false to ios.infoPlist in your app.json before kicking it off, and watch the next upload land without the yellow flag.