Quick answer: to update a ZIP-to-APK app, upload the new ZIP to the builder, keep the same package name and the same signing key, set a higher versionCode (and a new versionName), and rebuild. The new APK installs over the old one and keeps its data; on Google Play, upload the new AAB as a new release. Change the package name or the key and Android treats it as a different app.
The two things that must not change
- Package name. It is the app's identity. A build with a different package name installs beside the old app, not over it, and on Play it is a new listing.
- Signing key. Android accepts an update only from the same certificate. On the free tier the builder's key is stable, so this is automatic. With Pro and your own keystore, use the same file and alias every time — the signing guide.
The one thing that must go up
versionCode. An integer; the installer and Play both refuse a build whose code is not higher than the one they know. Use any scheme that only rises — sequential is simplest for ZIP rebuilds; the version planner shows three. Keep a note of the last one in your project folder. Change versionName too ("1.0" → "1.1") so people can see which version they have.
Everything else can change
The app name, the icon, the splash, the orientation, the content — all free to change between builds. A rebranding is an update, not a new app, as long as the package name and key stay.
Updating a sideloaded app
- Build the new APK.
- Replace the file at the URL people downloaded from — same link, same QR code, new file.
- Tell users to download and open it. Android shows "Do you want to update this app?" and installs over the existing one. Data is kept.
There is no automatic update for sideloaded apps. If that matters, the app itself can check a version file on your server when online and show a "New version available" link; that is ordinary JavaScript in your pages, fetching an https:// URL.
Updating on Google Play
- Build the new AAB with Pro, same keystore, higher versionCode.
- Play Console → Production (or a test track) → Create new release → upload → release notes → review and roll out.
- Review is usually quicker than the first submission. Staged rollout (e.g. 20% first) is available for production.
Users receive it through Play's normal auto-update within a day or so.
What happens to saved data
localStorage, IndexedDB and anything else the WebView stored live in the app's private directory. An in-place update leaves that directory alone. Data is lost only when the app is uninstalled — which happens implicitly if a user has to remove the old version because the key or package name changed. Preserve identity, preserve data.
When an update is refused
| Message | Cause |
|---|---|
| App not installed (phone) | Different signing key, or versionCode not higher |
| Version code X has already been used (Play) | Reused or lower versionCode |
| Your Android App Bundle is signed with the wrong key (Play) | Different upload key; request a reset if lost |
| Package name mismatch (Play) | Different package name — this is a new app to Play |
Checklist for every update
- Same package name
- Same keystore and alias (Pro) — or free tier, which is automatic
- versionCode higher than last time; versionName bumped
- New ZIP checked (index.html at root, relative paths)
- Tested from file:// and offline on a phone
- File replaced at the download URL, or AAB uploaded to Play