Native apps vs PWA: Hvad skal du vælge, og hvad betyder det teknisk?

Kort svar: hvornår giver native apps eller PWA mest mening?

Hvis du står og skal vælge teknologi til en ny app, er den praktiske forskel typisk:

• Vælg native app, hvis du har brug for maksimal performance, dyb adgang til hardware (kamera, sensorer, biometrisk login, Apple Pay, AR osv.) og bevidst tilstedeværelse i App Store/Google Play.
• Vælg PWA (Progressive Web App), hvis du vil ramme både mobil og desktop hurtigt, har begrænset budget, ikke er afhængig af helt specifikke device-funktioner og vil kunne opdatere uden om app stores.

Resten af artiklen går i dybden med, hvad forskellen faktisk er teknisk, hvad det betyder for pris, vedligeholdelse og brugeroplevelse, og hvordan du konkret kan beslutte dig.

Hvad er en native app, og hvad er en PWA?

En native app er en app, der er bygget specifikt til et bestemt styresystem:

• iOS (iPhone/iPad) med f.eks. Swift/SwiftUI i Xcode
• Android med f.eks. Kotlin/Jetpack Compose i Android Studio

Den bliver installeret fra App Store eller Google Play, kører direkte på enheden og har tæt adgang til systemets funktioner.

En PWA (Progressive Web App) er i bund og grund en webapp (bygget med HTML, CSS og JavaScript), som bruger nogle ekstra webstandarder til at opføre sig mere som en app:

• Den kan tilføjes til startskærmen og åbnes i et separat vindue uden browser-krom.
• Den kan i et vist omfang fungere offline via caching.
• Den tilgås stadig via en URL og hostes på en webserver, ligesom et website.

En vigtig forskel: hvor en native app er bundet til én platform ad gangen, kan en PWA i udgangspunktet køre på tværs af platforme og enhedstyper med én kodebase.

Hvad betyder forskellen teknisk?

Lad os kigge på, hvad der kører hvor, og hvilke byggesten du typisk arbejder med.

Native apps: tæt på operativsystemet

En klassisk native stack ser typisk sådan her ud:

• iOS: Swift eller Objective-C, ofte med SwiftUI eller UIKit, udviklet i Xcode.
• Android: Kotlin eller Java, ofte med Jetpack Compose eller klassiske Views, udviklet i Android Studio.

Koden bliver kompileret ned til noget, som kører direkte på enhedens operativsystem. Det giver:

• Hurtig og forudsigelig adgang til hardware (kamera, sensorer, Bluetooth, NFC osv.).
• Bedre kontrol over performance og ressourceforbrug.
• Tæt integration med systemfunktioner som notifikationer, widgets, systemindstillinger m.m.

Distribuering sker gennem App Store og/eller Google Play. Det betyder typisk:

• Build, signering og upload via udviklerkonti.
• Review-proces og regler (f.eks. Apple Guidelines).
• Versionering og udrulning via app stores.

PWA: en webapp med ekstra superkræfter

En PWA er teknisk set “bare” en webapplikation, men med nogle ekstra standarder ovenpå:

• HTML, CSS, JavaScript som grundlag.
• Service worker – et lille JavaScript, der kører i baggrunden og kan:
• interceptere netværkskald
• cache filer og API-svar
• muliggøre offline- eller dårlig-netværks-oplevelser
• Web App Manifest – en JSON-fil, der beskriver appen:
• navn, ikoner, start-URL, farver osv.
• fortæller browseren, hvordan appen skal “installeres”.
• HTTPS er påkrævet for service workers (sikkerhed).

Arkitekturen er typisk:

• Frontend: et SPA-framework (f.eks. React, Vue, Svelte eller et bundlerværktøj som Vite) eller ren vanilla JS.
• Backend: API’er (REST/GraphQL), ofte hostet separat – f.eks. en Express- eller anden HTTP-server.

Der er ingen app store som mellemled. Du deployer til en almindelig webhost eller platform (Vercel, Netlify, traditionel server osv.), og brugeren går ind via en URL og kan derefter vælge at “installere” appen fra browseren.

Hvor kører koden egentlig?

• Native: kører tæt på operativsystemet, med direkte adgang til system-API’er.
• PWA: kører inde i browserens JavaScript-motor og sandbox. Alt går gennem browserens lag og dens begrænsninger/muligheder.

Det er derfor, native apps generelt kan gå dybere ned i hardware, mens PWA’er typisk vinder på fleksibilitet og reach.

Hvad kan native apps, som PWA’er typisk har sværere ved?

PWA’er bliver hele tiden bedre, men der er stadig områder, hvor native apps er klart stærkest.

1. Dyb hardwareadgang og systemintegration

Native apps har generelt lettere og mere stabil adgang til:

• Kamera og sensorer (gyroskop, accelerometer, proximity, kompas osv.) på et avanceret niveau.
• Biometrisk login som Face ID og Touch ID via systemets auth-API’er.
• Betalingsløsninger som Apple Pay og Google Pay i fuldt integreret form.
• AR og 3D via frameworks som ARKit (iOS) og ARCore (Android).
• Bluetooth, NFC, baggrundsprocesser og andre lavniveau-funktioner.

Webplatformen har fået API’er som f.eks. Geolocation, WebRTC og visse sensor-API’er, men understøttelsen er ujævn på tværs af browsere, og adgangsniveauet er ofte mere begrænset end native.

2. Performance til tunge applikationer

Til apps, hvor du presser enheden hårdt (f.eks. 3D-spil, avanceret video- eller billedredigering, tung AR/VR), er native næsten altid det tryggeste valg.

Årsager:

• Mindre overhead mellem din kode og hardwaren.
• Mere forudsigelig hukommelsesstyring og tråd-håndtering.
• Bedre adgang til GPU og specialiserede biblioteker.

WebAssembly og moderne JS-motorer kan komme imponerende langt, men hvis performance er helt afgørende, vælger mange stadig native.

3. Systemoplevelse og ecosystem-fordele

Native apps kan:

• bruge platformsspecifik UX (gesture navigation, native kontroller, haptics osv.).
• få widgets på hjemskærmen, dybe integrationer med notifikationscenter m.m.
• drage fordel af App Store/Play Store-synlighed som en marketingkanal.

Hvis hele din strategi afhænger af, at brugerne “finder dig” i app stores, er det svært at komme uden om native (eller i hvert fald noget, der kan pakke din webapp ind til app stores, hvilket er et særskilt emne).

Hvad kan en PWA, og hvor er dens styrker?

Selv om PWA’er typisk ikke går lige så dybt ned i hardwaren, har de nogle ret stærke kort på hånden – både teknisk og forretningsmæssigt.

1. Én kodebase på tværs af platforme

En PWA er i udgangspunktet en enkelt webkodebase:

• Samme frontend rammer Android, iOS, desktop og alt med en moderne browser.
• Du vedligeholder og deployer ét codebase, ikke to (eller flere) apps.

Det påvirker både udviklingshastighed og vedligeholdelsesomkostninger ret markant.

2. Nem distribution og opdatering

• Brugere går ind på en URL – ingen App Store-søgning, ingen godkendelsesflow.
• Du kan rulle en opdatering ud ved at deploye ny kode til din webhost.
• Ingen ventetid på app store review, ingen versioneringskaos hos brugerne.

Det er især stærkt for produkter, der har hyppige releases, A/B-tests eller løbende tilpasning.

3. Offline-funktion og caching

Med en service worker kan du:

• cache HTML, CSS, JS, billeder og API-svar.
• servere cached indhold, når brugeren er offline eller har dårlig forbindelse.
• skabe en oplevelse, hvor appen “føles installeret” og mere robust.

Det kræver dog omtanke; caching er et helt kapitel for sig (jeg har skrevet mere om typiske faldgruber i denne artikel om cache).

4. Mindre pladsforbrug og lavere friktion

• En PWA fylder typisk mindre på enheden end en fuld native installation.
• Installationsflowet er lettere: brugeren får et “Tilføj til startskærm”-prompt direkte i browseren.

Det sænker barrieren for at prøve din løsning, især hvis målgruppen ikke aktivt søger efter din app i en app store.

5. Lavere indgangsomkostninger

Fordi du både bruger webteknologier og én kodebase, er PWA’er ofte:

• hurtigere og billigere at komme i luften med.
• nemmere at iterere på, mens du stadig validerer idé og produkt-marked fit.

Det gør PWA’er oplagte til alt fra content-drevne produkter til første version (MVP) af mere ambitiøse apps.

Begrænsninger og faldgruber – især for PWA’er

Nuancerne er vigtige her, for billedet ændrer sig løbende, og kilderne er ikke altid helt enige. Men der er nogle gennemgående punkter.

Begrænset hardware- og systemadgang

Selv om webplatformen får flere API’er, har PWA’er generelt:

• mere begrænset adgang til biometri, dyb Bluetooth/NFC, baggrundsopgaver osv.
• mindre kontrol over resource management (f.eks. når systemet slår ting ihjel i baggrunden).

Til simple brug af kamera, lokation, mikrofon osv. er web-API’er ofte fine, men ved avancerede scenarier eller krav om fuldt stabil offline-synkronisering i baggrunden er native typisk tryggere.

iOS og PWA: særligt følsomt område

Understøttelsen af PWA-funktioner på iOS udvikler sig løbende. Nogle ting fungerer, andre er mere begrænsede eller ændrer sig mellem versioner.

Især når vi taler om:

• Push-notifikationer – på nogle iOS-versioner er det delvist eller begrænset understøttet for PWA’er.
• Baggrundsopgaver og offline-sync – generelt mere restriktivt end på Android/web generelt.

Det er derfor en god idé at teste konkret på de iOS-versioner og enheder, du sigter efter, i stedet for at stole på én generel påstand i en blogpost (inklusive denne).

App store-fravær som både fordel og ulempe

At PWA’er ikke ligger i en app store betyder:

• Fordel: Du slipper for review-processer, gebyrer og visse platformskrav.
• Ulempe: Du mister den søgbarhed og “social proof”, som en listning i App Store/Google Play kan give.

Nogle organisationer ser fraværet af app stores som en kæmpe frihed. Andre oplever det som et markedsføringsproblem.

Hvad koster det typisk – og hvordan ser vedligeholdelsen ud?

Priser varierer voldsomt efter scope, kvalitet, team og marked. De tal, der dukker op i researchen, er typisk internationale estimater, ikke faste danske listepriser.

Udviklingsomkostninger (internationale estimater)

En kilde (AB Digital, 2024) nævner følgende intervaller:

• PWA: ca. 15.000 – 150.000 USD
• Native app: ca. 50.000 – 250.000+ USD

Det er brede intervaller, men pointen er klar: native ligger typisk markant højere, bl.a. fordi du ofte skal bygge både iOS og Android separat.

Hvis du overfører logikken til en dansk kontekst uden at opfinde tal:

• En PWA med én webkodebase vil som regel kræve færre udviklingstimer end to fulde native-forløb.
• Specialiserede native-features (AR, avanceret offline, tung grafik) koster ekstra, uanset land.

Vedligeholdelse og løbende drift

Samme kilde estimerer årlig vedligeholdelse til cirka:

• PWA: 5 – 10 % af den oprindelige udviklingspris pr. år
• Native: 15 – 20 % pr. år

Igen: det er grove intervaltal, men de afspejler nogle praktiske forskelle:

• Native: Du har mindst to kodebaser (iOS/Android), som skal opdateres, når:
• nye OS-versioner kommer
• app store-krav ændres
• biblioteker skal opdateres af sikkerhedsgrunde
• PWA: Du opdaterer én webkodebase og skal primært forholde dig til browserkompatibilitet og din hosting/platform.

Platform- og distributionsomkostninger

Når du er i app store-land, dukker der ekstra poster op:

• Apple Developer Account: ca. 99 USD/år.
• Google Play Developer: engangsbetaling på ca. 25 USD.
• Commission i visse cases (f.eks. 15 – 30 % på in-app purchases, afhængigt af ordninger og omsætning).

De tal er ikke katastrofale i sig selv, men de er relevante, hvis din forretningsmodel bygger på in-app salg eller abonnementer via app stores.

Hvornår giver det mest mening at vælge native – og hvornår PWA?

Her er en mere konkret beslutningsguide, du kan holde dit projekt op imod.

Vælg native app, hvis…

• Du har brug for avanceret hardwareadgang:
• tung brug af kamera, sensorer, Bluetooth, NFC
• biometrisk login (Face ID/Touch ID) som bærende login-flow
• AR/VR-funktioner, f.eks. ARKit/ARCore
• Du bygger performance-kritiske apps:
• mobilspil med 3D/grafikintensiv rendering
• video- eller billedredigeringsværktøjer
• Tilstedeværelse i App Store/Google Play er strategisk vigtig:
• brugerne forventer at finde dig dér
• du har brug for ratings, anmeldelser, kategori-lister osv.
• Du har budget og tid til at vedligeholde to platforme.

Vælg PWA, hvis…

• Du vil ramme både mobil og desktop med én løsning.
• Du har begrænset budget eller vil hurtigt til markedet.
• Din app er primært content- eller formular-drevet:
• portaler, dashboards, bookingsystemer, e-handel, intranet osv.
• Du har brug for offline light (læse tidligere hentet indhold, simple handlinger, der syncer senere) og ikke super-avanceret baggrundssync.
• Du gerne vil slippe for app store-krav og kunne rulle ændringer ud løbende.

Praktisk tommelfingerregel

En fornuftig måde at tænke på valget er:

• Start med at antage, at en PWA er nok.
• Lav en liste over krav til hardware, performance og app store-strategi.
• Hvis mere end et par krav kræver dyb systemintegration eller tung performance, så bevæger du dig mod native.

Det er ofte billigere at starte web-first og så opgradere til native senere, end at bygge to native apps fra dag ét, hvis du stadig er ved at validere produktet.

Hvordan ser en god beslutningsproces ud i praksis?

I stedet for at starte med teknologivalget, er det mere robust at starte med problemet og kravene.

1. Afklar mål og brugerrejse

• Hvad er det vigtigste, brugeren skal kunne med appen?
• Hvor ofte forventer du, at brugeren vender tilbage?
• Er det et arbejdsredskab, en service eller mere et indholdsprodukt?

2. Kortlæg tekniske krav

• Hvilke hardwarefunktioner er absolut nødvendige?
• Hvilke offline-scenarier skal understøttes (læs, skrive, synkronisere)?
• Hvilke performance-krav har du (tunge beregninger, grafik, real-time osv.)?

Her kan det være nyttigt at skrive konkrete use cases ned i stedet for generelle ønsker.

3. Vurder compliance, sikkerhed og platformskrav

• Har du særlige GDPR-, sikkerheds- eller branjespecifikke krav?
• Skal du følge bestemte enterprise-policies, der favoriserer eller begrænser web/native?
• Har du forretningskrav om App Store/Play Store-tilstedeværelse?

Til websikkerhed kan du bl.a. kigge på ting som Content Security Policy og korrekt håndtering af API-nøgler. Jeg har skrevet om det i f.eks. CSP og sikker opbevaring af API-nøgler.

4. Budget, tidshorisont og team

• Hvor mange timer og hvor stort budget har du realistisk?
• Har du allerede webkompetencer i huset, eller også native-udviklere?
• Hvornår skal første version være i hænderne på rigtige brugere?

5. Vælg teknologi og lav en prototype

Når du har et billede af krav og rammer, kan du:

• vælge PWA (klassisk webstack) eller native (Swift/Kotlin osv.) som primær retning
• bygge en klikbar prototype eller simpel proof-of-concept
• teste den på de enheder og netværksscenarier, der er relevante

Når det gælder PWA-arkitektur og routing, er erfaringer fra SPA vs klassisk serverrouting også ret relevante. Jeg har skrevet mere om det i artiklerne om SPA vs MPA og SPA-routing på Netlify/Vercel.

6. Planlæg drift og videreudvikling

• Hvor ofte forventer du releases?
• Hvem har ansvaret for opdatering af afhængigheder, sikkerhed og OS/browserkompatibilitet?
• Hvordan håndterer du monitorering og fejl (logs, analytics, brugerfeedback)?

Her spiller valget mellem webhosting og app stores også ind. Jeg har en separat guide til valg af hosting, som du kan bruge til PWA/backends: vælg den rigtige hosting-løsning.

Spørgsmål du bør stille, før du beslutter dig

Hvis du vil have en kort tjekliste, kan du bruge disse spørgsmål som filter:

• Skal brugerne kunne bruge appen uden stabil internetforbindelse? I hvor høj grad?
• Har jeg kritiske krav til hardware, der i dag kun (eller bedst) løses med native API’er?
• Er høj, stabil performance (spil, tung grafik, real-time) et krav eller et plus?
• Er det forretningskritisk at være synlig i App Store/Google Play?
• Skal løsningen fungere lige godt på desktop og mobil?
• Hvor hurtigt skal første version ud, og hvor meget kan vi investere nu vs senere iterations?
• Har vi primært webudviklere til rådighed, eller også erfarne native-folk?

Jo flere “ja”-svar du giver til hardware-/performance-/app store-spørgsmålene, desto mere peger det mod native. Jo flere “ja”-svar du giver til budget-/reach-/webteam-spørgsmålene, desto mere peger det mod PWA.

Typiske misforståelser om native apps og PWA’er

Afslutningsvis er her nogle klassiske misforståelser, det er værd at få ryddet op i.

“En PWA er bare en almindelig hjemmeside”

En PWA er bygget med webteknologi, ja, men:

• har en service worker til offline/caching og baggrundslogik
• har et Web App Manifest til installation på startskærm
• kan fungere app-lignende (full screen, ikon, splash screen osv.)

Det er fair at sige, at alle PWA’er er websites, men ikke alle websites er PWA’er.

“Native er altid bedre”

Native er stærkere til visse ting (hardware, performance, systemintegration), men “bedre” afhænger af:

• dit budget og din tidshorisont
• din målgruppe (desktop vs mobil, intern vs offentlig osv.)
• om du reelt har brug for native-features, eller om en god weboplevelse er nok

For rigtig mange produkter vil en veldesignet PWA-løsning dække behovet bedre, hurtigere og billigere end to fulde native apps.

“PWA’er kan ikke sende push-notifikationer”

Det er forældet. Moderne browsere understøtter web push-notifikationer, og PWA’er kan bruge dem. Men:

• understøttelsen og oplevelsen er ikke ens på alle platforme
• især på iOS er der historisk set flere begrænsninger og ændringer over tid

Derfor bør du altid teste, hvordan din konkrete PWA opfører sig på de platforme, du sigter efter, i stedet for at regne med enten “alt virker” eller “intet virker”.

“Hvis jeg vælger PWA nu, kan jeg aldrig få en native app”

Tværtimod kan en PWA være en fin første version af appen:

• Du får valideret produktet, UX, data-modeller og API’er.
• Du kan senere bygge native-klienter oven på de samme backend-API’er.

Det vigtige er at designe din backend og auth-arkitektur ordentligt fra start. Her kan du bl.a. kigge på artiklerne om loginvalg og auth-arkitektur, som gælder for både PWA’er og native apps.

Hvis du vil dybere ned i forskellen på webbaserede løsninger og andre softwaretyper, kan du også udforske kategorien softwaretyper og platforme og den mere generelle webudviklingskategori.