Flutter eller native utvikling?

Av Weapp · Oppdatert 2025-06-06

Flutter tegner hele brukergrensesnittet med en egen renderingsmotor, noe som gir identisk UI på iOS og Android og lavere kostnad enn to native team. Native utvikling er berettiget når plattformfølelse, maskinvarenære funksjoner eller langsiktig kompetansetilgang veier tyngst. Dart-utviklere er betydelig færre enn Kotlin- og Swift-utviklere, og det gjør bemanningen til et nøkkelspørsmål.

Flutter lover det samme som all cross-platform-teknologi: én kodebase for både iOS og Android i stedet for to. Men Flutter holder løftet på sin egen måte, med språket Dart og en egen renderingsmotor som tegner hver piksel selv. Begge valgene har konsekvenser som en kunde bør forstå før teknologien låses.

Flutters egen renderingsmotor: styrken og prisen

Native apper, og også React Native, bygger brukergrensesnittet av plattformens egne komponenter. Flutter gjør det motsatte: Rammeverket tegner hele brukergrensesnittet med sin egen motor, oppå et tynt plattformlag.

Styrken er konsistens. Appen ser identisk ut på en gammel Android-telefon og en ny iPhone, designsystemet gjengis nøyaktig slik designeren har tenkt, og animasjonene glir fint. For merkevaredrevne apper med eget formspråk er det et reelt argument.

Prisen er plattformfølelsen. En iPhone-bruker merker, ofte ubevisst, når rullefysikk, overganger og kontroller ikke oppfører seg nøyaktig som resten av telefonen. Flutter kan etterligne plattformenes oppførsel, men det er nettopp en etterligning som må bygges og vedlikeholdes, ikke noe appen får gratis. Jo viktigere det er at appen føles som en del av operativsystemet, desto mer veier dette punktet.

En praktisk følge er utgivelsestakten: Med én felles kodebase slippes iOS- og Android-versjonene i takt, bygget av samme team mot samme backlog. Med to native spor kreves aktiv samordning for at butikkene ikke skal gli fra hverandre. Det arbeidet er sjelden synlig i tilbudet, men alltid i forvaltningen.

Dart og kompetansespørsmålet

Native utvikling skjer i Kotlin og Swift, to språk som bærer henholdsvis hele Android- og iOS-økosystemet og dermed en stor, stabil kompetansebase. Dart brukes i praksis bare til Flutter.

For et enkeltstående prosjekt betyr det lite: Et erfarent byrå eller et innleid team klarer utviklingen. Spørsmålet er hva som skjer fra år to til ti. Appen skal forvaltes, videreutvikles og av og til skifte hender. Da blir språkvalget et spørsmål om tilgang på folk: Hvor raskt finner dere en erstatter når Flutter-utvikleren slutter, og til hvilken pris? Gruppen av Dart-utviklere vokser, men den er fortsatt betydelig mindre enn for Kotlin, Swift eller JavaScript. Det gjør ikke Flutter til et feil valg, men det gjør kompetanseplanen til en obligatorisk del av beslutningen, ikke en fotnote. Konkret: Be leverandøren redegjøre for hvordan forvaltningen bemannes i år tre, ikke bare hvem som bygger i år én, og regn med et visst pristillegg for smal spisskompetanse hvis appen skal drives videre internt.

Når native fortsatt er verdt to team

Det finnes situasjoner der to native kodebaser forsvarer den doble kostnaden:

Appen er hovedproduktet deres og skal føles helt naturlig på hver plattform, i hver detalj.
Maskinvarenære kjernefunksjoner (avansert Bluetooth, bakgrunnstjenester, AR eller spesialutstyr) der plattformenes egne API-er gir kortest vei og mest stabil drift.
Ekstreme ytelseskrav, som sanntidslyd eller tung videobehandling.
Organisasjonen har allerede etablerte iOS- og Android-team som leverer godt. Da er omstillingskostnaden et eget prosjekt.

Utenfor disse situasjonene er det vanskelig å forsvare to parallelle kodebaser økonomisk: Hver funksjon bygges, testes og vedlikeholdes dobbelt, år etter år.

Et konkret scenario

Tenk dere en eventapp: program, billetter, kart, varsler. Bygget native krever den to utviklingsspor som hver for seg implementerer de samme ti skjermbildene, kanskje 1,5–2,2 millioner kr totalt. Med Flutter bygges skjermbildene én gang, med felles logikk og design, til en klart lavere totalkostnad og med samtidige utgivelser i begge butikkene.

Snu så scenarioet: en app der kjernen er å styre egen maskinvare via Bluetooth i bakgrunnen, med krav om perfekt plattformintegrasjon. Der kan de native API-ene være halve produktet, og to team en fornuftig forsikringspremie.

Beslutningskriterier i korte trekk

Vei tre ting: hvor sentral plattformfølelsen er for produktet deres, hvor maskinvarenære kjernefunksjonene er, og hvordan dere skal bemanne appen de neste fem årene. To av tre mot Flutter taler for native. Ellers er én felles kodebase som regel riktig utgangspunkt, i Flutter eller i React Native, som er hovedstacken vår i Weapp. Usikre på hvor appen deres havner? Ta kontakt, så drøfter vi akkurat deres situasjon.

Ofte stilte spørsmål

Hva er Dart?

Programmeringsspråket som Flutter bygger på, utviklet av Google. Det er moderne og verdsatt av dem som jobber i det, men brukes i praksis nesten utelukkende til Flutter, i motsetning til Kotlin og Swift, som bærer henholdsvis hele Android- og iOS-verdenen.

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

Ja, i de fleste tilfeller. Flutter tegner brukergrensesnittet selv med høy presisjon og ytelse. Prisen er at appen ikke automatisk arver plattformens nøyaktige oppførsel og detaljer. Skal den føles helt naturlig på iOS, må den følelsen bygges bevisst.

Er Flutter billigere enn native utvikling?

Som regel. Grunnen er at én kodebase erstatter to. Besparelsen gjelder både utviklingen og årene etterpå: én kodebase å vedlikeholde, ett team å bemanne og felles utgivelser. Hvor stor forskjellen blir, avhenger av hvor mye plattformspesifikt arbeid appen likevel krever.

Hvordan er tilgangen på Flutter-utviklere?

Klart mindre enn for Kotlin, Swift eller JavaScript. Dyktige Flutter-utviklere finnes, men gruppen er begrenset. Det påvirker rekrutteringstid, konsulentpriser og sårbarheten hvis en nøkkelperson slutter, og det er faktorer som bør veies inn i beslutningen.

Kan Flutter brukes til mer enn mobilapper?

Ja, samme kodebase kan bygges for web og desktop. I praksis er mobil fortsatt hovedbruken, og webstøtten passer best for applignende verktøy snarere enn innholdstunge nettsider som skal indekseres av søkemotorer.