React Native-udvikling bliver som regel valgt for at spare tid: én kodebase i stedet for to, ét team i stedet for to. Det holder i praksis, men ikke helt så rent som det bliver solgt. Her er, hvad delingen reelt dækker, hvor den holder op, og hvordan I afgør om det er det rigtige valg til netop jeres app.
Hovedpointer
- Regn med at dele 70-90 % af koden. De sidste procenter er ofte dem, der tager tid.
- React Native passer bedst til apps, hvor indholdet og forretningslogikken fylder mest — ikke grafik og hardware.
- Vælg native, når appen lever af kamera, baggrundsopgaver, Bluetooth eller tunge animationer.
- Besparelsen ligger i vedligeholdelse over år, ikke i den første version.
- I har stadig brug for nogen, der forstår både iOS og Android. Kodebasen er delt, platformene er ikke.
- Start med at afklare de tre sværeste skærme, ikke de nemme.
Hvornår er React Native-udvikling det rigtige valg?
Der er et tydeligt mønster i de projekter, hvor det fungerer. Appen viser og redigerer data fra jeres systemer. Den har mange skærme, men få af dem er visuelt usædvanlige. Forretningslogikken er den samme på begge platforme, og I vil have nye funktioner ud til begge på samme dag.
Det dækker langt de fleste apps til kunder, medarbejdere og partnere: booking, selvbetjening, ordrer, rapportering, interne værktøjer. Det er også dér, besparelsen er størst, fordi hver ny funktion ellers skulle bygges og testes to gange.
Hvornår I bør vælge native i stedet
Fire ting gør native til det rigtige valg, selv når det koster mere.
- Hardware. Avanceret kamerabrug, Bluetooth-enheder, NFC eller sensorer, hvor timingen betyder noget.
- Baggrundsarbejde. Apps der skal gøre noget, mens de er lukkede — løbende positionering, synkronisering, lydafspilning.
- Grafik og animation. Spil, redigeringsværktøjer, alt hvor billedopdateringen skal være jævn under belastning.
- Platformens nyeste funktioner. Hvis I skal bruge noget, Apple eller Google lancerede i denne måned, kommer understøttelsen i React Native senere.
Er I i tvivl, er spørgsmålet ikke “kan React Native det?” — det kan næsten alt med et native modul. Spørgsmålet er, hvor meget af appen der ender med at være native alligevel. Bliver svaret en stor del, har I to kodebaser med ekstra kompleksitet i stedet for én.
Hvad deling af kode betyder i praksis
Forretningslogik, netværkskald, datamodeller, state og størstedelen af brugerfladen deles. Det er den del, der fylder mest i en almindelig app, og derfor holder løftet om én kodebase i grove træk.
Det, der ikke deles, er push-notifikationer, dybe links, betalinger, filhåndtering, rettigheder og alt hvad der rører ved systemets egne dialoger. Hver af dem kræver opsætning på begge platforme og test på begge platforme. De er ikke svære, men de er der, og de bliver typisk glemt i estimatet.
De steder, hvor React Native koster ekstra
Native moduler
Har appen brug for noget, der ikke findes som færdig pakke, skal nogen skrive det i Swift og Kotlin. Det er almindeligt arbejde, men det kræver folk med netop de kompetencer — og det er værd at afklare, før I vælger teknologi.
Opdateringer
React Native udvikler sig hurtigt, og pakker, I bruger, følger ikke altid med. Læg tid ind til opgraderinger mindst én gang om året. Springer I det over i tre år, bliver den fjerde opgradering et projekt i sig selv.
Ydeevne i lange lister
Lange lister med billeder og komplekse elementer er det klassiske sted, hvor en React Native-app føles langsommere end en native. Det kan løses, men det kræver, at nogen ved hvordan, og at det testes på en billig Android-telefon — ikke kun på en ny iPhone.
Hvad I sparer
Den første version bliver sjældent halvt så dyr som to native apps. Regn med 60-75 % af prisen, fordi opsætning, test og udgivelse stadig skal ske to steder.
Besparelsen kommer bagefter. Hver ny funktion bygges én gang. Hver fejlrettelse rettes ét sted. Over to-tre år med løbende udvikling er det dér, forskellen bliver tydelig — og det er også dér, valget skal begrundes.
Sådan starter I fornuftigt
Vælg de tre sværeste skærme i appen og byg dem først. Ikke login og en liste, men det, I er mest i tvivl om. Test på den ældste telefon, jeres brugere realistisk har. Beslut derefter.
Det er den samme tilgang, vi bruger i en MVP-udvikling: afklar det usikre først, mens det stadig er billigt at skifte retning. Skal appen bygges og driftes over tid, sætter vi typisk et dedikeret udviklingsteam på den, så viden bliver i teamet.
Har I brug for folk med netop denne erfaring, kan I hyre React Native-udviklere hos os, eller se bredere på vores mobiludviklingstjenester og mobiludviklere, hvis I endnu ikke har valgt teknologi.
Ofte stillede spørgsmål
Sjældent, hvis den er bygget ordentligt. Det, brugerne mærker, er lange lister der hakker, og overgange der ikke er jævne. Begge dele kan løses, men de skal testes på almindelige telefoner og ikke kun på udviklerens egen.
Ikke direkte. Forretningslogik og datalag kan ofte deles med en webapp, men brugerfladen skal bygges særskilt. Regn ikke med tre platforme til prisen for én.
Flutter løser samme problem og gør det godt. Det afgørende er som regel, hvad jeres team og jeres marked kan bemande. Har I allerede React-udviklere, er React Native den korteste vej.
En app med login, integration til ét system og ti til femten skærme lander typisk på tre til fem måneder inklusive test og udgivelse. Integrationer til ældre systemer er den faktor, der oftest flytter tidsplanen.
Hvad vi ville gøre
React Native passer, når appen handler om data og forretningslogik frem for hardware og grafik. Besparelsen ligger i årene efter lanceringen, ikke i den første version. Byg de sværeste skærme først, test på gammel hardware, og beslut på det.
Skal vi kigge på jeres app? Skriv til os eller book et møde, så giver vi en ærlig vurdering af, om React Native er det rigtige valg.
