Every EAS Submit Failure Mode I've Hit in Six Months (and What Catches Each Pre-Submit)

TL;DR

• eas submit exiting 0 does not mean your app is on track for review. It means the binary reached the store's front door
• Six failures I've hit in six months: wrong ascAppId, IAPs not attached to the version, vanished TestFlight tester groups, incomplete Play Data Safety, versionCode collisions, and screenshot resolution rejections
• Each one shares a shape: green CLI, red store, and roughly a day lost to the review calendar
• Every single one is catchable before you submit. Checklist at the bottom

eas submit is genuinely good software. That is the problem. The CLI succeeds so cleanly that it trains you to believe the release is done, when all it has actually verified is that a binary was delivered. Everything that gets apps rejected lives on the other side of that handoff, in App Store Connect and Play Console state that the CLI never sees.

Here is every way that has bitten me since March, and the pre-submit check that now catches each one.

Failure 1: Wrong ascAppId, right exit code

Two apps under one Apple team. The submit profile in eas.json carried the ascAppId of the wrong one:

{
  "submit": {
    "production": {
      "ios": {
        "ascAppId": "1234567890"
      }
    }
  }
}

The CLI went green, because the ID was valid. The build just landed under the wrong app in App Store Connect, and I spent a morning wondering why the right app showed no new build.

Pre-submit catch: print the target before you fire. A two-line script that echoes ascAppId and the app's bundle identifier side by side, and refuses to continue if they don't come from the same app record, ends this class of mistake permanently.

Failure 2: IAPs not attached to the version

The binary was fine. The in-app purchase products existed. But new IAPs have to be attached to the app version and submitted with it for their first review. Ship the binary without them and Apple rejects the release, because the app references products the reviewer cannot see.

Pre-submit catch: if this release introduces or changes any IAP, open the version page in App Store Connect and confirm the products are listed under it before submitting. This is a thirty-second look that saves a full review round trip.

Failure 3: The vanished TestFlight external group

After a fresh submit, external testers stopped getting builds. The external tester group was still there, but the new build wasn't distributed to it: external distribution needs the build assigned to the group, and the first build of a new version needs beta review again. Nothing failed. Testers just quietly received nothing.

Pre-submit catch: treat "build uploaded" and "build distributed" as separate checklist items. After every submit, verify the new build shows against the external group, not just in the builds list.

Failure 4: Play Console Data Safety, the silent blocker

On Android my release sat in "Ready to send for review" while I assumed it was in review. The Data Safety section had a newly required disclosure I hadn't filled, and Play Console will hold a release on incomplete store listing sections without anything resembling an error in your terminal.

Pre-submit catch: open the release dashboard and look for any yellow banners before and after submitting. If your app adds an SDK, assume the Data Safety answers changed.

Failure 5: versionCode collision

eas submit delivered the AAB, Play rejected it: versionCode already used. A local build from weeks earlier had burned the number.

Pre-submit catch: stop managing it by hand.

{
  "build": {
    "production": {
      "autoIncrement": true
    }
  }
}

Remote version management makes EAS the single source of truth for versionCode and iOS build numbers, and this failure mode disappears.

Failure 6: Screenshot resolution mismatch

Metadata, not binary. App Store Connect enforces exact pixel dimensions per display size class, and a set exported at the wrong scale gets the whole release bounced. The required sizes also shift as new devices ship, so a screenshot set that passed last year can fail this year untouched.

Pre-submit catch: script it. A tiny check that reads each PNG's dimensions and compares against the currently required sizes takes ten minutes to write and never lets a stale set through.

The pattern

All six failures share one shape: the CLI reported success, the store said no, and the cost was paid in calendar days, not compute. Review queues turn a five-minute config mistake into a one-day delay, and two mistakes into a lost week.

The fix is boring: a pre-submit checklist that verifies store-side state, not just build-side state. Ours is now the first file in every release branch.

If you'd rather not own that checklist at all, this is exactly the job we built RapidNative Deploy for: it runs these store-side checks and handles the submission path so a green pipeline actually means a shipping app.

Which one of these has cost you a review cycle? And what's the failure mode I haven't hit yet? Drop it in the comments.