Web app, native app, of allebei? Een eerlijke vergelijking.
"We willen een app." Dat is hoe het gesprek meestal begint. En dan volgt er een stilte, want "een app" kan van alles betekenen. Een iPhone-app in de App Store? Een Android-app in de Play Store? Iets dat je opent in je browser? Iets dat op je bureaublad staat?
De meeste KMO's die bij ons aankloppen bedoelen eigenlijk: "we willen iets dat beter werkt dan onze spreadsheet, en we willen het kunnen openen op onze telefoon." Dat is een volkomen logische wens. Maar de weg ernaartoe is niet altijd wat je denkt. En het verschil in kost tussen de verkeerde en de juiste keuze is groter dan je zou verwachten.
Laat me het uitleggen zonder jargon. Of toch zo min mogelijk.
Drie soorten "app"
Een web app is software die draait in je browser. Chrome, Safari, Firefox, maakt niet uit. Je tikt een adres in of klikt op een link, en je bent erin. Geen installatie, geen App Store, geen updates downloaden. Het werkt op je laptop, je tablet en je telefoon. Dezelfde app, overal.
Een native app is software die specifiek gebouwd is voor één platform. Een iOS-app voor iPhones en iPads. Een Android-app voor Samsung, Google Pixel, en de rest. Je downloadt ze uit de App Store of de Play Store, ze worden geïnstalleerd op je toestel, en ze hebben toegang tot de hardware van je telefoon: camera, GPS, pushmeldingen, offline opslag.
Een hybride app zit er tussenin. Het is in de kern een web app, maar verpakt als native app zodat hij in de App Store kan staan. Denk aan een webpagina die zich voordoet als een iPhone-app. Soms werkt dat prima. Soms voel je het verschil.
Waarom iedereen denkt dat ze een native app nodig hebben
Het is een reflexreactie. "App" roept het beeld op van een icoontje op je homescreen. Van iets dat je downloadt. Van iets dat voelt als Instagram of WhatsApp. Dat is logisch, want dat zijn de apps die je dagelijks gebruikt.
Maar Instagram heeft een team van honderden developers en een budget waar je KMO meerdere levens van zou kunnen draaien. De reden dat Instagram een native app is, heeft te maken met de miljoenen gebruikers die tegelijk foto's en video's laden, met de camera-integratie, met de complexe algoritmes die in realtime draaien op je toestel. Dat is een compleet ander verhaal dan een planning-app voor je team van twaalf man.
De vraag is niet "wil ik een native app?" De vraag is: "heb ik iets nodig dat alleen een native app kan?"
Wanneer een web app volstaat (en dat is bijna altijd)
Voor de overgrote meerderheid van KMO-processen is een web app de juiste keuze. En ik zeg dat niet omdat het makkelijker is voor mij om te bouwen. Ik zeg het omdat het voor jou goedkoper, sneller en praktischer is.
Een web app bouw je één keer. Niet één keer voor iPhone, één keer voor Android, en één keer voor desktop. Eén keer. Eén codebase. Die draait overal waar een browser draait. En laat me je een geheim verklappen: dat is op elk apparaat dat je bezit.
Updates zijn onmiddellijk. Als ik iets aanpas, ziet iedereen de nieuwe versie bij de volgende keer dat ze de app openen. Geen "er staat een update klaar in de App Store" en dan drie weken wachten tot iedereen geüpdatet heeft en ondertussen twee versies naast elkaar draaien.
Er is geen goedkeuringsproces. Apple keurt elke update van een native app handmatig goed. Dat duurt een tot drie dagen. Soms wijzen ze een update af om redenen die variëren van begrijpelijk tot kafkaësk. Bij een web app publiceer je wanneer je wilt.
En het belangrijkste: een web app is significant goedkoper. Niet tien procent goedkoper. Vaak de helft, of minder. Omdat je maar één versie bouwt in plaats van twee of drie.
Een planning-app voor je team? Web app. Een klantportaal? Web app. Een dashboard met je bedrijfscijfers? Web app. Een tool om offertes of werkbonnen te maken? Web app. Een intern systeem voor dossierbeheer? Web app.
Je kunt hem zelfs op je homescreen zetten. Een snelkoppeling aanmaken op je iPhone of Android, en hij staat daar als een icoontje naast je andere apps. Opent in volledig scherm. Ziet er precies hetzelfde uit.
Wanneer native wél zinvol is
Er zijn situaties waarin een native app de juiste keuze is. Ze zijn specifieker dan je denkt.
Je hebt de camera nodig op een manier die verder gaat dan gewoon een foto maken. Denk aan een app die barcodes of QR-codes scant in een magazijn. Of een app die documenten scant met OCR-herkenning. Of augmented reality toepassingen. De camera-integratie van een native app is dieper en betrouwbaarder dan wat een browser kan.
Je app moet offline werken in situaties zonder internet. Chauffeurs op de baan. Techniekers in kelders. Buitendienstmedewerkers op locaties zonder bereik. Als je app moet blijven functioneren zonder enige internetverbinding en data moet synchroniseren zodra er weer verbinding is, dan is native de betere keuze. Een web app kan beperkt offline werken, maar voor robuuste offline-functionaliteit met veel data is native sterker.
Pushmeldingen zijn bedrijfskritisch. Web apps kunnen tegenwoordig ook pushmeldingen sturen, maar de ondersteuning verschilt per platform en de betrouwbaarheid is niet altijd honderd procent. Als je app onmiddellijke, betrouwbare meldingen moet sturen die mensen niet mogen missen, dan is native betrouwbaarder.
Je app is bedoeld voor duizenden externe gebruikers. Als je een app bouwt die niet alleen je team maar ook je klanten of het grote publiek gaan gebruiken, en de verwachting is dat ze die downloaden uit de App Store, dan is native de logische keuze. Mensen vertrouwen de App Store. Het is een distributiekanaal. Voor een interne tool met twintig gebruikers is dat totaal niet nodig.
De kostenvraag die niemand hardop stelt
Laat me even eerlijk zijn over de cijfers.
Een web app bouwen voor een typisch KMO-proces kost, afhankelijk van de complexiteit, tussen de 5.000 en 30.000 euro. Eén app. Werkt overal.
Diezelfde app native bouwen voor iOS en Android kost je ruwweg het dubbele tot het drievoudige. Niet omdat native developers gulziger zijn, maar omdat je letterlijk twee aparte applicaties bouwt. Twee codebases. Twee sets met testen. Twee onderhoudscontracten. Twee keer updates uitrollen.
En dan komt de onderhoudskost. Apple brengt elk jaar een nieuwe versie van iOS uit. Google doet hetzelfde met Android. Bij elke grote update moet je controleren of je app nog werkt, en vaak aanpassingen doen. Dat is een lopende kost die je bij een web app niet hebt, of in veel mindere mate.
Voor de meeste KMO's is dat verschil in investering niet te verantwoorden. Niet omdat native slecht is, maar omdat je er simpelweg niet genoeg voor terugkrijgt om het verschil in prijs goed te maken.
De hybride verleiding
"Maar er bestaan toch tools die het allebei doen? Eén keer bouwen en dan zowel een web app als een native app hebben?"
Ja, die bestaan. React Native, Flutter, Ionic. Het zijn frameworks die je toelaten om één codebase te schrijven die op meerdere platformen draait. In theorie het beste van twee werelden.
In de praktijk is het een compromis. Je krijgt niet de volle kracht van native, en je krijgt niet de eenvoud van een pure web app. Je zit er tussenin. Voor sommige projecten is dat precies goed genoeg. Voor andere loop je tegen de grenzen aan zodra je iets wilt doen dat net buiten het standaardpad valt.
Mijn advies: begin met een web app. Als na zes maanden blijkt dat je echt iets nodig hebt dat alleen native kan, dan bouw je dat erbij. Niet andersom. De kennis die je opdoet met de web app maakt het native project achteraf beter en goedkoper.
Hoe het gesprek eigenlijk zou moeten gaan
Als iemand zegt "we willen een app", dan is mijn eerste vraag niet "voor welk platform?" Mijn eerste vraag is: "wie gaat het gebruiken, en wat moeten ze ermee kunnen?"
Als het antwoord is "ons team van vijftien mensen moet de planning kunnen inzien en aanpassen, ook op hun telefoon", dan is het antwoord een web app. Geen twijfel.
Als het antwoord is "onze chauffeurs moeten onderweg lading kunnen scannen, ook zonder internet, en de data moet automatisch synchroniseren als ze weer op de baan zijn", dan praten we over native. Dat is een reëel technisch argument.
Alles daartussenin is een gesprek waard. Maar in mijn ervaring landt tachtig procent van de KMO-projecten bij een web app. En de twintig procent die native nodig heeft, weet dat meestal al voordat ze bij mij aankloppen.
Samengevat
Bouw een web app tenzij je een concrete, technische reden hebt om native te gaan. Niet omdat web apps beter zijn, maar omdat ze voor jouw situatie waarschijnlijk de juiste balans zijn tussen kost, snelheid, en functionaliteit.
En als iemand je vertelt dat je absoluut een native app nodig hebt voor een intern planningssysteem met twaalf gebruikers, vraag dan even door naar het waarom. Het antwoord is vaak stiller dan je verwacht.
Benieuwd wat de juiste keuze is voor jouw situatie? Gebruik onze budgetconfigurator voor een snelle inschatting, of neem vrijblijvend contact op.