Release Architecture

Expo release work has three separate paths: build, submit, and update.

The Pieces

Piece	What it does	Common mistake
EAS Build	Creates signed Android/iOS binaries	Treating a dev server run as release proof
EAS Submit	Uploads binaries to Play Console or App Store Connect	Assuming submit handles metadata, screenshots, privacy, or review
EAS Update	Publishes compatible JavaScript/assets OTA	Shipping native or permission changes OTA
Runtime version	Compatibility boundary between binary and update	Reusing one runtime after native changes
Channel	Build-time pointer to update stream	Confusing store tracks with update channels
Branch	Update stream where update groups are published	Publishing production fixes to the wrong branch
Store track/TestFlight	Store distribution surface	Treating TestFlight/internal as production

Default Profile Ladder

{
  "build": {
    "development": {
      "developmentClient": true,
      "distribution": "internal"
    },
    "preview": {
      "distribution": "internal",
      "channel": "preview",
      "android": { "buildType": "apk" }
    },
    "production": {
      "channel": "production",
      "autoIncrement": true,
      "android": { "buildType": "app-bundle" }
    }
  },
  "submit": {
    "production": {
      "android": { "track": "production" },
      "ios": {}
    }
  }
}

Keep project-specific credential paths out of committed examples unless the files are gitignored and documented.

Release Rule

If the change affects native code, app config, permissions, SDK version, runtime version, package ID, bundle ID, signing, or store policy, it belongs in a new binary first. OTA can follow after the new binary is available.