Flutter mot React Native: Spiller valget noen rolle for deg?
Både Flutter og React Native bygger apper for iOS og Android fra én kodebase og er gode nok for de fleste forretningsapper. React Native bygger på JavaScript, som gjør det lettere å finne utviklere og byråer, mens Flutter gir sterk kontroll over utseende og ytelse. For deg som kunde veier teamets erfaring som regel tyngre enn hvilket rammeverk de velger.
Flutter mot React Native er et spørsmål utviklere gjerne debatterer med stor innlevelse. Som kunde trenger du en roligere vinkel: Hva betyr valget faktisk for appen din, budsjettet ditt og muligheten din til å forvalte den? Her er sammenligningen uten religionskrig.
Hva de to faktisk er
Både Flutter og React Native er rammeverk for cross-platform-utvikling. Det betyr at du skriver appen én gang og får ut versjoner for både iOS og Android, i stedet for å bygge to separate native apper. Det reduserer normalt både kostnad og tid sammenlignet med å gjøre alt to ganger.
React Native bygger på JavaScript, samme språk som store deler av nettet. Flutter bruker språket Dart og tegner opp brukergrensesnittet på egen hånd. Begge er modne, godt utprøvde og brukes i apper som millioner av mennesker har i lommen. For de aller fleste forretningsapper holder hvilket som helst av dem godt.
Tilgang på kompetanse og byråer
Dette er faktoren som påvirker deg mest på lang sikt, og den handler ikke om teknologi, men om mennesker.
React Native har en fordel her: Det bygger på JavaScript, som svært mange utviklere allerede behersker fra webutvikling. Flutter vokser jevnt, men krever kunnskap om språket Dart.
Hvorfor spiller det noen rolle? Fordi en app lever i mange år etter lanseringen. Jo flere utviklere som kan teknologien, desto lettere er det å:
- Bemanne prosjektet fra start.
- Hente inn flere folk når det trengs.
- Bytte leverandør hvis samarbeidet ikke fungerer.
- Finne noen som forvalter appen om flere år.
Et bredere tilbud er rett og slett en trygghet. Det gjør deg mindre avhengig av én enkelt leverandør.
Utseende, ytelse og webstøtte på et overordnet nivå
De tekniske forskjellene er mindre dramatiske enn debatten gir inntrykk av, men de finnes.
| Aspekt | Kort forskjell |
|---|---|
| Utseende | Flutter tegner alt selv, sterk kontroll; React Native ligger nær plattformens komponenter |
| Ytelse | Begge holder for de fleste apper; for det mest krevende finnes marginale forskjeller |
| Webstøtte | React Native deler grunnlag med weben; Flutter kan også nå weben, men med andre avveiinger |
| Økosystem | Begge har rike biblioteker; React Native drar nytte av hvor stor JavaScript-verdenen er |
For en vanlig forretningsapp (kontoer, lister, skjemaer, varsler, betaling) gir begge et resultat der brukeren ikke merker noen forskjell. Forskjellene blir relevante først i mer spesielle tilfeller, som apper med svært tung grafikk eller ekstreme ytelseskrav.
Hvorfor teamet veier tyngre enn rammeverket
Her er poenget som er lett å overse: Et dyktig team i rammeverket de kan best, slår nesten alltid et middelmådig team i det «teoretisk riktige» rammeverket.
En konkret måte å tenke på: Hvis du har funnet et byrå som er virkelig sterkt på React Native, er det sjelden verdt å tvinge dem over på Flutter fordi en artikkel hyllet det, eller omvendt. Kvaliteten kommer fra erfaringen, ikke fra logoen på rammeverket.
Det er også slik vi resonnerer når vi anbefaler teknologi: Vi tar utgangspunkt i hva prosjektet trenger og hva teamet behersker, ikke i hvilket rammeverk som tilfeldigvis er mest omtalt akkurat nå. Velger du leverandør først og lar dem foreslå rammeverk ut fra egen styrke, havner du som regel riktig.
Hva spørsmålet heller bør handle om
Hvis du likevel vil bruke energi på et valg, bruk den på leverandøren snarere enn på rammeverket. Et byrå med solid erfaring, tydelig kommunikasjon og fornøyde tidligere kunder gir deg et bedre resultat enn det «riktige» rammeverket i hendene på et team som nettopp har begynt å lære det.
En praktisk måte å snu spørsmålet på: Be en mulig leverandør begrunne teknologivalget sitt ut fra appen din. Et svar som tar utgangspunkt i hva appen din skal gjøre og hva teamet er sterkest på, er et godt tegn. Et svar som mest handler om at et bestemt rammeverk er «best» generelt, er et dårligere tegn.
Så: Spiller valget noen rolle? Litt, mest gjennom tilgangen på kompetanse. Men velger du et kyndig team, blir selve rammeverksspørsmålet sjelden avgjørende. Vil du drøfte hva som passer appen din, er du velkommen til å ta kontakt.
Ofte stilte spørsmål
Hvilket er best, Flutter eller React Native?
Det finnes ikke noe generelt beste valg. Begge bygger apper for iOS og Android fra én kodebase og klarer de fleste forretningsapper godt. Forskjellene handler mer om tilgang på kompetanse og detaljer i utseende og ytelse enn om at det ene skulle være dårligere. Riktig valg avhenger av teamet ditt og prosjektet ditt.
Finnes det flere React Native- eller Flutter-utviklere?
React Native har en fordel ved at det bygger på JavaScript, som mange utviklere allerede kan. Flutter vokser, men krever kunnskap om språket Dart. Flere tilgjengelige utviklere gjør det enklere å bemanne, bytte leverandør og forvalte appen på sikt.
Ser man forskjell på en app bygget i Flutter og en i React Native?
Sjelden som bruker. Begge kan gi apper som ser ut og føles som en hvilken som helst moderne app. Flutter tegner opp brukergrensesnittet selv, noe som gir sterk kontroll over utseendet, mens React Native ligger nærmere plattformens egne komponenter. For en vanlig forretningsapp merkes forskjellen knapt.
Spiller valget av rammeverk noen rolle for prisen?
Marginalt sammenlignet med andre faktorer. Appens omfang, antall integrasjoner og designet påvirker kostnaden langt mer enn hvilket av de to rammeverkene som brukes. Et dyktig team i rammeverket de kan best, gir som regel både bedre resultat og en mer forutsigbar kostnad.
Kan vi bytte rammeverk senere?
Å bytte rammeverk betyr i praksis å bygge appen på nytt, så det er ikke noe man gjør i forbifarten. Derfor er valget verdt å tenke gjennom fra starten selv om begge alternativene er trygge. Velger du ut fra teamets kompetanse, blir risikoen mindre for at du noen gang må ta den beslutningen.