Flutter eller React Native – hva bør bedriften velge?

Flutter er laget av Google og bruker programmeringsspråket Dart. Koden kompileres til maskinkode for iOS og Android, og Flutter tegner alle knapper, lister og overganger selv med sin egen grafikkmotor i stedet for å bruke plattformens innebygde komponenter. Samme kodebase kan også bygges til web og desktop.

React Native er laget av Meta og ble sluppet i 2015. Koden skrives i JavaScript, i praksis nesten alltid TypeScript, med samme programmeringsmodell som React på web. Forskjellen fra Flutter er at React Native bruker plattformens egne komponenter: en knapp i appen er en ekte iOS-knapp på iPhone og en ekte Android-knapp på Android. Verktøykassen Expo tar seg av bygging, publisering og oppdateringer, og er standardvalget for nye prosjekter.

To kjente norske apper viser at begge valgene fungerer i stor skala.

Coop Norge skrev appen sin på nytt i Flutter allerede i 2019, ifølge kode24. Det er en dagligvareapp med medlemskap, tilbud og kvitteringer, brukt av svært mange nordmenn hver uke.

AtB, kollektivselskapet i Trøndelag, bygde reiseappen sin i React Native og TypeScript og la koden ut som åpen kildekode under EUPL-1.2. Samme kodebase brukes av FRAM i Møre og Romsdal, Reis Nordland og Svipper i Troms. Fire fylker deler altså én React Native-app, noe som sier mye om hvor godt rammeverket tåler å bli gjenbrukt og vedlikeholdt av flere.

Poenget er ikke at dere skal kopiere noen av dem. Poenget er at ingen av valgene er en risiko i seg selv.

For en vanlig bedriftsapp med lister, skjemaer, kart, innlogging og push merker ikke brukerne forskjell på Flutter, React Native eller native. Det gjelder også Vipps-betaling og BankID-innlogging, som uansett skjer i egne apper eller i nettleseren.

Flutter har en fordel i tunge animasjoner og grafikk, fordi hele skjermen tegnes av én motor uten å gå fram og tilbake mellom rammeverk og plattform. React Native har en fordel i at appen føles helt hjemme på hver plattform, fordi komponentene er plattformens egne.

Der begge sliter, er ved svært krevende oppgaver: 3D, utvidet virkelighet, kontinuerlig bakgrunnsprosessering eller tett Bluetooth-integrasjon mot utstyr. Da må deler skrives som native moduler, og noen ganger er hele appen bedre tjent med Swift og Kotlin. Mer om det lenger ned.

Dette er det mest undervurderte argumentet. Erik Wendel i Bekk sa til kode24 at det er ekstremt vanskelig å finne kvalifiserte iOS- og Android-utviklere i Norge, og anslo at man sparer nær 45 prosent av arbeidet med React Native sammenlignet med to native apper.

React Native drar nytte av at Norge er fullt av utviklere som kan React og TypeScript fra webprosjekter. Har dere et eget IT-team som jobber med web, kan de ofte ta over en React Native-app etter lansering. Flutter krever at noen lærer Dart. Det tar erfarne utviklere noen uker, men det er en terskel hvis dere skal vedlikeholde appen selv.

Skal et byrå både bygge og drifte appen, betyr utviklertilgangen mindre for dere. Da bør dere heller spørre hvem som skal bygge appen, og be om å se arbeid de har gjort i rammeverket.

Begge rammeverkene må følge med når Apple og Google slipper nye versjoner av iOS og Android hver høst, og begge har biblioteker som må oppdateres. Der er det ingen forskjell, og begge trenger en avtale om vedlikehold og drift av app.

Forskjellen ligger i småoppdateringer. Med React Native og EAS Update kan endringer i JavaScript, stiler og bilder sendes rett til brukernes telefoner uten ny butikkgodkjenning. Retter dere en tekstfeil eller en knapp som ikke virker, er det ute samme dag. Endringer i native kode, tillatelser eller SDK-versjon krever fortsatt ny bygging og innsending. Flutter kompilerer koden, så oppdateringer går normalt gjennom App Store og Google Play hver gang.

For apper med hyppige små endringer, som kampanjer eller innhold, er dette et reelt argument for React Native.

Noen apper bør bygges i Swift for iOS og Kotlin for Android selv om det koster mer. Det gjelder apper der Apple Watch, widgets eller andre plattformspesifikke funksjoner er selve produktet, apper med tung Bluetooth- eller sensorintegrasjon, og apper som skal kjøre mye i bakgrunnen. Det gjelder også hvis dere allerede har et native team. DNB søkte i 2026 etter apputviklere i Bergen med krav om Kotlin, Swift, Jetpack Compose, SwiftUI og Kotlin Multiplatform, og store banker bygger fortsatt native av gode grunner.

Kotlin Multiplatform er et tredje alternativ som ligger mellom native og kryssplattform: forretningslogikken deles i Kotlin, mens brukergrensesnittet skrives native for hver plattform, eller deles med Compose Multiplatform. Det passer best for selskaper som allerede har Android-kompetanse. Les mer om iOS-apputvikling og Android-apputvikling, eller ta hele valget fra toppen i guiden native, hybrid eller webapp.