Mobile apps
Mobiele apps voor B2B: waarom we vaak een PWA kiezen
Een bouwleverancier vroeg ons om native iOS en Android. We praatten ze een PWA aan. Drie B2B-projecten leerden ons waar native nog z'n geld waard is en waar niet.

Een bouwleverancier uit Eindhoven zat in februari tegenover ons met een geprinte briefing: iOS en Android, native, app voor het buitenwerk, 120 gebruikers. Het eerste uur hebben we ze ervan afgepraat. Aan het einde van het gesprek lag er een Progressive Web App met push notificaties op tafel. Ze gingen vijf weken later live, betaalden ongeveer een derde van de native offerte, en de besparing dekt twee jaar operationele support.
Dat gesprek is inmiddels onze standaard. Voor de meeste B2B-klanten onder €2M sturen we eerst richting een PWA met push voordat we überhaupt een native traject offreren. Dat beleid is niet uit de lucht komen vallen. Drie projecten leerden ons dat, waarvan eentje die we hebben verloren.
De cijfers die zelden in de pitch belanden
Een fatsoenlijke native B2B-app kost €40-80k voor de eerste versie. Dat zijn twee codebases (of één React Native-codebase met platform-specifieke patches die op slechte dagen aanvoelt als twee codebases), accounts bij Apple Developer en Google Play, signing-infrastructuur, een release pipeline en een review-cyclus die in dagen wordt gemeten. Elke grote iOS-versie betekent een sprint regressiewerk. Elke aanpassing in een huisstijlkleur betekent een nieuwe binary uploaden.
Voor een B2B-portaal waar de gebruikerslijst bekend is (medewerkers, dealers, klanten met een contract) is de echte killer niet de prijs. Het is install friction. Je operations lead mailt een link naar een nieuwe functie. De gebruiker tikt erop. Er gebeurt niets, want de app wil eerst updaten. Hij tikt op de App Store. Hij weet z'n Apple ID niet meer. Hij geeft het op. Keer dat met 400 dealers.
Afwijzing één: de buitendienst die geen app nodig had
Een facilitair bedrijf vroeg om een native Android-tool voor ongeveer 120 monteurs. Werkbonnen, foto's uploaden, ticketstatus, push als er een nieuw ticket binnenkomt. We offreerden allebei de opties. De PWA-offerte was 28% van de native offerte, de looptijd 5 weken in plaats van 14, en de monteurs hadden Chrome al staan omdat ze die gebruikten voor routenavigatie.
We hebben hem tijdens de kickoff samen op het startscherm gezet. Dertig seconden per monteur, in één ochtend afgerond. Service-worker cache voor de werkbon zodat hij blijft werken in een dood plekje op een dak. Push voor nieuwe tickets. Achttien maanden later heeft nog niemand gevraagd wanneer de echte app komt.
Afwijzing twee: het dealerportaal dat bewees dat push het product is
Een Nederlandse bouwmaterialengroothandel wilde een bestel-app voor ongeveer 400 kleine bouwbedrijven. We zagen de native route twee kanten op gaan. Enterprise-distributie via MDM, wat 400 dealers met één laptop niet gaan accepteren. Of de openbare App Store met een loginmuur, wat in B2B installatiecijfers in de enkele cijfers oplevert omdat niemand de app van z'n leverancier downloadt.
We hebben een PWA gebouwd: catalogus, prijs per dealercode, herbestellen met één tik, push notificaties voor orderstatus en voorraadmeldingen. De installaties stonden binnen twee maanden op 73%, omdat de groothandel de aandacht van de dealers al had via facturen en een accountmanager. Het push-kanaal bleek het eigenlijke product. Het herbestelvolume op push-getriggerde voorraadmeldingen lag vier tot vijf keer hoger dan op de oude SMS-flow.
Afwijzing drie: degene die we verloren
Een B2B-dienstverlener wilde een premium aanvoelende klant-app voor ongeveer 3.000 klanten. We hebben ertegen gepleit. Het gedrag bestond niet: niemand opent een app voor het bedrijf dat z'n kopieerapparaten onderhoudt. We schetsten een PWA met maandelijkse overzichten, het aanmaken van tickets en push bij oplossing van een melding. Ze gingen met een concurrent in zee die wel de native iOS- en Android-apps bouwde.
Veertien maanden later hoorden we via een gezamenlijk contact daar dat de installaties in de enkele cijfers bleven hangen. De concurrent stuurt ze nu opnieuw een rekening om de vindbaarheid te verbeteren. Dat is de afwijzing die we andere klanten blijven vertellen, want niemand gelooft het open-rate-probleem totdat het geld al is uitgegeven.
Waar native het geld nog steeds waard is
Het beleid is PWA als standaard, niet PWA altijd. Een native build verdient zichzelf wel terug als:
- je continue Bluetooth, locatie op de achtergrond, NFC writing of ARKit/ARCore nodig hebt. Het web kan dat niet betrouwbaar en Apple heeft geen haast om het toe te staan.
- het product consumentgericht is, dagelijks gebruikt en betaald wordt. Ons werk aan consumer health apps is native, omdat die 's ochtends voor het ontbijt opengaat en concurreert om dezelfde aandacht als Instagram.
- de App Store zelf je distributiekanaal is. Voor de meeste B2B-portalen is dat niet zo. Voor een betaalde consumenten-tool kan het wel zo zijn.
- je voorgrond-media nodig hebt (zware AR via camera, videogesprekken met eigen beeldverwerking) die het web nog steeds slecht benadert.
Als je briefing login + dashboard + push is, dan kan het web dat nu. De ommekeer was iOS 16.4 in maart 2023, toen Safari Web Push voor geïnstalleerde startscherm-PWA's uitrolde. Daarvoor was PWA op iOS een beleefde fictie.
De stack die we daadwerkelijk uitrollen
Standaard build: Next.js of Vite + React aan de voorkant, een door Workbox gegenereerde service worker voor caching en push, en de Web Push API met VAPID-keys aan de serverkant. Notificaties lopen voor iOS-gebruikers via Apple's APNs en voor Android en desktop via FCM of autopush, transparant, want dat is waar Web Push onder de motorkap naartoe routet.
De push-handler in de service worker is veertig regels en is het enige stuk dat native aanvoelt:
// public/sw.js
self.addEventListener('push', (event) => {
const data = event.data?.json() ?? {}
event.waitUntil(
self.registration.showNotification(data.title || 'Update', {
body: data.body,
icon: '/icons/icon-192.png',
badge: '/icons/badge.png',
tag: data.tag,
data: { url: data.url || '/' },
})
)
})
self.addEventListener('notificationclick', (event) => {
event.notification.close()
event.waitUntil(
self.clients.matchAll({ type: 'window' }).then((clients) => {
const target = event.notification.data.url
const open = clients.find((c) => c.url.includes(target))
if (open) return open.focus()
return self.clients.openWindow(target)
})
)
})
Op iOS werkt Web Push pas nadat de gebruiker de PWA op het startscherm heeft gezet. Roep je Notification.requestPermission() aan vanuit een Safari-tab, dan verschijnt de prompt niet. Plaats het verzoek achter een moment in de app (eerste bestelling bevestigd, eerste ticket aangemaakt) dat na installatie komt.
Waar het stukloopt, eerlijk gezegd
We verkopen geen gratis ritje. Waar PWA's nog steken laten vallen:
- iOS install friction. Toevoegen aan startscherm is een dansje van drie tikken dat geen marketingpagina gaat oplossen. Plan een onboarding-moment waarin je de gebruiker erdoorheen loodst, het liefst in persoon bij waardevolle B2B-portalen.
- Background sync is dunner dan op native. Uploads die lang duren werken beter met een 'laat deze tab open' patroon dan met fire-and-forget.
- Enterprise MDM-profielen blokkeren soms de installatie van een PWA of strippen de service worker. Test op de daadwerkelijke devices voordat je je vastlegt.
- Heb je echt NFC writing of continue BLE nodig, dan is het web er nog niet. Stop met lezen en offreer native.
Een audit van vijf minuten voordat je native gaat scopen
Loop drie vragen door met de klant erbij:
- Opent de gebruiker dit dagelijks omdat hij dat wil, of alleen als een taak hem dwingt?
- Heb je echt een van deze nodig: continue Bluetooth, locatie op de achtergrond, ARKit, NFC writing, eigen camera-verwerking?
- Is de App Store je distributiekanaal, of stuur je gebruikers zelf een link?
Als vraag twee 'nee' is en vraag drie we sturen ze zelf de link, dan heb je geen native app nodig. Je hebt een snelle site nodig, een service worker, een push-keypair en een installatiemoment.
Toen we het dealerportaal bouwden voor de groothandel uit afwijzing twee was de iOS-permissieflow het stuk dat we steeds verkeerd hadden: uiteindelijk hebben we de push-prompt achter de eerste succesvolle herbestelling gezet, waarmee opt-in steeg van 19% naar 64% onder de actieve dealers. Datzelfde scoping-gesprek vormt het grootste deel van wat ons website- en SaaS-werk de eerste maand bij een nieuwe B2B-klant inhoudt.
De kleinste actie voor vandaag: open je laatste mobiele-app-briefing, zoek de feature lijst en omcirkel alles wat continue Bluetooth, locatie op de achtergrond of NFC writing nodig heeft. Staat er niets omcirkeld, dan heb je je antwoord.
Kern
Als je B2B-briefing login plus dashboard plus push is, kan het web dat nu. Hou native voor consumer apps die je dagelijks gebruikt en voor echte hardware-eisen.
FAQ
Wanneer heeft een B2B-klant nog wel een native app nodig?
Wanneer je continue Bluetooth, locatie op de achtergrond, NFC writing of ARKit/ARCore nodig hebt, of wanneer de App Store zelf je distributiekanaal is. De meeste B2B-portalen onder €2M hebben niets daarvan nodig.
Werkt Web Push nu echt op de iPhone?
Ja, sinds iOS 16.4 in maart 2023, maar alleen nadat de gebruiker de PWA op het startscherm heeft gezet. Toestemming voor push kan niet worden gevraagd vanuit een gewone Safari-tab.
Hoe lang duurt een PWA-build vergeleken met native?
Ons dealerportaal stond na vijf weken live tegenover een native offerte van 14 weken, voor ongeveer een derde van de kosten. Die verhouding zien we terug in de meeste B2B-portaalprojecten die we hebben gescoped.
En React Native of Flutter als middenweg?
Die leveren nog steeds native binaries op met App Store review, signing en update friction. De besparing zit in de bouw, niet in de distributie. Voor B2B-portalen is distributie nou juist het echte probleem.