Anything served by your website — pages, prices, design, menus, new features written in HTML, CSS and JavaScript — updates in the app the next time it loads, with no rebuild and no store review. You need a new build (same package name and key, higher version code) only to change the app itself: name, icon, splash, start URL, link scope, permissions, push or other native features, and the yearly target API level.
The line, in one table
| Change | Rebuild? |
|---|---|
| Text, images, products, posts | No |
| Site design, menus, new pages | No |
| New web features (forms, chat, maps) | No — unless they need a new permission |
| App name, icon, splash, theme colour | Yes |
| Start URL or in-app domains | Yes |
| Camera, location, notification permissions | Yes |
| Push SDK, App Links hosts | Yes |
| Google Play's target API deadline | Yes, about once a year |
How to ship a new version
- Build with the same package name and same signing key (or upload key for Play).
- Raise
versionCode(a whole number Android compares) and set a readableversionNamelike 1.1. - Upload the AAB to Play; users get it through normal updates. Sideloaded users install the new APK over the old one.
Caching can make “instant” look slow
The WebView caches like a browser. If users still see old CSS after a deploy, version your asset URLs (style.css?v=42) or send sensible cache headers. Pull-to-refresh helps users, but don't rely on it.
Feature-flag the app
Because your site can detect the app (app mode snippet), you can ship app-only tweaks — a different footer, a bigger tap target, hidden banners — on your website, instantly, without touching the app.
FAQ
Do users need to update the app when I change my website?
No. They see changes the next time a page loads.
What if I lost the signing key?
Without it you can't update a sideloaded app. On Play with Play App Signing, you can ask Google to reset the upload key.