Mobiele app of PWA: de tabel die we met klanten gebruiken

Een founder schuift haar laptop over tafel. De deck telt vier maanden featurescope. Op de laatste slide staat iOS + Android, Q3. We stellen eerst één vraag voor we ook maar één slide lezen: wie heeft je verteld dat het een app moest worden?

Soms is het antwoord de board. Soms een concurrent die er net eentje heeft uitgebracht. Soms de founder zelf, halverwege een pricingpagina waar elke knop "Download" zegt. Bijna nooit is het de gebruiker.

Dit is de tabel die we in dat gesprek gebruiken. Niet de enige tabel. Wel degene die de meeste discussies overleeft.

De twee vragen die de meeste cases beslissen

Voor de tabel, eerst het filter. Twee vragen, allebei binair.

1. Heeft het product hardware nodig die de browser niet kan bereiken? Bluetooth Classic, NFC-betalingen, HealthKit, ARKit, low-level camerabesturing, Apple Watch.
2. Opent de gebruiker dit meer dan één keer per week op zijn telefoon, elke week, minstens zes maanden lang?

Is het antwoord op vraag één ja, dan bouw je native. De browser heeft de kloof verkleind. Niet gedicht. PWA-installability wordt met elke Safari-release beter, maar Bluetooth Low Energy op iOS Safari is nog steeds een muur.

Is vraag één nee en vraag twee ook nee, dan bouw je een PWA. De gebruiker zet jouw icoon niet op zijn beginscherm. Hij vindt je via een zoekresultaat of een link, doet wat hij komt doen en sluit het tabblad. App-storeaanwezigheid voor een tool die je één keer per kwartaal opent is plankvulling met een downloadbadge.

De interessante beslissingen zitten tussen deze twee antwoorden in. Daarvoor is de tabel.

De keuzetabel

Lees van boven naar beneden door de linkerkolom. Geef per rij één punt aan de kant die jouw werkelijkheid raakt. Tel de punten op. Wint één kant met drie of meer punten verschil, bouw die.

Signaal	PWA wint	Native wint
Openingsfrequentie	Maandelijks of minder vaak	Dagelijks of wekelijks
Sessieduur	Korter dan twee minuten	Langer dan vijf minuten
Hardware-bereik	Camera, geolocatie, accelerometer	BLE, NFC, HealthKit, secure enclave, achtergrond-audio
Push notifications	Leuk meegenomen	Kern van de retentielus
Offline-betrouwbaarheid	Alleen lezen, of zelden	Writes moeten een tunnel overleven
Distributiekanaal	SEO, e-mail, paid social	App-storezoekopdrachten, ASO, partner-installs
Updatecadans	Meerdere keren per week	Eens per twee tot vier weken is prima
Teamvorm	Eén webteam	Bestaande iOS- of Android-capaciteit
Tijd tot de eerste gebruiker	Dagen	Weken aan reviewpijplijnen
Houding van het publiek	Desktop-zwaar of gemengd	Phone-first, vaak onderweg

Tien rijen. De rekensom is met opzet bot. Founders ruziën minder met een getal dan met een gevoel. Kun je niet uitleggen waarom een rij naar één kant valt, dan is die rij geen echte requirement. Streep 'm door voordat je 'm scoort.

De kleine lettertjes rond iOS push notifications

Push is waar de meeste van deze gesprekken sneuvelen. Sinds iOS 16.4 ondersteunt Safari de Web Push API op de iPhone. Mensen lezen de kop en gaan ervan uit dat het gat dicht is.

Lees de aankondiging van WebKit zelf en de voorwaarde staat al in de tweede zin: web push werkt alleen voor sites die de gebruiker zelf aan het beginscherm heeft toegevoegd. Niet via een bookmark. Niet door vaak te bezoeken. Bewust toegevoegd, met de share sheet en daarna "Zet op beginscherm".

We hebben dit gemeten op drie productie-B2C-deployments. De home-screen install rate vanuit een eerste bezoek lag tussen 0,3% en 2,1%, zelfs met een in-page prompt en een schermopname van hoe je het doet. Native installratio's via de App Store lagen voor dezelfde doelgroepen tussen 8% en 22%.

Draait de retentielus op push, dan scoort de rij hierboven geen punt voor native. Hij scoort er drie.

Distributierekenen dat niemand op de slide zet

Het getal dat in de meeting voor PWA pleit is "geen app-storefees". Het getal dat alsnog native laat verschijnen is "waar de gebruikers kijken".

Aanwezigheid in de App Store is betaalde aandacht. Apple rekent 99 dollar per jaar plus 15% of 30% van in-app-aankopen, afhankelijk van het Small Business Program. Google vraagt eenmalig 25 dollar om te publiceren en dezelfde revenue split. Voor een B2B-tool met een seat van 200 euro per maand die je via een gesprek verkoopt, doet dat niets. Voor een consumer-abonnement van 4 euro met App Store organic als hoofdkanaal vreten beide getallen je marge op.

De PWA-route ruilt store-fees in voor SEO-investering, partner-integraties en het zwaardere werk om een gebruiker je site op zijn beginscherm te laten zetten zonder downloadknop als ankerpunt. Dat werk is niet gratis. Het wordt alleen in een andere munt betaald, en de factuur komt later binnen.

De tabel overrulen

De tabel is een startpunt, geen vonnis. Drie overrules die we vaker dan eens hebben gebruikt.

Investor-optiek. Een Series A-founder heeft om dezelfde reden een native app nodig als een restaurant een gedrukt menu. Bij een edtech-klant zei de tabel vorig jaar PWA. We hebben een dunne React Native-wrapper rond de webbuild gebouwd voor de App Store-aanwezigheid en de PWA als het echte product gehouden. Drie weken werk, geen drie maanden. Eerlijk als je gebruikers vertelt wat ze krijgen, oneerlijk als je voor een webview native-prijzen rekent.

Interne tools. Zijn de gebruikers werknemers en het apparaat een managed laptop of een kiosk-tablet, dan wijst de tabel bijna altijd naar PWA, ook als push en offline meetellen. Via MDM uitgerolde web-shortcuts geven je het meeste native-installgedrag zonder de reviewpijplijn.

Snelheid van validatie. De tabel zegt native omdat het product op dagelijks push leunt. De founder heeft zes maanden runway. Lever de PWA op, leer of de loop überhaupt werkt en bouw daarna native met wat je echt geleerd hebt. We hebben die keuze twee keer gemaakt en nul keer betreurd.

De audit van vijf minuten

Open je roadmap. Print de tabel. Score 'm eerlijk met de productmanager en één engineer in de kamer, niet alleen. Verrast de uitkomst je, dan zit daar de waarde. Bevestigt de uitkomst wat je al dacht, dan heb je een verdedigbaar antwoord voor de volgende keer dat de board vraagt waarom.

Toen we vorig jaar de courier-tracking PWA bouwden voor een Nederlandse logistieke broker, zei de tabel web en bouwden we web. Zes weken later klaagden de chauffeurs over de wrijving rond installeren op het beginscherm en promoveerden we hem tot een dunne native shell over dezelfde codebase. Het meeste van ons werk rond mobiele apps doen we tegenwoordig in die volgorde: valideren op het web, doorgroeien naar native als de gebruikers erom vragen, niet als de deck erom vraagt.