The first update: what changes after launch
Three things change after launch, and the first one surprises people.
1. Updates are reviewed, and version one being approved is not a precedent. A different reviewer looks at it, guidelines change, and an update can be rejected for something that shipped in the approved original. That is normal, not evidence that something went wrong.
2. Mistakes are expensive now. Before launch a bad build cost you a review cycle. After launch it reaches real users, and the only lever you have once it is live is a phased or staged release, which limits how many people a bad build reaches and can be paused. Use it from the first update, not after the first incident.
3. Over-the-air updates become relevant. In a React Native or Expo app a JavaScript-only fix can ship without a new binary. Supported, useful, and limited: an update must not change what the app fundamentally does, which is a Guideline 2.3.1 question. Disclose that you use it in the review notes; it costs three lines.
And the mistake that costs a whole cycle for nothing: submitting metadata changes separately from the build. Name, subtitle, keywords, description and screenshots each require a review, so bundle them into the build you are already submitting.
The pre-update pass
Shorter than the first submission and not empty:
Anything that changed in the dependency tree. A new SDK can introduce a privacy manifest obligation, a permission, or a required-reason API you did not have. ITMS-91061. · When a dependency blocks your release.
Anything that changed about data collection. New analytics, a new backend, a new third-party service. That changes your App Privacy label and your Play Data safety form, and neither updates itself. App privacy labels. · Play Data safety.
Any new feature that touches a guideline. Accounts introduce 5.1.1(v) account deletion. Social login introduces 4.8. User content introduces 1.2. A subscription introduces 3.1.2.
The upgrade path. Install the previous version, use it, create data, then upgrade to the new build. Nobody tests this and it is the single most common source of a bad first update, because the fresh-install path works and the upgrade path has a migration in it.
The upgrade test, written out
1. Install the currently live version from TestFlight or the store.
2. Create an account and some data. Use it properly.
3. Install the new build over the top. Do not delete first.
4. Open it. Is the data there?
5. Is anything asking to be set up again?
6. Force quit, reopen, check again.
7. Repeat on a device with a slow connection.Step four is the whole test. A migration that silently drops data is worse than any rejection.
Phased release
Apple: phased release for automatic updates, over several days, pausable.
Google: staged rollouts by percentage, pausable, and you can halt a bad rollout.
Use both from the first update. The cost is that the rollout takes longer. The benefit is that a bad build reaches a fraction of your users and you can stop it, which is the only control you have after release. When your app is removed or suspended.
And watch crash rates during the rollout, not after it completes. A rollout you are not watching is just a slower release.
Ratings, done properly
The system prompt, after a moment where the app has clearly worked for them. Not on first launch, not after an error.
Ask everyone the same way. Selecting who gets asked based on expected sentiment, or routing unhappy users to a private form, is prohibited and is separately a consumer-protection issue in the US. Guideline 3.2.2.
What to expect
An update can be rejected. It happens to established apps constantly and it is not a signal about your app's standing.
Review timing varies. Do not build a launch plan that requires a specific turnaround.
Users see the release notes. Write what changed, plainly. "Bug fixes and improvements" is a missed opportunity every single time.
After a rejection. · What changes at each OS release. · The first-submission checklist.
shipcheck runs the same pass on an update as on a first submission, which is the point: the things that changed are the things nobody re-checks. What it checks.
More in this section
About shipcheck
shipcheck is a pre-submission checker from Baker Ventures LLC that runs inside Claude Code. It reads your React Native or Expo project, finds the things that get apps rejected or blocked at upload, cites the exact App Store Review Guideline or Google Play policy clause, and names the file and line to fix.
It exists because React Native and Expo apps fail for reasons that are invisible in the code you wrote: capability arriving through a dependency, purpose strings added by a config plugin, a privacy manifest missing from an SDK you never chose directly, and a generated ios/ directory that discards your edits on the next prebuild. shipcheck checks what the binary and the config actually declare, not what you intended. The rejection references on this site are free, need no account, and link to the primary Apple or Google document for every claim.
Questions and answers
Are app updates reviewed?
Yes. Every version goes through review, and an update can be rejected for something that was in the original approved build, because a different reviewer looks at it. Approval of version one is not a precedent.
What is phased release and should I use it?
A staged rollout to a percentage of users over several days. It is worth using from your first update, because it limits how many people a bad build reaches and it can be paused, which is the only lever you have once something is live.
Can I fix a bug without submitting a new build?
In a React Native or Expo app, a JavaScript-only fix can ship over the air. That is supported and its limit is that an update must not change what the app fundamentally does, which is a Guideline 2.3.1 question.
Why did my update get rejected when version one was approved?
Because review is performed by people, guidelines change, and a reviewer may notice something the first one did not. It is not evidence that anything went wrong; it is a normal property of the process.
When should I ask users for a rating?
Through the system prompt, after a moment where the app has clearly worked for them, and not on first launch. Manipulating who gets asked based on expected sentiment is prohibited and is also a consumer-protection issue.
What is the most common first-update mistake?
Changing metadata and the build in separate submissions. Each metadata change requires its own review, so bundling them into the build you are already submitting saves a full cycle.
shipcheck. “The first update: what changes after launch.” Baker Ventures LLC, September 7, 2026. https://shipcheck.bakerventuresstudio.com/guides/shipping-your-first-update/