Appudvikler: native, cross-platform eller webapp-udvikler?
Hvilken appudvikler skal du vælge? Forskellen på native-, cross-platform- og webapp-udviklere, og hvad valget betyder for budget og vedligehold.
Freelance full-stack udvikler
- Udgivet
- Læsetid
- 11 min.
Indhold i indlægget9
Der findes groft sagt tre typer appudviklere: native-udviklere der bygger separate apps til iPhone og Android i Swift og Kotlin, cross-platform-udviklere der bygger én app til begge platforme med React Native eller Flutter, og webudviklere der bygger en webapp eller PWA som kører i browseren. Hvilken appudvikler du skal vælge, afhænger mest af to ting: om appen skal bruge telefonens hardware og ligge i App Store, og hvor meget du kan afsætte til vedligehold i årene efter lanceringen.
Jeg er selv webudvikler og bygger webapps og backends i Laravel og React, så læs med det forbehold. Jeg skriver lige så tydeligt hvornår en webapp ikke er nok, og hvornår du skal finde en anden end mig.
Den korte version: hvem bygger hvad?
| Native | Cross-platform | Webapp | |
|---|---|---|---|
| Sprog og værktøjer | Swift til iPhone, Kotlin til Android | React Native eller Flutter | Fx React, Next.js og Laravel, evt. som PWA |
| Kodebaser til selve appen | To, én pr. platform | Én, plus lidt platformspecifik kode | Én, som kører i browseren |
| App Store og Google Play | Ja | Ja | Nej som udgangspunkt |
| Adgang til telefonens hardware | Fuld | Næsten fuld via plugins | Begrænset, men kamera, placering og push virker som regel |
| Pris for første version | Højest | Mellem | Lavest |
| Løbende vedligehold | To apps der skal følge Apple og Google | Én app plus opgraderinger af frameworket | Ingen butikskrav, rettelser går live med det samme |
| Passer typisk til | Apps hvor ydeevne eller hardware er selve produktet | Forbrugerapps der skal findes i butikkerne | Kundeportaler, interne værktøjer, B2B og MVP'er |
Min tommelfingerregel er at starte med ét spørgsmål: skal appen overhovedet ligge i App Store? Hvis nej, er en webapp næsten altid det billigste og hurtigste valg. Hvis ja, er cross-platform det fornuftige udgangspunkt, og native er til apps hvor telefonen selv er en stor del af produktet.
Er du i tvivl om hvad de forskellige udviklerroller dækker mere generelt, så start med min oversigt over typer udviklere og hvem der gør hvad. Resten af indlægget handler kun om apps.
Native-udvikleren: Swift til iPhone, Kotlin til Android
Native betyder at appen bygges direkte med platformens egne værktøjer: Swift og SwiftUI i Apples Xcode til iPhone og iPad, og Kotlin i Android Studio til Android. Appen får adgang til alt hvad telefonen kan, og den føles som en del af styresystemet, fordi den bruger de samme byggeklodser som Apples og Googles egne apps.
Prisen er at du får to apps. iOS og Android er to forskellige specialer, og mange native-udviklere arbejder kun med den ene platform. Ofte skal du derfor bruge to udviklere eller et helt team, og hver ny funktion skal bygges, testes og udgives to gange. Backenden deles mellem de to apps, så regningen bliver sjældent præcis dobbelt så stor, men forskellen kan mærkes.
Native er det rigtige valg når telefonen er en stor del af produktet. Det gælder fx avanceret kamera- eller lydbehandling, tæt samspil med ure, sensorer eller Bluetooth-udstyr, spil og apps hvor animationer og svartider skal være helt i top.
Hvornår du ikke skal vælge native
- Når appen mest viser data og formularer fra en server, som de fleste forretningsapps gør. Så betaler du for to kodebaser uden at brugeren mærker forskellen.
- Når budgettet kun rækker til første version. To native apps er dyre at holde i live, og en app der ikke bliver opdateret, forfalder hurtigt.
- Når du endnu ikke ved om nogen vil bruge den. Test idéen på en billigere måde først.
Cross-platform-udvikleren: React Native og Flutter
En cross-platform-udvikler skriver én app som kører på både iPhone og Android. De to store frameworks er React Native, som bygger på JavaScript og React og vedligeholdes af Meta, og Flutter, som bruger sproget Dart og vedligeholdes af Google. Begge giver apps der ligger i App Store og Google Play og for brugeren ligner almindelige apps.
For de fleste forbrugerapps er det et godt kompromis. Du får én kodebase, ét team og nye funktioner der lander på begge platforme samtidig. React Native har den fordel at udviklere med React-erfaring fra web hurtigt kan bidrage, og at noget logik kan deles med en webapp.
Ulempen er et ekstra lag mellem din app og telefonen. Når Apple eller Google ændrer noget, skal frameworket og dets plugins følge med før din app kan. Større opgraderinger af frameworket kan tage dage, og nogle gange skal der alligevel skrives native kode i Swift eller Kotlin til en enkelt funktion. Spørg derfor en cross-platform-udvikler om vedkommende også kan det, eller hvem der gør det.
Hvornår du ikke skal vælge cross-platform
- Når appen er så afhængig af hardware at store dele alligevel skal skrives native. Så får du det dyreste fra begge verdener.
- Når du ikke har brug for butikkerne. Så er en webapp billigere at bygge og at vedligeholde.
Webapp-udvikleren: webapp og PWA
En webapp kører i browseren og virker på telefon, tablet og computer fra én kodebase. Det er den type løsning jeg selv bygger. En PWA (progressive web app) er en webapp der kan lægges på hjemmeskærmen og åbnes i fuld skærm som en app. Siden iOS 16.4 kan webapps på hjemmeskærmen også sende push-notifikationer på iPhone, og det fjernede en af de største grunde til at vælge en app i butikken.
Den store fordel er økonomien. Der er ingen butiksgodkendelse, ingen årlige butikskrav og ingen gamle versioner der lever videre på brugernes telefoner. Retter du en fejl, har alle rettelsen med det samme. En webudvikler bygger ofte også backenden, så én person kan stå for hele løsningen. Det har jeg skrevet mere om i indlægget om hvornår én fullstack-udvikler er nok til hele projektet.
Webappen har dog sine grænser. Den findes ikke i App Store, og mange forbrugere leder stadig efter apps der. Adgangen til hardware er mere begrænset end i en native app, især på iPhone, og ting som avancerede baggrundsopgaver og visse Bluetooth-forbindelser er svære eller umulige fra browseren.
Hvornår du ikke skal vælge en webapp
- Når synlighed i App Store eller Google Play er en vigtig del af din markedsføring.
- Når appen skal virke fuldt ud uden internet i længere tid eller bruge hardware som browseren ikke giver adgang til.
- Når dine brugere forventer at finde dig i butikken, fx fordi alle dine konkurrenter har en app der.
Den del alle glemmer: backenden
Appen på telefonen er kun den synlige halvdel. Skal brugerne logge ind, se deres egne data, betale eller modtage beskeder, skal der også være en backend: en server med en database, et API (den forbindelse appen henter og gemmer data igennem) og som regel et administrationspanel hvor du selv kan rette indhold og hjælpe kunder.
Den del skal bygges ved alle tre typer, og den er ofte en stor del af det samlede arbejde. Mange appudviklere er stærke til brugerflader men bygger nødigt backends, og så ender du med at skulle finde endnu en udvikler. Spørg derfor tidligt hvem der bygger og driver serveren.
Her kan typerne kombineres. En fornuftig opdeling er tit en webudvikler der bygger backend, API og administration, og en appudvikler der bygger appen ovenpå. Skal det hele ske samtidig med design og flere platforme, kan et samlet team være det rigtige, og så er det værd at læse min ærlige sammenligning af freelancer og bureau.
Hvad valget betyder for budget og vedligehold
Den største forskel på de tre typer ligger sjældent i prisen på første version. Den ligger i hvad appen koster at holde i live. En app i butikkerne bliver aldrig færdig, for Apple og Google opdaterer deres styresystemer hvert år og stiller krav om at apps følger med.
Et par konkrete eksempler:
- Google Play kræver at nye apps og opdateringer er bygget til en nyere Android-version. Fra 31. august 2026 er kravet Android 16, og eksisterende apps der er bygget til Android 14 eller ældre, kan ikke længere hentes af nye brugere på nyere telefoner.
- Apple hæver løbende kravet til hvilken version af udviklingsværktøjet Xcode nye opdateringer skal bygges med. Er appen ikke blevet vedligeholdt, kan du ende med at skulle opgradere hele projektet før du kan udgive en hurtig fejlrettelse.
- Apples udviklerprogram koster 99 dollars om året, og Google tager en mindre engangsafgift. Beløbene er små, men udløber medlemskabet hos Apple, kan appen ikke længere hentes, og du kan ikke sende opdateringer.
| Native | Cross-platform | Webapp | |
|---|---|---|---|
| Faste opgaver hvert år | Tilpas to apps til nye versioner af iOS og Android | Opgradér framework og plugins, og test på begge platforme | Opdatér pakker og server, ingen butikskrav |
| Udgivelse af en fejlrettelse | To indsendelser og to godkendelser | Typisk to indsendelser og to godkendelser | Live med det samme |
| Hvem kan overtage koden | Udviklere med Swift- og Kotlin-erfaring | Udviklere der kender samme framework | Typisk det største udvalg af udviklere |
| Hvis ingen vedligeholder den | Appen kan ikke opdateres og mister nye brugere på nye telefoner | Det samme, og opgraderingen bliver større jo længere du venter | Siden kører typisk videre, men sikkerhedsopdateringer hober sig op |
Regner du på budgettet, så tag vedligeholdet med fra start. Selv i de år hvor du ikke bygger nye funktioner, kræver en app i butikkerne betalte udviklertimer. Konkrete prisniveauer for webapps, PWA'er og native apps finder du i min guide til hvad en app koster.
Sådan vælger du den rigtige appudvikler i fem trin
- Skriv ned hvad appen skal kunne på telefonen: kamera, placering, push-beskeder, brug uden internet, Bluetooth, betaling. Er listen kort og standard, kan en webapp klare det. Er der hardware som browseren ikke kan nå, peger det mod cross-platform eller native.
- Afgør om App Store er et krav eller en vane. Skal fremmede kunne finde dig i butikken, er det et krav. Er brugerne dine egne kunder eller medarbejdere som du allerede har kontakt med, kan du sende dem et link, og så er butikken ofte mere vane end behov.
- Start med den mindste version der kan testes. En webapp eller PWA er tit den billigste måde at finde ud af om løsningen bliver brugt. Backenden kan genbruges hvis du senere bygger en app til butikkerne.
- Regn på tre år, ikke kun på lanceringen. Spørg om opdateringer til nye versioner af iOS og Android er med i tilbuddet, og hvad de koster hvis ikke.
- Find en udvikler der har udgivet netop den type app før. En native-udvikler vil ofte anbefale native, og en webudvikler som mig vil ofte anbefale en webapp. Derfor skal typen være afgjort før du spørger.
Spørg appudvikleren om det her før du skriver under
- Hvilke apps har du udgivet i App Store og Google Play? Bed om at se dem i butikkerne.
- Hvem ejer udviklerkontiene? Appen skal ligge på din virksomheds egen konto hos Apple og Google, ikke på udviklerens.
- Hvem bygger og driver backenden? Og hvor ligger brugernes data?
- Hvad koster det at holde appen opdateret? Få et skøn pr. år på skrift.
- Hvor ligger koden? Den skal ligge i dit eget repository (kodearkiv) fra første dag.
- Hvad sker der hvis du stopper? Kan en anden udvikler overtage, og findes der dokumentation?
Er du stadig i tvivl om hvilken slags udvikler dit projekt kræver, så prøv min beslutningsguide efter projekttype.
Næste skridt
Handler din app mest om login, data og formularer, er en webapp sandsynligvis nok. Det er den slags løsninger jeg bygger: kundeportaler, interne værktøjer og platforme hvor én kodebase dækker både telefon og computer. Du kan se hvordan jeg griber det an på siden om webapps og platforme.
Skal du have en ren native app til iPhone og Android, er jeg ikke den rette til at bygge selve appen. Til gengæld hjælper jeg gerne med at afklare valget og med backenden bag den. Ved større projekter starter jeg med et betalt forprojekt til fast pris. Her afklarer jeg sammen med dig hvilken type løsning der passer, og først derefter bliver der skrevet kode.
Ofte stillede spørgsmål
Kan en webudvikler bygge en app til App Store?
Ja, men med forbehold. En webudvikler kan pakke en webapp ind med værktøjer som Capacitor, så den kan ligge i App Store og Google Play. Apple afviser dog apps der ikke er meget mere end en hjemmeside, så appen skal have funktioner der udnytter telefonen. Kræver appen meget native kode, er en cross-platform- eller native-udvikler et bedre valg.
Kan jeg starte med en webapp og bygge en rigtig app senere?
Ja, og det er ofte en fornuftig rækkefølge. Er backenden bygget med et API, kan en senere app til iPhone og Android bruge den samme server, database og administration. Det er primært brugerfladen der skal bygges igen. Sig det til udvikleren fra start, så API'et bliver lavet til flere slags klienter.
Hvem skal eje udviklerkontoen hos Apple og Google?
Din virksomhed. Opret selv kontiene og giv udvikleren adgang, så appen ikke er bundet til én bestemt person. Som virksomhed skal du typisk bruge et D-U-N-S-nummer for at tilmelde dig hos Apple. Det er gratis, men kan tage nogle arbejdsdage at få, så start i god tid før lanceringen.
Er React Native eller Flutter bedst?
Ingen af dem er bedst i alle tilfælde. Begge er modne og bruges til apps i begge butikker. React Native er oplagt hvis du allerede har en webapp i React eller udviklere med JavaScript-erfaring, fordi viden og noget logik kan deles. Flutter er stærk når appen skal se helt ens ud på begge platforme. Vælg ud fra udvikleren og dit eksisterende system.