Webapp vs native app vs PWA: hvad skal du vælge?

Webapp vs app er sjældent et enten-eller. De fleste nye forretningsløsninger bør starte som en webapp, få PWA-funktioner når brugerne kommer tilbage på telefonen, og først blive til en native app når der er en konkret grund. Den grund er typisk adgang til hardware som Bluetooth og GPS i baggrunden, et krav om at virke uden net i lang tid, eller at App Store og Google Play faktisk er der hvor dine kunder finder dig.

Jeg bygger selv webapps og backends, så læs med det forbehold. Jeg har forsøgt at være lige så konkret om de situationer hvor en native app er det rigtige valg.

Den korte version: webapp, PWA eller native app?

Min tommelfingerregel er enkel. Start som webapp. Tilføj PWA-funktioner når brugerne bruger løsningen på telefonen flere gange om ugen. Byg native når du kan pege på en bestemt funktion eller salgskanal som webben ikke kan levere. Valget hører til den tidlige afklaring i et projekt, så se også hvordan det passer ind i hele udviklingsprocessen fra idé til drift.

Hvad er forskellen på en webapp, en PWA og en native app?

Ordene bliver ofte brugt i flæng, så her er de definitioner jeg bruger i resten af indlægget.

Webapp

En webapp er et program der kører i browseren. Brugeren åbner et link, logger ind og udfører en opgave: booker en tid, godkender en faktura eller opdaterer en ordre. Kundeportaler, bookingsystemer, SaaS-produkter og interne værktøjer er typisk webapps. Forskellen til en almindelig hjemmeside er at brugeren arbejder med data i stedet for bare at læse.

PWA

En PWA (progressive web app) er en webapp med to tilføjelser: en manifestfil med navn og ikon, og en service worker, som er et lille script der kører i baggrunden i browseren. Tilsammen gør de det muligt at installere webappen på hjemmeskærmen, åbne den uden browserens adresselinje, gemme indhold til brug uden net og modtage push-beskeder. Det er stadig den samme kode og den samme adresse.

Native app

En native app er bygget specifikt til iPhone og Android, enten i Apples og Googles egne sprog (Swift og Kotlin) eller med et værktøj som React Native eller Flutter, der laver begge apps fra én kodebase. Den hentes i App Store eller Google Play, skal godkendes før hver udgivelse og har fuld adgang til telefonens funktioner.

Hvorfor jeg oftest anbefaler at starte som webapp

Første version handler om at lære hvad brugerne faktisk har brug for. Det lærer du hurtigst med én kodebase som du kan ændre samme dag. Finder du en fejl i en webapp, er rettelsen ude hos alle brugere få minutter efter. I en native app skal rettelsen først gennem Apples godkendelse, som ifølge Apple selv tager under et døgn for 90 % af indsendelserne, og derefter skal brugerne opdatere. Nogle gør det aldrig.

Der er også en praktisk grund. I B2B-løsninger sidder mange brugere ved en computer det meste af dagen. En native app alene udelukker dem, og de fleste ender alligevel med at bygge en webbaseret administration ved siden af. En webapp dækker computer, tablet og telefon fra første dag.

Du slipper desuden for en mellemmand. Ingen app-butik skal godkende dine ændringer, ingen kan afvise din næste udgivelse, og ingen tager en andel af det du sælger.

Endelig lukker du ikke døren for en native app. Bygger du webappen oven på et API, kan en senere app genbruge forretningslogik, data og login, så det kun er brugerfladen der skal laves igen. Er begrebet nyt for dig, har jeg forklaret hvad et API er, og hvorfor dit system har brug for et.

Hvilken teknologi webappen skal bygges i, er et separat valg. Jeg sammenligner to oplagte muligheder i Laravel vs Next.js og forklarer i et andet indlæg hvorfor Laravel er mit standardvalg til webapps.

Hvornår en PWA er det rigtige næste skridt

En PWA passer når brugerne begynder at bruge webappen på telefonen flere gange om ugen. Typiske eksempler er medarbejdere der tjekker vagtplaner, håndværkere der registrerer timer ude hos kunden, eller kunder der følger en ordre. Her gør et ikon på hjemmeskærmen og en påmindelse via push en reel forskel, og det kræver ikke en ny app.

Arbejdet er overskueligt sammenlignet med en native app: manifest og ikoner, en service worker der gemmer de vigtigste sider til brug uden net, og opsætning af push. Det tager længere tid hvis brugerne skal kunne oprette data uden net og synkronisere bagefter, for så skal løsningen kunne håndtere at to personer har ændret det samme.

Begrænsningerne ligger især på iPhone:

• Push-beskeder virker kun når webappen er installeret på hjemmeskærmen. Det har været muligt siden iOS 16.4.
• Der er ingen installationsknap som på Android. Brugeren skal selv åbne Del-menuen, typisk i Safari, og vælge "Føj til hjemmeskærm", og mange ved ikke at muligheden findes.
• Bluetooth, NFC og opgaver der kører i baggrunden, er stadig begrænsede eller mangler helt i Safari.

Der er også en platformsrisiko. I februar 2024 fjernede Apple hjemmeskærms-webapps for brugere i EU i en testversion af iOS 17.4 med henvisning til EU's forordning om digitale markeder (DMA), men trak beslutningen tilbage efter kritik fra både udviklere og EU-Kommissionen. De virker i dag, men episoden viser at PWA'er på iPhone afhænger af Apples velvilje.

Hvornår du faktisk har brug for en native app

Der er fire situationer hvor jeg selv ville anbefale en native app:

1. Appen skal bruge telefonens hardware i dybden: tale med Bluetooth-udstyr, læse NFC, følge positionen mens telefonen ligger i lommen eller hente sundhedsdata.
2. Brugerne skal arbejde uden net i lang tid. Teknikere i kældre, på skibe eller i landområder skal kunne arbejde en hel dag og synkronisere bagefter. En PWA kan klare noget af det, men en native app er mere forudsigelig.
3. App-butikkerne er din salgskanal. Henvender du dig til forbrugere der søger efter løsninger i App Store og Google Play, er appen en del af produktet.
4. Løsningen presser telefonens ydeevne, fx spil, AR eller tung billed- og videobehandling.

Regningen er tilsvarende større. To apps betyder i praksis to platforme der skal testes, to udgivelsesprocesser og en årlig runde opdateringer når Apple og Google udgiver nye versioner af styresystemerne. Dertil kommer backenden, som du skal bruge under alle omstændigheder. Sælger du digitale varer eller abonnementer i appen, tager butikkerne også en andel. Hos Apple i EU er det 26 %, eller 15 % for mindre udviklere, efter de vilkår der gælder fra 1. oktober 2026. Fysiske varer og ydelser der leveres uden for appen, er som regel ikke omfattet. Vil du se hvad det betyder i kroner, har jeg skrevet om hvad det koster at få udviklet en app.

Native apps er ikke mit speciale. Skal du have en, så find en udvikler med netop den erfaring. Backenden, API'et og administrationen bag appen kan sagtens bygges som en webapp, og den del kan jeg hjælpe med.

Hvornår hver løsning ikke passer

Webappen alene

• Når brugerne skal have besked med det samme på telefonen, fx om en ny opgave. Så har du brug for push og dermed mindst en PWA.
• Når løsningen skal virke uden net. En almindelig webapp holder op med at virke når forbindelsen forsvinder.

PWA

• Når de fleste brugere har iPhone, og hele løsningen står og falder med push. Installationstrinnet får nogle brugere til at falde fra.
• Når du har brug for Bluetooth, NFC eller GPS i baggrunden.
• Når kunderne skal kunne finde dig ved at søge i App Store.

Native app

• Når idéen ikke er afprøvet endnu. At bygge to apps for at finde ud af om nogen vil bruge dem, er den dyreste måde at lære det på.
• Når brugerne mest sidder ved en computer.
• Når budgettet kun rækker til at bygge appen og ikke til at vedligeholde den. En app der ikke bliver opdateret, begynder før eller siden at give problemer på nye versioner af iOS og Android.

Mellemvejene: cross-platform og webapp i en app-skal

Mellem en ren webapp og to native apps findes der to mellemveje.

Cross-platform-værktøjer som React Native og Flutter laver apps til både iPhone og Android fra én kodebase. Det sparer meget i forhold til to separate apps, og for de fleste forretningsløsninger er resultatet tæt på en native app. Men det er stadig en app: den skal i app-butikkerne, godkendes og vedligeholdes ved siden af din webapp.

Den anden vej er at pakke webappen ind i en tynd app-skal med et værktøj som Capacitor. Så kan den komme i app-butikkerne og få adgang til enkelte native funktioner, fx kamera og push, mens det meste af koden deles med webappen. Faldgruben er Apples godkendelse. Ifølge Apples retningslinjer for App Store skal en app være mere end en ompakket hjemmeside, så en ren indpakning uden ekstra app-funktioner risikerer at blive afvist. Google er mere lempelig, og på Android kan en PWA lægges i Google Play med relativt lidt ekstra arbejde.

Jeg ser app-skallen som et godt valg når webappen allerede fungerer godt på telefonen, og du har brug for at være i app-butikkerne plus et par native funktioner.

Næste skridt: sådan træffer du valget

1. Skriv ned hvem brugerne er, og hvor de bruger løsningen: ved skrivebordet, på farten eller ude hos kunder uden net.
2. Lav en liste over de funktioner der kræver telefonens hardware eller lang tid uden net. Er listen tom, er en webapp det rigtige udgangspunkt.
3. Afgør om app-butikkerne er en salgskanal for dig, eller bare et sted nogle kunder forventer at finde dig.
4. Byg første version som webapp oven på et API, og planlæg PWA-funktionerne fra start. Tag stilling til native når du har tal på hvordan løsningen bliver brugt.

Svarene hører hjemme i en kravspecifikation, så den udvikler du vælger, kan give et præcist tilbud. På siden om webapps og platforme kan du se hvordan jeg bygger den slags løsninger, fra første afklaring til drift.

Ofte stillede spørgsmål

Er en responsiv hjemmeside det samme som en webapp?+

Nej. Responsiv betyder at layoutet tilpasser sig skærmen, så siden er let at bruge på både computer og telefon. En webapp er et program hvor brugeren logger ind og arbejder med data, fx en kundeportal eller et bookingsystem. En webapp bør altid være responsiv, men en responsiv hjemmeside er ikke nødvendigvis en webapp.

Hvad koster det at gøre en webapp til en PWA?+

Det er typisk en mindre opgave end at bygge selve webappen. Manifest, ikoner og simpel brug uden net er hurtigt på plads i en velbygget webapp. Push-beskeder og især oprettelse af data uden net med synkronisering bagefter tager længere tid og kræver grundig test på både iPhone og Android. Bed om et estimat på hver del for sig, så du kan vælge til og fra.

Skal jeg vælge React Native eller Flutter?+

Begge kan bruges til de fleste forretningsapps, så valget afhænger mest af hvem der skal bygge og vedligeholde appen. React Native bruger JavaScript og React, som mange webudviklere kender, og kan dele noget logik med en React-webapp. Flutter bruger sproget Dart og har sit eget system til brugerflader. Vælg det din udvikler har solid erfaring med.

Kræver en native app mere vedligehold end en webapp?+

Ja, som regel. Apple og Google udgiver nye versioner af iOS og Android hvert år og stiller løbende krav til hvilke versioner apps skal bygges til. Derfor skal en native app opdateres og indsendes igen, også selvom du ikke selv har ændret noget. Med en webapp er det browserne der følger med, og du vedligeholder kun én kodebase.