Apputvikling

Kom i gang med React Native: hva et prosjekt krever

Hva som skal på plass før utviklingen starter, hvordan et React Native-prosjekt er satt opp, og hva som kreves for å holde appen i live etterpå.

· Oppdatert

Mobil koblet til en laptop med USB-C-kabel for testing av en ny app

Denne artikkelen handler om det praktiske ved å starte og drifte et React Native-prosjekt. Vurderer du fortsatt om React Native er riktig valg, er apputvikling med React Native et bedre sted å begynne.

Det som må på plass før utviklingen starter

En del av arbeidet i starten er administrativt, og det har en tendens til å bli undervurdert.

Dere trenger utviklerkontoer hos både Apple og Google. Apples koster penger årlig og krever verifisering av organisasjonen, noe som kan ta tid hvis firmaopplysningene ikke stemmer overens. Googles er en engangsavgift. Begge bør opprettes i navnet til bedriften, ikke til en ansatt, for ellers får dere et problem den dagen vedkommende slutter.

Dere trenger også å avklare hvor koden skal ligge og hvem som skal ha tilgang. Dette er selvsagt når dere leser det og glemmes overraskende ofte.

Og skal appen bruke BankID, Vipps eller koble seg mot et eksisterende fagsystem, start de prosessene med én gang. Ventetiden på avtaler og testtilganger er ikke noe utviklerne kan påvirke, og den har veltet flere tidsplaner enn tekniske problemer.

Hvordan prosjektet er satt opp

Et React Native-prosjekt består av én kodebase som bygges til to apper. Det meste av koden er felles, men det finnes egne mapper for det som er spesifikt for hver plattform.

Vi bruker Expo i de fleste prosjekter. Det tar seg av mye av oppsettet rundt bygging, testing på ekte enheter og distribusjon av testversjoner, og sparer en betydelig mengde arbeid som ellers måtte gjøres manuelt for hver plattform. Når et prosjekt trenger noe Expo ikke dekker, kan man fortsatt legge til native kode for akkurat den delen.

Under utviklingen får dere testversjoner på telefonen deres underveis, slik at dere kan prøve appen på ekte utstyr framfor å se skjermbilder. Det er den raskeste måten å oppdage at noe ikke føles riktig.

Hva dere merker underveis

Det praktiske dere trenger å gjøre som kunde er mindre enn folk tror, men det er ikke ingenting.

Dere må kunne svare på spørsmål raskt. Ventetid på avklaringer er den vanligste enkeltårsaken til forsinkelse i prosjekter, og det gjelder uansett teknologi.

Dere bør teste underveis, gjerne med de samme folkene som faktisk skal bruke appen. En testversjon annenhver uke er et rimelig utgangspunkt.

Og dere må ta stilling til hva appen skal hete i butikkene, hvilke skjermbilder som skal vises, og hva beskrivelsen skal si. Dette høres trivielt ut og tar alltid lengre tid enn planlagt.

Lansering

Appen sendes inn til begge butikkene. Google slipper som regel gjennom raskt. Apple gjennomgår hver innsending manuelt, og selv om det ofte går på et par dager, kan en avvisning koste en uke.

De to vanligste grunnene til avvisning er mangelfull informasjon om hvilke data appen samler inn, og at Apple ikke får testet funksjonalitet som ligger bak innlogging. Det siste løses ved å sende med en demokonto. Begge er enkle å unngå når man vet om dem.

Å holde appen i live etterpå

Dette er den delen som ikke er synlig i budsjettet, men som avgjør om appen finnes om tre år.

Apple og Google gir ut nye versjoner av operativsystemene hvert år, og begge krever jevnlig at apper bygges mot nyere versjoner for å bli værende i butikkene. React Native og bibliotekene appen bruker oppdateres også, og en app som ikke følger med, blir tyngre å oppdatere jo lenger man venter.

Rådet vårt er å oppdatere jevnlig i små steg framfor å ta et stort hopp annethvert år. Det er både rimeligere og mindre risikabelt.

Regn med 10 til 20 prosent av utviklingskostnaden årlig til dette, pluss det som koster å drifte serverne. Vi har skrevet mer om kostnadsbildet i hva koster det å lage en app i Norge.

Et råd om tredjepartspakker

Det finnes en ferdig pakke for nesten alt, og det er fristende å bruke dem. Hver pakke er samtidig noe som vedlikeholdes av noen andre, og som kan slutte å bli vedlikeholdt.

Vi holder listen kort med vilje og velger pakker som er godt etablerte. Det er verdt å spørre hvem som helst dere jobber med om hvordan de tenker rundt dette, fordi en app med femti avhengigheter er merkbart dyrere å holde i live enn en med ti.

Vil du diskutere et prosjekt? Se hvordan vi jobber med apputvikling, regn på omfanget i priskalkulatoren, eller ta kontakt.