Flutter vs. native udvikling: Hvad skal I vælge?

Af Weapp · Opdateret 2025-06-06

Flutter tegner hele brugerfladen med sin egen renderingsmotor, og det giver identisk UI på iOS og Android og lavere omkostninger end to native teams. Native udvikling er begrundet når platformsfølelse, hardwarenære funktioner eller den langsigtede kompetenceforsyning vejer tungest. Dart bruges i praksis kun til Flutter, og det gør bemandingen til et nøglespørgsmål.

Flutter lover det samme som al cross-platform-teknologi: én kodebase til både iOS og Android i stedet for to. Men Flutter holder løftet på sin egen måde, med sproget Dart og sin egen renderingsmotor der selv tegner hver eneste pixel. Begge valg har konsekvenser som en kunde bør forstå før teknologien låses fast.

Flutters egen renderingsmotor: styrken og prisen

Native apps, og også React Native, bygger brugerfladen af platformens egne komponenter. Flutter gør det modsatte: Frameworket tegner hele brugerfladen med sin egen motor, oven på et tyndt lag mod platformen.

Styrken er konsistens. Appen ser identisk ud på en gammel Android-telefon og en ny iPhone, designsystemet gengives præcis som designeren havde tænkt det, og animationer glider fint. For brandorienterede apps med eget formsprog er det et reelt argument.

Prisen er platformsfølelsen. En iPhone-bruger mærker, ofte ubevidst, når scrollfysik, overgange og kontroller ikke opfører sig præcis som resten af telefonen. Flutter kan efterligne platformenes adfærd, men det er netop en efterligning der skal bygges og vedligeholdes, ikke noget appen får gratis. Jo vigtigere det er at appen føles som en del af styresystemet, jo mere vejer dette punkt.

En praktisk følgevirkning er releasetempoet: Med en fælles kodebase udgives iOS- og Android-versionerne i takt, bygget af det samme team ud fra den samme backlog. Med to native spor kræves der aktiv koordinering for at butikkerne ikke glider fra hinanden. Det arbejde ses sjældent i tilbuddet, men altid i driften.

Dart og kompetencespørgsmålet

Native udvikling foregår i Kotlin og Swift, to sprog der bærer hele henholdsvis Android- og iOS-økosystemet og dermed en stor, stabil kompetencebase. Dart bruges i praksis kun til Flutter.

For et enkelt projekt betyder det ikke meget, for et erfarent bureau eller et indlejet team klarer udviklingen. Spørgsmålet er hvad der sker i år to til ti. Appen skal driftes, videreudvikles og indimellem skifte hænder. Så bliver sprogvalget et forsyningsspørgsmål: Hvor hurtigt finder I en afløser når Flutter-udvikleren stopper, og til hvilken pris? Puljen af Dart-udviklere vokser, men den er stadig betydeligt mindre end for JavaScript og Kotlin. Det gør ikke Flutter til et forkert valg, men det gør kompetenceplanen til en obligatorisk del af beslutningen, ikke en fodnote. Konkret: Bed leverandøren om at redegøre for hvordan driften og vedligeholdelsen bemandes i år tre, ikke kun hvem der bygger i år ét, og regn med et vist pristillæg for smal specialistkompetence hvis appen skal drives videre internt.

Hvornår native stadig er to teams værd

Der findes situationer hvor to native kodebaser retfærdiggør den dobbelte omkostning:

Appen er jeres hovedprodukt og skal føles perfekt hjemme på hver platform, i hver eneste detalje.
Hardwarenære kernefunktioner (avanceret Bluetooth, baggrundstjenester, AR eller specialudstyr), hvor platformenes egne API’er giver den korteste vej og den mest stabile drift.
Ekstreme krav til ydeevne, f.eks. realtidslyd eller tung videobehandling.
Organisationen har allerede etablerede iOS- og Android-teams der leverer godt. Så er omstillingsomkostningen et projekt i sig selv.

Uden for de situationer er det svært at forsvare to parallelle kodebaser økonomisk: Hver funktion bygges, testes og vedligeholdes dobbelt, år efter år.

Et konkret scenarie

Forestil jer en eventapp: program, billetter, kort, notifikationer. Bygget native kræver den to udviklingsspor der hver for sig implementerer de samme ti skærme, måske 1,3–1,9 mio. DKK i alt. Med Flutter bygges skærmene én gang, med fælles logik og design, til en klart lavere totalomkostning og med samtidige releases i begge butikker.

Vend så scenariet om: en app hvis kerne er at styre egen hardware via Bluetooth i baggrunden, med krav om perfekt platformintegration. Dér kan de native API’er være halvdelen af produktet, og to teams en rimelig forsikringspræmie.

Beslutningskriterier i korte træk

Vej tre ting: hvor central platformsfølelsen er for jeres produkt, hvor hardwarenære kernefunktionerne er og hvordan I skal bemande appen de næste fem år. Peger to ud af tre væk fra Flutter, taler det for native. Ellers er en fælles kodebase som regel det rigtige udgangspunkt, i Flutter eller i React Native, som er vores primære stack hos Weapp. Usikker på hvor din app lander? Kontakt os, så ræsonnerer vi om netop jeres situation.

Ofte stillede spørgsmål

Hvad er Dart?

Det programmeringssprog Flutter bygger på, udviklet af Google. Det er moderne og populært blandt dem der arbejder i det, men bruges i praksis næsten udelukkende til Flutter, i modsætning til Kotlin og Swift, der bærer hele henholdsvis Android- og iOS-verdenen.

Føles en Flutter-app som en rigtig app?

Ja, i de fleste tilfælde. Flutter tegner selv brugerfladen med høj præcision og ydeevne. Prisen er at appen ikke automatisk arver platformens præcise adfærd og detaljer. Skal den føles helt hjemme på iOS, skal den fornemmelse bygges bevidst.

Er Flutter billigere end native udvikling?

Som regel, ja: Én kodebase erstatter to. Besparelsen gælder både udviklingen og årene efter: én kodebase at vedligeholde, ét team at bemande og fælles releases. Hvor stor forskellen bliver, afhænger af hvor meget platformspecifikt arbejde appen alligevel kræver.

Hvordan ser udbuddet af Flutter-udviklere ud?

Klart mindre end for JavaScript og Kotlin. Dygtige Flutter-udviklere findes, men puljen er begrænset. Det påvirker rekrutteringstid, konsulentpriser og sårbarheden hvis en nøgleperson stopper, og det er faktorer der bør indgå i beslutningen.

Kan Flutter bruges til mere end mobilapps?

Ja, den samme kodebase kan bygges til web og desktop. I praksis er mobil stadig den primære anvendelse, og webunderstøttelsen passer bedst til applignende værktøjer snarere end til indholdstunge hjemmesider der skal indekseres af søgemaskiner.