The approval email arrived a little after three in the morning, my time.
I had submitted that version with "automatically release" still selected, so by the time I woke up the store listing had already flipped to the new build. My announcement post was still a draft. The replacement screenshots were scheduled for the next day. Nothing broke, and no user noticed — but the order of events had been decided by a review queue on the other side of the world rather than by me, and that detail stuck.
You cannot make review go faster. What you can do is stop treating "approved" and "live" as the same event. Both stores keep them on separate switches, and once you separate them, the unpredictability of the queue stops leaking into everything downstream.
Approved and live are two different switches
Here is what each store actually lets you control.
| Aspect | App Store | Google Play |
|---|---|---|
| How long review takes | Not under your control | Not under your control |
| When an approved build goes live | Three release options per version | Managed publishing on or off |
| Where you set it | The version page in App Store Connect | Publishing overview in Play Console |
| Scope of the setting | Per version — you pick it every submission | Per app — set it once and it persists |
| Relationship to your submit tooling | eas submit only uploads the build |
eas submit config has to agree with it |
That last row is the one people miss. When you are shipping a Rork-exported project through EAS, it feels like eas.json should own the whole pipeline including the moment of release. It does not. The store-side setting sits above it, and changing only one of the two produces a mismatch that shows up as a failed submission rather than a helpful warning.
App Store Connect asks you to choose again every submission
The version page in App Store Connect offers three ways to release.
| Option | What happens after approval | When it fits |
|---|---|---|
| Automatically release this version | Goes live as soon as review clears | Quiet bug fixes with no announcement attached |
| Manually release this version | Sits at "Pending Developer Release" until you press the button | Anything you want to coordinate with a post or another store |
| Automatically release after a date | Goes live after review, but no earlier than the date and time you set | A launch date that was fixed before the build was ready |
The third option takes a date and time in your own local time zone. If you are coordinating with an audience in another region, do that conversion once, deliberately, rather than assuming the field means what you want it to mean. It is an easy place to land several hours off target.
My default is the manual option, for a plain reason: I do not get to choose what hour the approval lands. Review can clear at three in the morning or during a weekend. With manual release, an overnight approval simply waits. I open the store listing in the morning, look at it with my own eyes, and then publish — which keeps the announcement, the screenshots, and the build in the order I intended.
One practical caveat: this setting is stored per version, so the next submission starts fresh and you choose again. It is worth a line in whatever pre-submission checklist you keep, because it is exactly the kind of setting that gets skipped when you are focused on the build itself.
Turn on managed publishing before you need it
On the Play side, the equivalent control is managed publishing, and it is set per app rather than per release. With it enabled, changes that pass review collect in a "Ready to publish" list and stay there until you publish them yourself. With it disabled — the default — approved changes go live the moment they clear review.
The benefit that matters most in practice is not timing for its own sake. It is that store listing edits and app updates can be released together. Without managed publishing, a screenshot change can clear review in an hour while the binary is still being examined, leaving your listing describing a version nobody can download yet.
If you submit through EAS, there is one collision worth knowing about before you hit it. With managed publishing enabled, a plain eas submit run fails, because EAS tries to send the changes for review automatically and the store is configured to let you do that manually. You resolve it by declaring the intent in eas.json:
{
"submit": {
"production": {
"android": {
"serviceAccountKeyPath": "./secrets/play-service-account.json",
"track": "production",
"releaseStatus": "completed",
"changesNotSentForReview": true
}
}
}
}Setting changesNotSentForReview to true narrows the EAS step to uploading the artifact. Sending changes for review and publishing them both stay in Play Console, where managed publishing expects them to be. If you are going to use managed publishing, treat these two settings as a pair — enabling one without the other is the whole failure mode.
The reverse is also worth checking. On an app where managed publishing is off, leaving changesNotSentForReview set to true means your upload succeeds and then quietly sits there, never entering review at all. That one is easy to inherit by copying an eas.json between a test app and a production app, and it looks like nothing went wrong until you notice the release never moved.
When a deadline is fixed, start counting from before review
Controlling the moment of publication does not make review time predictable. For updates with an externally imposed date — a target API level requirement, a seasonal campaign, a partner announcement — you still need to work backwards, and the backwards count should start before the submission, not after it.
Three allowances I build in every time:
- Budget one full rejection round trip. Planning as if the first submission clears means a single piece of feedback consumes the entire buffer. Assuming one round trip and being pleasantly surprised costs nothing.
- Push a TestFlight external build through first. Distribution to external testers requires Beta App Review, which is a separate queue from the production App Review — and it is only required for the first build of a version. Getting it through early surfaces the things reviewers most often push back on, like permission usage strings and metadata, while you still have room to fix them. Internal testers on your team skip this review entirely, which is convenient but also means an internal-only test tells you nothing about how a reviewer will read your submission.
- Set your own submission deadline a few days ahead of the launch date. Without a hard "submitted by" date, small refinements expand to fill the time you were holding for the review queue.
If the deadline you are working against is on the Android side, the three places I had to fix before a Rork project actually targeted API level 36 covers what I actually had to change. And if the submission itself is rejected over a number rather than a policy, Version code 1 has already been used — who owns that number, app.json or EAS? is the closest neighbour to this article.
What you can change today
Two of these do not require waiting for your next submission.
Open Play Console and turn managed publishing on for the app you ship most often. If you submit through EAS, add changesNotSentForReview to eas.json in the same sitting — it is an app-level setting, so once the pair is in place it keeps working for every release after this one.
App Store Connect is the one you re-select each time. Adding a single line to your pre-submission checklist ("set release option to manual") has been the only thing that reliably stops me from forgetting it.
While your build is sitting in the queue, there is very little left to do. But the first move after it comes out of the queue can still belong to you — and having that one move back makes the announcement, the listing update, and the release itself happen in the order you actually planned.