Submitting an Expo app with EAS: the checklist

npx expo config --type public

Before the build

Check the resolved config, not the source.

npx expo config --type public > /tmp/resolved.json
# purpose strings, capabilities, bundle id, version
grep -E 'UsageDescription|bundleIdentifier|usesAppleSignIn|version|buildNumber' /tmp/resolved.json

Every value a reviewer will see comes from here. A purpose string added by a plugin appears in this output and not in app.json, which is why auditing the source file misses it. Auditing what your config plugins added.

Diff your build profiles.

# what actually differs between what you tested and what you ship
python3 -c "import json;d=json.load(open('eas.json'))['build'];\
print(sorted(set(json.dumps(d.get('preview',{}),sort_keys=True).split(','))^\
set(json.dumps(d.get('production',{}),sort_keys=True).split(','))))" 2>/dev/null || cat eas.json

Read it by hand if that is easier. The question is: what is true in production that was not true in the profile you tested?

Confirm the environment variables exist on the server. Anything read at build time must be set as an EAS environment variable or secret. A .env file that is gitignored is, by definition, not on the build machine.

After the build, before submitting

Install the artifact and use it. Not the simulator build. The actual thing, on a device, signed the way it will ship. Three of six launch bugs in this house's own history were only visible on device, and that is a typical ratio.

Do the reviewer's run. Fresh install, no existing account, no data on the server, offline once. That is the state a reviewer starts in and almost nobody tests it, because your device has your account and your data. What reviewers actually test.

Check the version and build number against what App Store Connect expects. A duplicate build number is a rejected upload, which is cheap, and a wrong version string in the listing is a metadata problem, which is not.

The upload-time blockers

These are decided before a human sees anything, and an Expo project meets them through dependencies rather than through code you wrote:

• ITMS-90683 missing purpose string
• ITMS-91053 required-reason API with no declared reason
• ITMS-91054/5/6 invalid privacy manifest
• ITMS-91061 a listed SDK ships no manifest

Fix all four before uploading, because each one costs a round trip and they are found one at a time.

Then the review-time items

• Account deletion, if the app has accounts
• Sign in with Apple, if you offer social login
• Subscription disclosure, if you sell one
• Other-platform references in metadata and in-app strings
• Screenshots showing the app, on the right device
• Review notes with credentials that work today

Play, in the same pass

Different mechanism, same discipline: check the Console's own blocking list for the version rather than reasoning from memory.

Target API level · Data safety form · Closed testing requirement · Foreground service types

Over-the-air updates

expo-updates after approval is supported and normal. Its limit is that an update must not change what the app fundamentally does, and disclosing that you use it costs three lines in the review notes. Guideline 2.3.1, hidden features.

shipcheck runs this pass against the resolved config, Podfile.lock and node_modules from inside Claude Code, cites the Apple or Google clause for each finding, and names the file and line. What it checks. · The first-submission checklist. · After a rejection.

Questions and answers