TWA-app afgewezen op Google Play? Stap over op WebView

Dit is een van de frustrerendste afwijzingen voor een zelfstandige ontwikkelaar. Je testers waren echt actief. Je had 12 mensen. De 14 dagen waren voorbij. Toch antwoordde Google dat "your testers were not engaged enough". Heb je de app gebouwd als Trusted Web Activity (TWA) of PWA-wrapper, dan beeld je je het patroon niet in. Bij de meer dan 7.400 apps die wij hebben begeleid, krijgen wrapper-builds deze afwijzing veel vaker dan gewone native of WebView-builds. Deze gids legt uit waarom, toont het belangrijke architectuurverschil en helpt je overstappen zonder de testdagen die je al hebt opgebouwd weg te gooien.

Waarom worden TWA-apps bij de gesloten test afgewezen?

Een Trusted Web Activity rendert je website via Chrome Custom Tabs in plaats van de schermen binnen je eigen app te tekenen. Het is een snelle manier om een site of PWA installeerbaar te maken en voor veel apps in productie werkt dat prima. Het probleem ontstaat vooral wanneer een persoonlijk ontwikkelaarsaccount eerst de gesloten test van 14 dagen moet doorlopen voordat het productietoegang kan aanvragen.

In onze ervaring met meer dan 7.400 apps krijgen TWA-builds en PWA-wrappers de afwijzing "testers were not engaged" veel vaker dan gewone native apps, zelfs wanneer testers de app elke dag gebruikten. Het patroon is zo consistent dat we ontwikkelaars WebView adviseren zolang hun app de gesloten test nog moet halen.

Wat is een TWA werkelijk en hoe wordt die gebouwd?

Voor je de afwijzing oplost, is het nuttig precies te begrijpen wat je hebt gepubliceerd. Een Trusted Web Activity is een Android-app die in wezen je website schermvullend in een echte browserengine draait, zonder adresbalk of andere browserinterface. Voor de gebruiker ziet hij eruit en voelt hij aan als een native app. Onder de motorkap blijft het je live website.

TWA-apps worden meestal gemaakt met de Bubblewrap-CLI van Google of met PWABuilder. Beide bouwen voort op de bibliotheek androidbrowserhelper van Google. Je geeft de tool een URL, hij maakt een Android-project, waarna je het ondertekent en de AAB naar Google Play uploadt.

Waarom ontwikkelaars voor een TWA kiezen

De keerzijde die de afwijzing veroorzaakt

Wat een TWA goedkoop maakt, maakt hem kwetsbaar bij de gesloten test:

• Internet is nodig. De app is een venster naar je site, dus een zwakke verbinding betekent een zwakke app tenzij je PWA goede offline-ondersteuning heeft.
• Risico op afwijzing in de Play Store. Het beleid voor minimale functionaliteit en herverpakte content richt zich op apps die slechts een website in een wrapper zijn. Een TWA zonder echte native mogelijkheden kan worden afgewezen of verwijderd. Native functies zoals pushmeldingen, offlinemodus, camera of share targets helpen je aan de juiste kant van die grens te blijven.
• Het probleem met gebruikssignalen uit de vorige sectie verklaart waarom persoonlijke accounts bij de gesloten test van 14 dagen de melding "testers not engaged" blijven krijgen.

Het misverstand: een TWA is GEEN WebView

Dit is waar veel artikelen de fout in gaan. Nauwkeurigheid is belangrijk, omdat dit bepaalt hoe je het probleem oplost. Een TWA gebruikt het WebView-component van Android helemaal niet.

Omdat een TWA de engine achter Custom Tabs gebruikt, krijg je dezelfde renderingengine, JavaScript-engine en beveiligingssandbox als in Chrome. Cookies en opslag worden met Chrome gedeeld, browserupdates zijn automatisch en de volledige webstandaard wordt ondersteund. Dat is krachtig voor een gewone gepubliceerde app, maar betekent ook dat je schermen buiten het proces, in Chrome draaien. Daar ligt de waarschijnlijke bron van zowel zwakkere gebruikssignalen als lage aantallen actieve gebruikers.

De startvolgorde, stap voor stap

De vertrouwenscontrole: Digital Asset Links

Chrome verbergt de adresbalk alleen wanneer de app via Digital Asset Links kan aantonen dat hij bij de website hoort. De app declareert welke site hij vertegenwoordigt. De site moet op /.well-known/assetlinks.json een bestand aanbieden met het package en de SHA-256-vingerafdruk van het ondertekeningscertificaat.

[{
  "relation": ["delegate_permission/common.handle_all_urls"],
  "target": {
    "namespace": "android_app",
    "package_name": "com.yourapp.name",
    "sha256_cert_fingerprints": [
      "AB:CD:EF:...:99"  // your signing cert SHA-256
    ]
  }
}]

De route van gebruikssignalen: TWA tegenover WebView

De eenvoudigste manier om de afwijzing te begrijpen, is volgen waar de activiteit van een tester werkelijk terechtkomt. Bij een TWA staan je schermen één laag verder van je app, in Chrome Custom Tabs. Bij een WebView-app draaien dezelfde schermen binnen het proces van je eigen app en worden ze rechtstreeks aan je package toegeschreven. Dat verschil bepaalt hoe sterk de activiteit wordt geregistreerd.

Een TWA herkennen, van buiten en van binnen

Weet je niet zeker of de app die jij of een opdrachtnemer heeft opgeleverd echt een TWA is? Zo stel je het vast, eerst op het oog en daarna definitief via de APK of een aangesloten apparaat.

Snelle visuele aanwijzingen voor gebruikers

• De app gedraagt zich precies als de website, omdat hij de website is.
• Bij een verkeerde configuratie zie je bovenaan een browseradresbalk. Dat is een duidelijke aanwijzing, zie de assetlinks-fout hierboven.
• Content verandert zonder app-update in de Play Store.

Definitieve technische aanwijzingen in de APK of op het apparaat

Bevestig het met adb

Op een aangesloten apparaat of emulator geven twee opdrachten uitsluitsel:

# Is it a TWA? Look for the delegation service:
adb shell dumpsys package <package.name> | grep -i DelegationService

# Which site does it wrap, and is the trust check passing?
adb shell pm get-app-links <package.name>
#   -> "verified"  = Digital Asset Links pass (fullscreen)
#   -> "1024"      = verification failed (address bar shows)

TWA tegenover WebView bij de gesloten test

Beide architecturen verpakken webcontent. Voor de gesloten test van 14 dagen telt vooral waar die content draait en waaraan activiteit wordt toegeschreven. Zo verschillen ze op de punten die bepalen of je in één cyclus productie bereikt.

De oplossing: bouw een gewone WebView-app

In plaats van een TWA te repareren of er sterkere signalen uit te proberen halen, is de duidelijkste route je app rond een WebView-component herbouwen en die build publiceren. Je hebt drie gangbare routes. Alle drie laden je site binnen je eigen app:

De minimale WebView-opzet, klaar om te kopiëren

De kern is klein: een WebView die je URL laadt met JavaScript en opslag ingeschakeld, navigatie binnen de app houdt en de Android-terugknop correct afhandelt. Kies je taal en kopieer de basis:

val webView = findViewById<WebView>(R.id.webview)
webView.settings.apply {
    javaScriptEnabled = true          // most sites need this
    domStorageEnabled = true          // localStorage / sessionStorage
    cacheMode = WebSettings.LOAD_DEFAULT
}

// Keep links INSIDE the app (this is the key difference vs a TWA)
webView.webViewClient = WebViewClient()
webView.loadUrl("https://yourwebsite.com")

// The exact back-button handler Google looks for
onBackPressedDispatcher.addCallback(this, object : OnBackPressedCallback(true) {
    override fun handleOnBackPressed() {
        if (webView.canGoBack()) {
            webView.goBack()
        } else {
            finish()
        }
    }
})

WebView webView = findViewById(R.id.webview);
WebSettings settings = webView.getSettings();
settings.setJavaScriptEnabled(true);      // most sites need this
settings.setDomStorageEnabled(true);      // localStorage / sessionStorage
settings.setCacheMode(WebSettings.LOAD_DEFAULT);

// Keep links INSIDE the app (this is the key difference vs a TWA)
webView.setWebViewClient(new WebViewClient());
webView.loadUrl("https://yourwebsite.com");

// The exact back-button handler Google looks for
getOnBackPressedDispatcher().addCallback(this, new OnBackPressedCallback(true) {
    @Override
    public void handleOnBackPressed() {
        if (webView.canGoBack()) {
            webView.goBack();
        } else {
            finish();
        }
    }
});

# Wrap an existing web/PWA project in a native WebView shell
npm install @capacitor/core @capacitor/cli
npx cap init "YourApp" "com.yourapp.name"

# Point Capacitor at your live site (capacitor.config.ts)
#   server: { url: "https://yourwebsite.com", cleartext: false }

npm install @capacitor/android
npx cap add android
npx cap sync

# Capacitor handles back-button + DOM storage natively.
# Open in Android Studio to build a signed AAB:
npx cap open android

Drie toevoegingen die je voor de beoordeling nodig hebt

Een kale WebView die alleen loadUrl() aanroept, blijft een thin wrapper. Deze drie toevoegingen maken er een echte app van en voorkomen dat testers op lege schermen uitkomen:

Overstappen zonder je teller van 14 dagen terug te zetten

Ben je al halverwege de test, dan hoef je niet opnieuw te beginnen. De teller van 14 dagen blijft bij een app-update lopen zolang je dezelfde testtrack en hetzelfde package name gebruikt. Zo stap je veilig over:

Geldt een WebView-app nog steeds als thin wrapper?

Hier gaat het mis bij ontwikkelaars die WebView als wondermiddel zien. Overstappen van TWA naar WebView pakt het probleem met gebruikssignalen aan, maar stelt je niet vrij van het Google-beleid voor spam en minimale functionaliteit. Een WebView die niet meer is dan je homepage in een kader kan nog steeds als thin wrapper worden afgewezen. Daarmee bedoelen we een dunne wrapper: alleen een ingelijste website zonder echte native meerwaarde.

Zie dit als twee aparte poorten. Een testdienst of een WebView-rebuild kan je bij één poort helpen, maar niet automatisch bij de andere.

Het doel is dus niet alleen WebView in plaats van TWA, maar een WebView-app met genoeg echte waarde en native gedrag om zelfstandig te staan. In de praktijk betekent dat:

Wil je een uitgebreidere checklist van kwaliteitsproblemen? Onze gids over waarom gesloten tests worden afgewezen behandelt de meest voorkomende beleids- en beoordelingsfouten naast gebruikssignalen.

Weet je niet of je app een TWA is? Wij controleren het bij je bestelling

Je hoeft niet zelf adb-opdrachten uit te voeren of door je APK te graven. PrimeTestLab kan voor je vaststellen of je app een TWA is. Zodra je onze testdienst bestelt, inspecteert ons team je build en bepaalt het of het om een TWA of PWA-wrapper gaat. Is dat zo, dan vertellen we precies wat je moet aanpassen voordat je 14 dagen besteedt aan een architectuur die op gebruikssignalen kan stranden.

Wat er gebeurt zodra je bestelt

Hoe PrimeTestLab helpt bij de andere helft van het probleem

Architectuur is de ene helft. De andere helft, waar veel zelfstandige ontwikkelaars vastlopen, is 12 testers vinden die zich echt aanmelden en 14 dagen aangemeld blijven. Dat regelt PrimeTestLab.

Wij leveren geverifieerde, aangemelde testers op echte Android-apparaten. Ze houden je gesloten test gedurende de volledige vereiste actief, zodat één afhaker je reeks van 14 dagen niet breekt. Jij deelt de aanmeldingslink voor de gesloten test. Wij verzorgen uitnodigingen, controleren aanmeldingen, volgen dagelijks de activiteit en bewaken de retentie van 14 dagen. Meer dan 7.400 apps en een eerste-pogingsscore van 99,9%.

Huidige pakketten

Plus 5% servicekosten · gratis hertest of volledige terugbetaling

Veelgestelde vragen

Conclusie