Every Android app has two version identifiers: a version code and a version name. Understanding both is essential for managing updates to your app on Google Play.
Version Code vs Version Name
Version Code
An integer used internally by Android and Google Play to determine app update ordering. Each new release submitted to Google Play must have a higher version code than the previous release. Users don't see this number directly.
Example: Version code 1 for your first release, 2 for the next, 3 for the one after that.
Version Name
A human-readable string displayed to users in the Play Store and in the app's details. Can be any format: 1.0.0, 2.1, March 2026, or any convention you choose.
Most developers use semantic versioning (MAJOR.MINOR.PATCH) for version names: 1.0.0, 1.1.0, 2.0.0.
How WebToAppConvert Handles Versioning
Version code is incremented automatically with each Starter or Professional build. You don't need to manually track version codes: the build server ensures each release build has a higher version code than the previous one for that app.
Version name is set by you in the app configuration. It defaults to 1.0.0 and should be updated manually before significant releases.
The Update Process
When you want to update your app on Google Play (for configuration changes: not content updates, which are live automatically):
- Make your configuration changes in the dashboard (new icon, updated permissions, new Firebase config, etc.)
- Update the version name if this is a significant release
- Run a Debug build and test the changes
- Run a Starter or Professional build once testing passes
- Download the new AAB
- In Google Play Console, go to your app's Production track
- Click Create new release
- Upload the new AAB
- Add release notes describing what's new
- Roll out the release
Google Play handles distributing the update to users automatically. Users who have your app installed will receive the update notification through the Play Store's automatic update mechanism.
Release Notes
Release notes ("What's new") are displayed in the Play Store when users view your app listing or when they receive an update notification. Keep them informative and user-focused:
- Clear: "Added push notifications for new posts and events"
- Not technical: Don't mention version codes, Gradle, or AAB
- Brief: 2–4 bullet points for a minor update, a short paragraph for a major one
Content Updates Don't Require a Rebuild
A frequent source of confusion: changes to your website content do not require rebuilding or resubmitting the app. When you add a new blog post, update your pricing page, or change your menu, those changes are visible in the app immediately because the WebView loads your live URL.
You only need a rebuild when the app's configuration changes: icon, permissions, Firebase setup, WebView behavior, or feature set. For most apps, rebuilds happen once or twice a year at most.
Version Code Gaps
If you've run several builds (including debug builds that were never uploaded to Play), your version code may be higher than the number of releases you've published. This is fine: Google Play only requires that each new upload has a higher version code than the previous upload. Gaps are allowed and don't cause any issues.