Hvad koster det at bygge en PWA?

Af Weapp · Opdateret

En PWA koster som regel 60–80 procent af hvad en tilsvarende native app ville koste fordi du bygger én kodebase i stedet for én pr. platform. Besparelsen er reel, men PWA har begrænsninger i iOS-funktioner, tilstedeværelse i appbutikkerne og hardwareadgang. Den er det rigtige valg til B2B-værktøjer, kataloger og bookingflows, mindre egnet til forbrugerapps der kræver fuld platformsintegration.

En PWA (progressive web app) er nettets svar på mobilappen: en app som brugeren kan installere på hjemmeskærmen, og som virker delvist offline, men som kører i browseren i stedet for at blive downloadet fra en butik. Det gør den billigere end en native app, og til de rette formål er den et smart valg. Men den lavere pris har en bagside som er værd at kende før du beslutter dig.

Hvad en PWA koster

Den enkle tommelfingerregel: En PWA lander som regel på 60–80 procent af hvad en tilsvarende native app ville koste. Grunden er én kodebase i stedet for to.

AlternativRelativ udgift
Native, iOS + AndroidFuld udgift (to kodebaser)
PWACirka 60–80 % af native
Videreudvikling af PWALavere, kun én kodebase at opdatere

Besparelsen er størst over tid. En native satsning på både iOS og Android betyder to apps der skal bygges og derefter vedligeholdes i takt med at styresystemerne opdateres. En PWA har én kodebase der virker overalt, hvilket sænker både udgiften til udvikling og udgiften til drift og vedligeholdelse.

Hvorfor bliver det billigere? Fordi den største udgift i appudvikling er arbejdstiden, og to platforme betyder i praksis at meget arbejde udføres to gange: to kodebaser der skal bygges, testes og holdes opdaterede. En PWA bygges én gang med webteknologi og kører i browserens motor på alle enheder. Du slipper for dobbeltarbejdet, og du slipper for appbutikkernes godkendelse ved hver opdatering, hvilket sænker både tærsklen og den løbende udgift til at forbedre produktet.

Bagsiden: begrænsninger der kan koste senere

Besparelsen er reel, men den kommer med kompromiser. De vigtigste at tage med i vurderingen:

  • iOS-funktioner. På iOS har PWA’er mindre adgang til systemet end på Android. Visse notifikations- og integrationsfunktioner er begrænsede, og det er på Apples platform du tydeligst mærker forskellen til native.
  • Tilstedeværelse i butikkerne. En PWA findes ikke i App Store eller Google Play medmindre du gør et ekstra stykke arbejde. Den synlighed og den tillid som en plads i butikken giver, udebliver.
  • Hardwareadgang. Dyb adgang til kamera, sensorer og andre funktioner er mere begrænset end i en native app.

Ingen af dem er et problem i sig selv, men hvis nogen af dem er afgørende for dit produkt, kan den billigere vej ende med at blive dyrere.

Hvornår en PWA er det rigtige valg

En PWA brillerer når rækkevidde og lav pris vejer tungere end dyb platformsintegration. Tydelige tilfælde:

  1. B2B-værktøjer. Et værktøj som medarbejderne bruger i browseren på arbejdet, og hvor installation via en butik bare er i vejen.
  2. Kataloger. Produkt- eller indholdskataloger der skal være lette at nå uden download.
  3. Bookingflows. Book en tid, en plads eller en ydelse: flows hvor nettet er en naturlig indgang.

I de tilfælde får du appfølelsen og besparelsen uden at savne det som native tilbyder.

Et konkret scenarie

Lad os sige at du vil give feltmedarbejdere et værktøj til at registrere arbejde og se arbejdsplaner, tilgængeligt på både telefon og tablet uanset mærke. En PWA er det rigtige valg: én kodebase, ingen godkendelse i butikkerne, hurtige opdateringer. Regn med omkring to tredjedele af hvad tilsvarende native apps til iOS og Android ville koste.

Har produktet senere brug for dyb platformsintegration, kan man bygge native på det tidspunkt. Det er ofte en klog strategi: Start med en PWA for at nå markedet hurtigt og billigt, valider at idéen holder, og sats først på native når du ved at produktet er den større investering værd. Vælger du de rigtige teknologier fra start, kan dele af arbejdet genbruges, hvilket gør skridtet mindre bekosteligt.

Den mest almindelige fejl er at vælge teknologi efter hvad der lyder mest imponerende, i stedet for efter hvad produktet faktisk har brug for. En dyr native app til noget der lige så godt kunne være en PWA, er spildte penge; en PWA til et forbrugerprodukt der lever af notifikationer og synlighed i butikkerne, bliver en besparelse der koster i tabt rækkevidde. Det rigtige valg er det der matcher hvordan produktet skal bruges. Vi hos Weapp bygger både PWA’er og native apps og hjælper dig med at vælge rigtigt ud fra produktets krav. Se vores ydelser eller kontakt os med din idé.

Ofte stillede spørgsmål

Hvor meget billigere er en PWA end en native app?

En PWA lander som regel på 60–80 procent af udgiften til en tilsvarende native app. Besparelsen kommer af at du bygger og vedligeholder én kodebase der virker i browseren på alle enheder, i stedet for separate apps til iOS og Android. Ved videreudvikling bliver forskellen endnu tydeligere fordi du kun har én kodebase at opdatere.

Hvad er en PWA?

En PWA, progressive web app, er en webapp der opfører sig som en app man kan installere. Brugeren kan lægge den på hjemmeskærmen, den virker delvist offline og kan sende notifikationer. Den kører i browserens motor i stedet for at blive downloadet fra en appbutik, hvilket gør den billigere at bygge og hurtigere at opdatere.

Hvilke begrænsninger har en PWA?

Først og fremmest på iOS, hvor PWA’er har mindre adgang til systemfunktioner end på Android. Visse notifikations- og hardwarefunktioner er begrænsede, og du mangler den synlighed det giver at være i App Store og Google Play. Er nogen af dem afgørende for produktet, kan begrænsningerne koste dig senere.

Hvornår er en PWA det rigtige valg?

Når rækkevidde og lav pris vejer tungere end dyb platformsintegration. En PWA passer godt til B2B-værktøjer som medarbejdere bruger i browseren, til produktkataloger og til bookingflows. Den er mindre egnet til forbrugerapps der lever af notifikationer, avanceret hardwareadgang eller synlighed i appbutikkerne.

Kan man gå fra PWA til native senere?

Ja, og det er en almindelig strategi. Man kan starte med en PWA for at nå markedet hurtigt og billigt, validere idéen og derefter bygge native hvis behovet for dybere platformsintegration vokser. Vælger man de rigtige teknologier fra start, kan dele af arbejdet genbruges, hvilket gør skridtet mindre bekosteligt.