Google raises the bar every year
New apps and updates must target a recent Android version by Google's yearly deadline. An old template cannot be uploaded after that date; the target API level guide explains the timing.
Instant or store update?
| Change | How it ships | Notes |
|---|---|---|
| New pages, features, bug fixes, design changes in the web app | Instant: deploy in Lovable, Bolt, Vercel or your host | Every installed app shows it on the next load; no review |
| Copy, prices shown on the web, legal pages | Instant | Keep in-app purchase prices in the stores in sync with what the app displays |
| App icon, app name, splash screen | Store update | Native assets inside the build |
| Enabling a native feature (push provider, biometrics, QR scanner, AdMob, RevenueCat) | Store update | A Config switch plus a rebuild; new permissions are reviewed |
| New permission texts (camera, location, photos) | Store update | Also update the App Privacy answers and the Data safety form if data use changes |
| Changing the start URL or domain | Store update | Avoid by choosing the custom domain before launch |
| WebViewGold template update (new iOS SDK, Play target API level, privacy manifests) | Store update | Free updates; needed roughly yearly to stay publishable |
| Store listing text and screenshots | No build, but review | App Store: screenshots, description and keywords change only with a new version; promotional text and URLs any time. Play: listing changes any time, reviewed |
Versioning done right
iOS has two numbers: the version (CFBundleShortVersionString, for example 1.2.0) that users see, and the build number (CFBundleVersion) that must increase with every upload, even for the same version. Android has versionName (free text, shown to users) and versionCode, an integer that must increase with every upload to the Play Console. Set them in Xcode's General tab and in build.gradle, or in the matching fields of the Cloud Builder. Keep the user-facing version identical on both platforms and use major.minor.patch; it makes support conversations ("which version are you on?") painless.
Your web app has its own release rhythm, and the two can drift apart in one important way: a web feature that needs a native capability (say, a new QR flow) will not work in app versions built before the capability was enabled. WebViewGold's App Version Check API solves this: navigate to getappversion:// and the app sets window.versionNumber and window.bundleNumber (or set autoInjectVariable / AUTO_INJECT_VARIABLES to true to get them injected on every page). Your web app can then hide the feature or show an update banner for old installs. Docs: App Version Check (iOS) and Android.
Nudge users on old app versions
Runs on every page load inside the app. Compare against the lowest version that supports the current web app.
javascript
const inApp = /WebViewGoldApp/.test(navigator.userAgent);
const MIN_APP_VERSION = "1.3.0";
function olderThan(a, b) { // "1.2.9" < "1.3.0"
const pa = a.split(".").map(Number), pb = b.split(".").map(Number);
for (let i = 0; i < 3; i++) { if ((pa[i] || 0) !== (pb[i] || 0)) return (pa[i] || 0) < (pb[i] || 0); }
return false;
}
if (inApp) {
window.location.href = "getappversion://"; // WebViewGold sets window.versionNumber
setTimeout(() => {
if (window.versionNumber && olderThan(String(window.versionNumber), MIN_APP_VERSION)) {
document.getElementById("update-banner").hidden = false; // "A new version is available" + store link
}
}, 800);
}
I am very happy I bought this app! Extremely easy and great documentation. Was in contact with the customer service, they replied very quickly and very friendly. They solved my question within a day. 10/10 would recommend.
The store release routine
About an hour of work plus review time. Do it whenever a row in the table above says "store update".
Refresh the WebViewGold template if an update is available
Download the current version (updates are free), then copy over your Config.swift and Config.java values, icon, splash, GoogleService-Info.plist or google-services.json and any custom permission texts. Your Android keystore and upload key stay the same. Cloud Builder users skip this step: the service builds with the maintained template.
Bump the version and build numbers
Version 1.2.0 → 1.3.0, build number +1, versionCode +1.
Build and upload
Xcode → Product → Archive → Distribute to App Store Connect; Android Studio → Build → Generate Signed Bundle → upload to the Play Console. Or one click in the Cloud Builder for both.
Smoke-test the build
TestFlight internal testing and the Play internal track: login, push permission, offline screen, a deep link from an email, one purchase in sandbox if you sell anything. Fifteen minutes on a real phone; see the testing guide.
Submit with a phased rollout
Apple: choose phased release (seven days, automatically increasing percentage, pausable) or manual release after approval. Google: staged rollout, start at 10 to 20 percent and raise it over a few days; halt if Play vitals show a crash spike.
Watch the first 48 hours
App Store Connect crashes and reviews, Play Console vitals and policy emails. Web-side fixes still ship instantly while the native build rolls out.
Things that silently break after a web deploy
- Changing the domain or adding a redirect on the start URL: the app still loads the old URL baked into the build.
- Deleting or moving /.well-known/apple-app-site-association and assetlinks.json: deep links and magic links stop opening the app.
- Changing OAuth redirect URLs or the Supabase Site URL without updating the providers.
- A new cookie banner, "open in our app" smart banner or desktop header showing inside the app: hide it for the app user agent with your CSS or WebViewGold's custom CSS injection.
- A redesign that drops the Delete account button or the privacy policy link. The next store review will notice.
- A service worker that keeps serving the old bundle inside the app: bump the cache version on every deploy.
- Heavier JavaScript that pushes the first paint past the splash timeout; raise
splashTimeoutor enableremainSplashOption.
Keep the WebViewGold template current
Apple requires recent SDKs
Uploads must be built with a recent Xcode and iOS SDK, and iOS apps now ship privacy manifests. Template updates carry both.
New native features arrive
Updates add APIs (document scanner, health data, widgets) that you can expose to your web app with one link each.
A yearly rebuild is a good habit
Even without changes, a rebuild on the current template once a year keeps the app publishable and the "updated" date fresh for ASO.
Frequently asked questions
Do web changes trigger an App Store review?
No. Review happens only when you submit a new build or change listing metadata. Content inside the web app is yours to change, as long as the app keeps matching its listing and the guidelines.
How often should I rebuild the native app?
At least once a year for platform requirements, plus whenever you change an icon, a native feature or a permission. Many teams settle on a store update every one to two months.
Can I force users to update?
Not forcibly, but the version check lets you block old app versions behind a message with a store link when a backend change requires it.
Does a store update log users out?
No. Cookies and localStorage survive updates unless the cache-clearing options in the Config files are enabled.
Three ways to get your app into the stores
Same result, different amount of work on your side. All three come with the approval guarantee and 24/7 human support.
Do it yourself
$109 per platform, one-time
The WebViewGold license: a finished Xcode or Android Studio project. Paste your URL, set name and icon, switch on features, build and submit. Free updates forever.
See plans on the main pageCloud Builder
$349 per license, one-time add-on
No Mac, no Xcode, no Android Studio: configure in the browser, we build both apps in the cloud and hand them to App Store Connect and the Play Console.
How the Cloud Builder works Try the free demoFull Service
$698 per platform $798
Send us your URL and icon. Our team configures, builds and delivers your app within 72 hours, white-label, with source projects. Both platforms for $1,158.
Full Service details Powered by
Winter Sale prices valid until December 31, 2026.