Flutter vs. React Native: Betyder valget noget for dig?
Både Flutter og React Native bygger apps til iOS og Android fra én kodebase og rækker fint til de fleste forretningsapps. React Native bygger på JavaScript, som langt flere udviklere kan, mens Flutter giver stærk kontrol over udseende og ydeevne. For dig som kunde vejer teamets erfaring som regel tungere end hvilket framework de vælger.
Flutter vs. React Native er et spørgsmål som udviklere gerne debatterer med stor indlevelse. Som kunde har du brug for en mere nøgtern vinkel: Hvad betyder valget egentlig for din app, dit budget og din mulighed for at drive og vedligeholde den? Her er sammenligningen uden religionskrig.
Hvad de to egentlig er
Både Flutter og React Native er frameworks til cross-platform-udvikling. Det betyder at du skriver appen én gang og får versioner til både iOS og Android, i stedet for at bygge to separate native apps. Det sænker normalt både omkostninger og tidsforbrug sammenlignet med at gøre alt to gange.
React Native bygger på JavaScript, det samme sprog som store dele af nettet bruger. Flutter bruger sproget Dart og tegner selv brugerfladen. Begge er modne, velafprøvede og bruges i apps som millioner af mennesker har i lommen. Til langt de fleste forretningsapps rækker hvilket som helst af dem fint.
Adgang til kompetencer og bureauer
Det er den faktor der påvirker dig mest på lang sigt, og den handler ikke om teknik, men om mennesker.
Puljen af udviklere der kan arbejde med React Native, er generelt større. En vigtig årsag er at det bygger på JavaScript, som rigtig mange udviklere allerede behersker fra webudvikling. Flutter vokser støt, men har stadig et noget smallere udbud.
Hvorfor betyder det noget? Fordi en app lever i mange år efter lanceringen. Jo flere udviklere der kan teknologien, jo lettere er det at:
- Bemande projektet fra start.
- Tage flere personer ind når der er brug for det.
- Skifte leverandør hvis samarbejdet ikke fungerer.
- Finde nogen der kan vedligeholde appen om flere år.
Et bredere udbud er ganske enkelt en tryghed. Det gør dig mindre afhængig af en enkelt leverandør.
Udseende, ydeevne og webunderstøttelse på et overordnet niveau
De tekniske forskelle er mindre dramatiske end debatten giver indtryk af, men de findes.
| Aspekt | Kort forskel |
|---|---|
| Udseende | Flutter tegner alt selv og giver stærk kontrol; React Native ligger tæt på platformens komponenter |
| Ydeevne | Begge rækker til de fleste apps; i de mest krævende tilfælde er der marginale forskelle |
| Webunderstøttelse | React Native deler fundament med web; Flutter kan også nå web, men med andre afvejninger |
| Økosystem | Begge har rige biblioteker; React Native nyder godt af JavaScript-verdenens størrelse |
I en almindelig forretningsapp (konti, lister, formularer, notifikationer, betaling) giver begge et resultat som brugeren ikke kan skelne fra hinanden. Forskellene bliver først relevante i mere specielle tilfælde, f.eks. apps med meget tung grafik eller ekstreme krav til ydeevne.
Hvorfor teamet vejer tungere end frameworket
Her er den pointe der er let at overse: Et dygtigt team i det framework de kender bedst, slår næsten altid et middelmådigt team i det “teoretisk rigtige” framework.
En konkret måde at tænke på: Har du fundet et bureau der er rigtig skarpt til React Native, er det sjældent værd at tvinge dem over i Flutter fordi en artikel roste det, eller omvendt. Kvaliteten kommer af erfaringen, ikke af logoet på frameworket.
Det er også sådan vi ræsonnerer når vi anbefaler teknologi: Vi tager udgangspunkt i hvad projektet har brug for og hvad teamet behersker, ikke i hvilket framework der tilfældigvis er mest omtalt lige nu. Vælger du leverandør først og lader dem foreslå et framework ud fra deres styrker, rammer du som regel rigtigt.
Hvad spørgsmålet bør handle om i stedet
Vil du alligevel bruge energi på et valg, så brug den på leverandøren snarere end på frameworket. Et bureau med solid erfaring, klar kommunikation og tilfredse tidligere kunder giver dig et bedre resultat end det “rigtige” framework i hænderne på et team der lige er begyndt at lære det.
En praktisk måde at vende spørgsmålet på: Bed en potentiel leverandør begrunde sit teknologivalg ud fra din app. Et svar der tager udgangspunkt i hvad din app skal kunne og hvad teamet er stærkest til, er et godt tegn. Et svar der mest handler om at et bestemt framework er “bedst” i al almindelighed, er et dårligere tegn.
Så betyder valget noget? Lidt, mest gennem adgangen til kompetencer. Men vælger du et dygtigt team, bliver selve spørgsmålet om framework sjældent afgørende. Vil du vende hvad der passer til din app, er du velkommen til at kontakte os.
Ofte stillede spørgsmål
Hvad er bedst, Flutter eller React Native?
Der findes ikke et generelt bedste valg. Begge bygger apps til iOS og Android fra én kodebase og klarer de fleste forretningsapps godt. Forskellene handler mere om adgangen til kompetencer og om detaljer i udseende og ydeevne end om at den ene skulle være dårligere. Det rigtige valg afhænger af dit team og dit projekt.
Findes der flere React Native- eller Flutter-udviklere?
Puljen af udviklere der kan arbejde med React Native, er generelt større, bl.a. fordi det bygger på JavaScript, som mange allerede kan. Flutter vokser, men har et noget smallere udbud. Flere tilgængelige udviklere gør det nemmere at bemande, skifte leverandør og vedligeholde appen på sigt.
Kan man se forskel på en app bygget i Flutter og en bygget i React Native?
Sjældent som bruger. Begge kan give apps der ser ud og føles som enhver anden moderne app. Flutter tegner selv brugerfladen og får derved stærk kontrol over udseendet. React Native ligger derimod tæt på platformens egne komponenter. I en almindelig forretningsapp mærkes forskellen knap.
Betyder valget af framework noget for prisen?
Marginalt sammenlignet med andre faktorer. Appens omfang, antallet af integrationer og designet påvirker omkostningen langt mere end hvilket af de to frameworks der bruges. Et dygtigt team i det framework de kender bedst, giver som regel både et bedre resultat og en mere forudsigelig omkostning.
Kan vi skifte framework senere?
At skifte framework betyder i praksis at bygge appen om, så det er ikke noget man gør i forbifarten. Derfor er valget værd at overveje fra starten selvom begge alternativer er trygge. Vælger du ud fra teamets kompetencer, mindsker du risikoen for nogensinde at skulle træffe den beslutning.