Can I update a Despia app during the 14-day closed test?

Yes. Despia's default remote loading means the app fetches the current version from your URL at launch, so web-layer fixes reach testers over the air without a new build or a new review. Use it for bug fixes, but avoid changing features mid-window, or the feedback you collected will describe a product that no longer exists.

Do WebView apps get rejected by Google Play?

Not because they use a WebView, but Play policy is unfriendly to apps that offer little more than a website in a frame. Using native capability such as push notifications, device features and a real offline state, rather than shipping a bare wrapper, both improves review odds and gives testers something to actually report on.

What breaks most often in WebView-based Android apps during closed testing?

System window insets, which leave bottom navigation hidden behind the Android navigation bar; back-button behaviour that exits the app from a sub-screen instead of navigating history; and a missing offline state, which shows a blank screen when the network drops. All three surface on real low-end devices rather than in a desktop browser.

Despia

Publishing a Despia app to Google Play

Q: Does a Despia app still need 12 testers for Google Play?

Yes. The requirement attaches to the Google Play developer account, not to the build tool. A personal developer account created after 13 November 2023 must run a closed test with at least 12 testers opted in for the last 14 consecutive days before applying for production access, regardless of whether the app was built in Despia, Base44, Lovable, Bolt or native code.

Updated: 2026-08-02

Despia turns a web app into native iOS and Android builds and lets you submit from the browser, with no Mac and no CLI. That removes the packaging problem. It does not remove Google's closed testing requirement — and the way Despia ships content creates one wrinkle during the 14-day window that catches people out.

Short answer: the 12 testers requirement attaches to your Google Play developer account, not to how the app was built. A Despia build from a new personal account needs the same 12 testers opted in for 14 consecutive days as anything else. What changes is that Despia's remote loading lets you fix the app mid-cycle without resubmitting a build — which is a real advantage and a real trap.

Why the requirement still applies

Google gates on the account, not the toolchain. Personal developer accounts created after 13 November 2023 must run a closed test with at least 12 testers opted in for the last 14 consecutive days before they can apply for production access. Building in Despia, Base44, Lovable, Bolt or Android Studio makes no difference to that gate.

What Despia does change is the part before it. Getting a signed Android build onto a closed testing track is usually where no-code founders stall, and browser-based signing and submission removes that step. You arrive at the testing requirement faster — which is exactly why so many Despia users hit it as their first real blocker.

The remote loading wrinkle

By default a Despia build ships without embedded assets and loads the current version from your URL at launch. Web changes go out over the air; you only resubmit when the native layer changes. During a 14-day closed test that cuts both ways.

What it means	Why it helps	Where it bites
Testers load your live site on every launch	A bug a tester finds on day 3 can be fixed on day 3, with no new build and no review wait.	Your site going down means the app is blank for every tester until you notice.
The build in the track rarely changes	No release churn, no re-review of the native shell mid-cycle.	Nothing in Play Console reflects what testers are actually seeing.
You can change anything, any time	You can ship the fixes your feedback produced before you apply.	Change the product mid-window and your testers tested something that no longer exists.

The practical rule: fix bugs during the window, freeze features. Google's production questionnaire asks what you changed based on testing — bug fixes are a great answer. Rewriting the app halfway through means the feedback you collected describes a different product, and you will notice when you try to write that answer honestly.

What WebView-based apps get caught on

Thin-wrapper risk

Play policy is unfriendly to apps that are little more than a website in a frame with no app-like value. Despia exposes native device capability through a single JavaScript call — use some of it. Push, camera, haptics, offline handling: anything that makes the thing behave like an app rather than a bookmark improves both your review odds and what testers have to say about it.

The offline and dead-network state

Remote loading means no connection can mean no app. Testers on 4 GB Android devices on patchy mobile data will find this before your reviewer does. Make sure there is a real offline state rather than a white screen.

System insets and the navigation bar

The single most common finding we see in WebView-based apps: bottom navigation sitting underneath the Android system navigation bar because window insets are not handled. It looks fine in a desktop browser and broken on a real phone.

Back-button behaviour

Android's hardware and gesture back must move through your app's history sensibly, not dump the user out of the app from a sub-screen. Testers notice this immediately.

Data Safety has to match reality

Your Data Safety form describes what the app collects — including anything your web layer collects through analytics or sign-in. A wrapper does not exempt you, and a mismatch here is a release-review problem rather than a testing one.

The order that works

Ship the build to a closed track

Get the Despia Android build onto a closed testing track and confirm the release is actually live, not sitting in draft.

Sanity-check on a low-end device

Before testers arrive. Insets, back button, offline state, first-launch time. Fixing these on day 0 costs nothing; finding them on day 9 costs feedback quality.

Enroll 12 testers and start the clock

Google counts the 14 days per tester, so a dropout on day 2 is recoverable and one on day 13 is not.

Fix over the air, log every fix

This is your advantage. Every bug fixed during the window is material for the production questionnaire.

Freeze, then apply

Stop changing the product before the window ends so your feedback and your app describe the same thing.

Building in one of the AI builders Despia supports? We have dedicated guides for Base44 and Lovable. Related: the 12 testers requirement explained, the production questionnaire question by question, and why testers cannot open your opt-in link.

Stuck at the 12 testers stage?

We run the cycle so you can keep shipping.

Real testers enrolled for the full 14 days, daily enrollment checks, and a QA report you can answer Google's production questionnaire from. Plans from $180, worldwide.

Start your testing cycle