AppForShare

EAS Submit: what it uploads and what you still do by hand

· 7 min read

EAS Submit: what it uploads and what you still do by hand

EAS Submit (Expo now also calls it Expo Submit) does one job well: it takes a store build and uploads it to App Store Connect or to a Google Play track. Many teams expect it to do more, then find that the listing, the screenshots, the release notes and the App Review step are still waiting for them. This post sets out what EAS Submit does, what Expo's other tools add, and what is left for you, with the commands for each step. Expo facts were read in Expo's docs on November 4, 2026.

What EAS Submit uploads

From Expo's Submit introduction: it uploads the .ipa to App Store Connect, where it shows up in TestFlight after Apple processes it, and the .aab to a Google Play track. The same page is clear about the limits. EAS Submit "uploads your binary but does not manage store listing metadata, screenshots, or release notes", and "A TestFlight build is not automatically released to the App Store". The iOS page adds: "To release to production, log in to App Store Connect and submit the build for App Review".

The usual commands:

# newest EAS build of each platform
eas submit --platform ios --latest
eas submit --platform android --latest

For Android, the submit profile in eas.json takes track, releaseStatus, changesNotSentForReview and a rollout fraction (submit schema):

{
  "submit": {
    "production": {
      "android": {
        "track": "production",
        "releaseStatus": "inProgress",
        "rollout": 0.1
      }
    }
  }
}

The rollout value is set once, at upload. Raising it to 50% or 100% later happens somewhere else.

What the rest of Expo adds

  • The testflight job in Expo Workflows. It uploads to TestFlight and can add internal and external groups and "What to Test" notes. Its submit_beta_review option "defaults to true when external_groups are provided", so it also sends the build to Beta App Review (pre-packaged jobs). This is a real strength.
  • EAS Metadata. You keep App Store text in store.config.json and push it with eas metadata:push. Expo says it is "in beta and subject to breaking changes", it covers the App Store only ("The Google Play Store is one of those features currently not implemented"), and it does not upload screenshots (EAS Metadata docs).
  • Webhooks. SUBMIT events tell other tools when an upload finished or failed.

What is still left for you

StepExpo (EAS)Still to do
Upload .ipa to App Store ConnectEAS Submit, testflight jobNothing
TestFlight groups and Beta App Reviewtestflight jobNothing, if you use Workflows
App Store textEAS Metadata (beta)Review it per language
App Store screenshotsNot in EAS MetadataUpload them in App Store Connect
Send for App Review, releaseNot in EAS SubmitApp Store Connect
Upload .aab to a Play trackEAS SubmitNothing
Google Play listing and graphicsNot in EAS MetadataPlay Console
Raise or halt a Play rolloutOne fraction at uploadPlay Console
Reply to store reviewsNot found in its docsBoth consoles

None of this is a flaw in EAS Submit. It is an upload tool. The work after the upload is just spread across two consoles, and it is easy to forget a language, a screenshot size or the What's New text.

Where AppForShare fits after the upload

AppForShare connects to your stores with your own App Store Connect API key and a Google Play service account (Pro: one of each; Team: up to 10 per store). Every store change is made by a person, never by AppForShare on its own.

Store listing for both stores

The listing editor (Pro and Team) edits App Store and Google Play text per language, with each store's limits, plus screenshots, history and AI translation that a person reads and saves. It can import a store.config.json as unsaved changes and export your App Store listing in the same format, so a team already using EAS Metadata does not retype anything. Google Play saves go to Google's review, so they need an Admin.

App Store review

The App Store review card (Pro and Team) picks a processed build, asks the export compliance and App Review contact questions, and checks the listing before an Admin ticks a confirm box and sends it with your own key. It can also release an approved version and pause or resume Apple's 7 day phased release. It never sends a version for review on its own.

Google Play tracks and rollouts

The Google Play releases page shows every track. Pro edits release notes and promotes between testing tracks. Team also handles production: promote, raise the rollout, halt, resume and complete, each by an Admin with a confirm tick. A scheduled rollout plan on Team raises a rollout that is already in progress at set times, and it stops itself if anyone changes the rollout elsewhere. Team also shows Play crash rate and ANR rate per version, read only. The plan never pauses on those numbers by itself; a person watches them and acts. The Google Play staged rollout guide covers the steps.

Uploading without eas submit

If a build was uploaded to AppForShare, an Admin can send it to the store from there: an App Store signed .ipa to TestFlight, or an .aab to a Play internal, closed or open track (Pro), or a Play production release saved as a draft (Team). It needs a confirm tick, and AppForShare does not sign or re-sign the file. From the CLI:

npx appforshare store-upload <build id> --to testflight --yes
npx appforshare store-upload <build id> --to play:internal --yes

If eas submit already works in your pipeline, keep it. This is for builds that come from somewhere else, or for teams who want the upload and the review in one place. See store upload.

TestFlight feedback and reviews

On Team, screenshot and crash feedback that testers send in the TestFlight app lands in the AppForShare feedback inbox next to install page feedback, read only. The reviews inbox (Pro and Team) shows App Store and Google Play reviews with reply drafts that a person posts.

A practical order of steps

  1. Build with EAS and run eas submit (or the testflight job) as you do today.
  2. While Apple processes the build, finish the listing in the editor for every language, including What's New.
  3. Run the App Store review card checklist and send. Apple still decides; AppForShare shows the reasons if it refuses.
  4. On Google Play, promote the build to production (Team) or finish it in Play Console, then raise the rollout by hand or with a plan.
  5. Watch reviews and, on Team, crash and ANR rates per version.

The App Store submission checklist lists what Apple looks at.

More for EAS teams: how EAS internal distribution links work and EAS Build pricing in 2026.

Common questions

Does EAS Submit send my app to App Review?

No. Expo's docs say to submit the build for App Review in App Store Connect. The testflight job can send a build to Beta App Review for external TestFlight testers, which is a different review.

Does AppForShare replace eas submit?

It does not have to. Keep eas submit for uploads and use AppForShare for the listing, review and rollout steps. Store upload is there if your builds do not come from EAS.

Does AppForShare submit for me?

No. An Admin of your workspace sends each change with your own store keys, after a confirm tick. Nothing goes to Apple or Google on its own.

Can testers install the build I submitted?

Not from a link. App Store and Google Play builds go through TestFlight or Play testing tracks. For link installs, share an internal distribution build; this Workflows guide shows how.

For the bigger picture, see AppForShare vs Expo EAS, Use AppForShare with Expo EAS and Expo EAS alternatives in 2026. You can sign up for free and connect your stores when you move to Pro.

Keep reading

App Distribution Platform · · 5 min read

AppForShare File Size and Upload Limits

AppForShare limits the size of each build you upload by plan: 50 MB without an account, 150 MB on the Free plan, 2 GB on Pro and 4 GB on Team. Accounts also have a storage total, and every plan...