Shipping When Review Takes a Week ⏳

A recurring complaint surfaced on Hacker News this month: Google Play review is now regularly taking longer than a week, where it used to be hours. Whether that is a permanent shift or a queue problem, it changes something concrete. Review latency is no longer a rounding error at the end of your release. It is the longest single step, and it is the one step you cannot optimise.

So the process has to absorb it. Here is what that actually means, from a month of shipping across both stores.

The thing that actually costs you a week is a rejection

A seven-day review that approves costs you seven days once. A seven-day review that rejects costs you seven days, plus however long you take to understand the rejection, plus another seven days. The compounding is the problem, not the latency.

Which means the highest-leverage work is not "submit earlier". It is "do not get rejected", and the failure modes are boringly consistent:

• Metadata that is incomplete in a language you do not read. We had a tvOS submission bounce with nothing more than a generic error from the API. The web console eventually listed the real cause: the Traditional Chinese description, keywords and support URL were missing, and so was the Simplified Chinese description. The submission endpoint knew that. It just would not say so.
• Entitlements you cannot back. Claiming something restricted without a provisioning profile that grants it gets caught late and explained badly.
• A demo path a reviewer cannot walk. If your app needs credentials the reviewer does not have, you need a demo mode that works with no network and no account, and you need to say so in the review notes.

Read the rejection in the console, not the API

This is the single most useful operational habit we picked up.

App Store Connect's API will hand you a 409 or a 500 and a message that could mean anything. The web interface, for the same submission, enumerates the actual missing fields. If you are automating submissions — and you should be, the API is far better than clicking — automate the submission, then open the console to read failures. The two surfaces do not carry the same information, and the one that does is the one you are not scripting.

For historical failures the notary and review logs are worth pulling directly:

xcrun notarytool log <submission-id> \
  --key ./AuthKey_XXXXXXXX.p8 --key-id XXXXXXXX --issuer <issuer-uuid>

We used exactly this to find out why a DMG had failed months earlier. The answer — a bundled helper signed without a Developer ID certificate, missing a secure timestamp, and carrying get-task-allow — was in the log the whole time and nowhere else.

Decouple the artifact from the announcement

If review is a week, then "ship" and "announce" cannot be the same event.

Structure the release so the artifact is final and reviewable days before anyone outside needs to know. That means:

• The version in review is the version you intend to ship, not a placeholder you plan to replace. Every replacement restarts the clock.
• On Google Play specifically, submitting a new change cancels and restarts a review already in progress — and it does so silently through the API. If you push an update while something is in review, you have not sped anything up; you have thrown away the days already served.
• Release notes, screenshots and store copy are part of the artifact. Finishing them after submission means editing the thing under review.

Keep a channel you control

The strongest structural answer to review latency is to not have every path to your users run through a queue.

For desktop software that means a signed, notarized direct download alongside the store build. It is more work — code signing, notarization, stapling, hosting, update delivery — and the platform differences are real. But when the store build is stuck behind a week of review, a direct build is the difference between "our users have the fix" and "our users will have the fix next Thursday."

That is not an argument against the stores. Distribution, discovery, payment and trust are genuinely valuable and worth the queue. It is an argument against having exactly one door.

What we changed

Three things, all process rather than code:

1. Submit the finished thing. Metadata, screenshots and notes complete in every language the listing declares, before the build goes up.
2. Treat rejections as console work. Automate submission, read failures in the web UI, and keep the notary log command handy for anything older than a day.
3. Never touch a review in flight. Especially on Play, where the restart is silent.

None of that makes review faster. It makes the week cost you once.