How updates work after the first launch
A released app becomes the starting point for the next release; updates still require identity continuity and, when native inputs change, a new build.
Same app identity
Keep the same Apple bundle identifier and Android package name when updating the same store application. Changing those identifiers generally means a different app identity rather than a normal update.
Versioning
Each store has version/build rules. Increment the appropriate marketing version and/or build number or version code as required by the provider and your current release state.
Web-only changes
For a deliberately hosted live-URL wrapper, some web content can change without a new native binary because the shell loads the hosted app. That does not bypass store rules for changes that materially alter regulated/native behavior, nor does it update embedded native code or metadata.
Native changes
Changes to native plugins, entitlements, permissions, embedded SDKs, signing, compiled assets, native configuration, or native application code require a new build and another release cycle.
Store metadata changes
Some listing fields and screenshots can be changed independently of the binary when the provider allows it; other metadata is version-scoped or review-scoped. Provider state is authoritative.
Existing-build replacement
When replacing a build, upload a newly built artifact with valid identity and versioning rather than trying to mutate the old uploaded binary.
Release history
Keep build, deployment, and approval history intact so you can tell which source/configuration produced which artifact and which artifact reached which provider state.