How to Update Your App on the App Store & Google Play

Shipping version 1.0 is a milestone. Keeping the app alive after that — fixing bugs, adding features, refreshing screenshots when the stores change their specs — is where most of the real work lives. The update flow is shorter than a first launch, but the small rules trip people up: version numbers that won't increment, phased rollouts that stall, metadata changes that quietly need a new build.

Here's the short answer on how to update your app: bump the version number, generate a new signed build, refresh any metadata you want to change, upload it to App Store Connect or Google Play Console, and submit the new version for review. Below is the full process for both stores, plus the differences that matter and the mistakes worth avoiding.

What actually changes in an app update

An update can include any mix of three things:

New code — bug fixes, features, performance improvements. This requires a brand-new build.
New metadata — description, keywords, subtitle, what's-new text. Sometimes needs a build, sometimes doesn't (details below).
New store assets — screenshots, feature graphic, app preview video, icon.

The version number you increment tells the stores — and your users — which kind of change shipped. A good habit is semantic versioning: MAJOR.MINOR.PATCH, e.g. 2.1.4. Bump the patch digit for a bug fix, the minor digit for new features, the major digit for a big redesign. Neither store enforces this scheme, but it keeps your release notes honest.

Step 1: Increment the version and build number

This is the number-one cause of a failed update, so do it first.

Both stores reject any binary that reuses a version or build number you've already uploaded. If you're publishing from Adalo, open Settings → App Settings and raise the version there before you generate the build; Adalo increments the build number for each new build automatically. If you touch the raw project files, the two values to update are:

Platform	Version (user-facing)	Build number (internal)
iOS	`CFBundleShortVersionString` (e.g. `1.2.1`)	`CFBundleVersion` — must be higher than the last upload
Android	`versionName` (e.g. `1.2.1`)	`versionCode` — an integer that must increase every build

The user-facing version can repeat across platforms; the internal build number cannot repeat within a platform. If you see "redundant binary" (Apple) or "version code already used" (Google), this is what's wrong.

Step 2: Generate the new build

Rebuild the app after the version bump — not before, or the new build will carry the old number. If you build with a no-code tool, this is a cloud compile that produces a signed .IPA (iOS) and .AAB (Android). The same signing identity and bundle ID / package name must match your original release exactly; an update with a different bundle ID is treated as a different app entirely and will not attach to your existing listing.

If you're publishing an Adalo app specifically, the mechanics of generating and uploading builds are covered end to end in how to publish an Adalo app. The update flow reuses that same Publish step — you're just doing it with a higher version.

Step 3: Update the App Store version

In App Store Connect, open your app and click the + Version or Platform button to create a new version record (e.g. 1.2.1).
Fill in the What's New in This Version notes. This is the changelog users see — keep it specific ("Fixed a crash when opening the calendar" beats "Bug fixes and improvements").
Once your new build finishes processing, attach it in the Build section.
Update any metadata tied to this version — description, keywords, screenshots — if you're changing them.
Answer the export-compliance prompt, then click Add for Review and submit.

Which App Store changes need a new build?

Most metadata on the App Store is version-scoped, so you usually change it alongside a build. The exception is promotional text (the 170-character blurb above your description), which you can edit at any time without submitting a new version. Screenshots, description, keywords, and subtitle changes generally ride along with a version submission.

Step 4: Update the Google Play release

In Google Play Console, go to Production (or a testing track first — recommended for big changes) and click Create new release.
Upload the new .AAB. The versionCode must be higher than your live release.
Add release notes for the changelog.
Review the release summary, then Save and publish.

Metadata-only updates on Google Play

Google is more flexible than Apple here. You can edit your store listing — title, short and full descriptions, screenshots, feature graphic — under Grow → Store presence → Main store listing without shipping a new build at all. These changes go through their own (usually quick) review and publish independently of your app binary.

Step 5: Roll out gradually (staged & phased release)

You don't have to push an update to 100% of users on day one. Both stores let you release slowly so a bad bug hits a small fraction of users, not everyone.

Feature	Apple	Google
Name	Phased Release	Staged rollout
Default schedule	7-day ramp (1%, 2%, 5%, 10%, 20%, 50%, 100%)	You set the percentage (e.g. 10%, then 50%, then 100%)
Pause it	Yes	Yes
Halt a bad build	Pause, then ship an expedited fix	Halt the rollout entirely

Turn on phased release for anything bigger than a trivial fix. If crash reports spike, pause the rollout and ship a patch before it reaches your whole base.

Update checklist

[ ] Version number incremented (user-facing) and build number raised (internal)
[ ] Bundle ID / package name unchanged from the original release
[ ] New build generated after the version bump
[ ] What's New / release notes written and specific
[ ] Metadata refreshed if needed (description, keywords, screenshots)
[ ] Screenshots re-exported at current store sizes if the UI changed
[ ] Data Safety / App Privacy answers updated if data practices changed
[ ] Phased/staged rollout enabled for anything non-trivial
[ ] Submitted for review on both stores

When an update is a good moment to refresh your assets

Updates aren't only for code. They're the natural time to fix things you shipped in a hurry at launch. If your screenshots are stale, off-spec for the latest devices, or just underperforming, re-export them at the current dimensions — the App Store screenshot sizes reference has the full 2026 spec table, and Adalo Studio's screenshot generator exports every size the stores accept without cropping. Refreshing screenshots and the description is one of the highest-leverage moves in ASO for indie developers, and an update is the moment to do it.

If you're still deciding whether all this is worth a paid tier, the Adalo Studio pricing page spells out what's free versus a one-time unlock.

A realistic update timeline

Minor fix (metadata only, Google Play): publish in minutes to hours.
Bug-fix build (both stores): rebuild same day, Apple review usually 24–48 hours, Google 1–3 days.
Feature release with new screenshots: budget a day for assets, then normal review windows.

Because your app is already approved, update review is generally faster than your first submission — the reviewers have context, and you're not clearing the initial account and content checks again.

Frequently asked questions

Do app updates go through review again?

Yes. Every new version you submit to the App Store or Google Play goes through review, though updates to an already-approved app are usually faster than a first submission. Metadata-only changes on Google Play can sometimes publish without a full re-review.

Do I have to update the version number for every app update?

Yes. Both stores reject a build that reuses a version or build number you've already uploaded. Increment the version (for example 1.2.0 to 1.2.1 for a fix, or 1.3.0 for new features) and let the build number rise with each new build.

Can I update just my screenshots or description without submitting a new build?

On Google Play, yes — store listing text and graphics can be edited on their own. On the App Store, most metadata changes are tied to a new app version, so you typically submit them alongside a build, though promotional text can be changed anytime.

Tools mentioned in this guide: App Store Screenshot Generator, App Privacy Policy Generator.