Hvilke kode- og forretningsmæssige fordele er der ved React Native? Og performer det godt nok sammenlignet med Native? Det var nogle af de spørgsmål, jeg forsøgte at besvare, da jeg for noget tid siden holdte oplæg om React Native. Et par af pointerne herfra vil jeg nu dele med dig her.

Men først en kort introduktion til hvad React Native er til de læsere, som ikke kunne være der til oplægget. Det er en udviklingsplatform til cross-platform mobiludvikling, udgivet og vedligeholdt af Facebook. Det er baseret på den interne Javascript virtual machine på telefonen, som ved hjælp af React genererer native UI widgets på runtime. Det betyder, at man med frameworket kan bygge apps i ren Javascript, som nu både ser ud som og føles som en native app, i modsætning til tidligere forsøg på hybrid-apps, som i stedet blev afviklet i en “webbrowser”.

Så er det selvfølgelig også værd at bemærke, at nogle af de større spillere på markedet allerede, i varierende grad, har taget React Native til sig. Herunder selvfølgelig Facebook selv, men også andre store tech virksomheder som Instagram, Skype, Tesla, AirBnB, Wix, Walmart og mange flere. Det faktum alene, at så store tech virksomheder med så store brugerplatforme har taget teknologien til sig, er for mig at se rigeligt testamente for platformens stabilitet, performance og fremtidsudsigter, da det som bekendt er en dyr investering at udskifte frameworks.

Jeg anbefaler interesserede at læse nogle af de blogindlæg, der ligger fra virksomhederne på https://facebook.github.io/react-native/showcase.html . Specifikt anbefaler jeg blog-serien fra Artsy, da det giver indblik både i udviklingsflowet samt den positive påvirkning på deres team og samarbejde.

Derfor er jeg fan!

Jeg er, som de deltagende til oplægget nok lagde mærke til, en fan af React Native, og jeg ser mange fordele ved det sammenlignet med andre cross-platform løsninger, og endda også ift. ren native udvikling. Jeg ser dog særligt to fordele som værende af større betydning end de andre, både for udviklere og forretningsansvarlige.

2 vigtige fordele ved React Native

Den første fordel er, at jeg i ovenstående beskrivelse om de større spilleres optagelse af frameworket skrev ordene “i varierende grad”, for det er kun React Native, der giver muligheden for at integrere frameworkets kode med native moduler, og dermed eksisterende apps, uden at skulle afvikles i en webbrowser. Muligheden for både at kunne integrere ny React Native kode i eksisterende apps, eller at bruge ældre native kode moduler i en ny React Native app er en af de absolut største fordele ved React Native, og et faktum som bør give (potentielle) brugere af frameworket en god følelse i maven. Man ved derfor altid, at det værste der kan ske er, at man implementerer en funktion natively, som man ellers ville have gjort det. På den måde er “lock-in” i frameworket meget mere begrænset og tilgivende end i andre frameworks, hvor man risikerer at have “kodet sig op i et hjørne”, hvis man møder nogle user requirements som den valgte platform af en eller anden grund ikke understøtter.

Den anden fordel er, at man kan opdatere sin React Native kode gennem OTA updates udenom app store reviews. Det giver en fantastisk følelse af fleksibilitet og sikkerhed, og tillader principielt et “continuous delivery” setup for sine mobilapps, hvilket før har været stoppet af “review-muren”.

Men hvad med sikkerheden?

Til mit oplæg i København blev der gjort den skarpe observation, at dette kunne være et muligt sikkerhedshul for brugeren - både for, at udviklerne kan levere kode igennem en OTA update, som gør noget uhensigtsmæssigt og ved, at man som tredje part måske kunne opfange forespørgslen på OTA updates og levere en falsk bundle til telefonen.

Her diskuterede vi, at man i førstnævnte tilfælde som bruger må stole på leverandøren af appen, og at dette også er tilfældet hver gang man opdaterer apps på normal vis. I sidstnævnte tilfælde talte vi om, at de OTA services jeg nævnte (Expo og CodePush) sandsynligvis har en signing proces indbygget, men at det kunne være interessant at undersøge. Jeg har i den forbindelse haft fat i Expo teamet, og de har rigtig nok en signing med public/private keys af manifestet til deres bundles, som er hostet over TLS på Amazons S3 servere. Hvis man er mere interesseret, kan man læse yderligere her https://forums.expo.io/t/ota-updates-security/5050.

Det åbner dog for et nyt sikkerhedshul, da Expo eller Microsoft så kunne levere skadelig kode, enten med vilje eller hvis de selv har været åbne for et angreb, så der skal man som udvikler/forretning enten stole på dem som leverandør, eller selv håndtere sine OTA updates og bundle signing, hvis man vil have fuld kontrol. Det er den evige kamp i mellem sikkerhed og nemhed.

(Great) work in progress

Med alt det sagt, så skal man selvfølgelig aldrig blive smittet af “silver bullet syndromet”, og React Native er ikke uden sine fejl og mangler. I min optik er den største svaghed stadig den relative unge alder, hvilket naturligt leder til et mere eksperimenterende miljø i forbindelse med værktøjer og hjælpebiblioteker. Ligeledes har React Native et mindre erfarent community, hvor alle gør deres bedste for at hjælpe hinanden, men de fleste har også forholdsvist begrænset erfaring. Det bliver naturligvis bedre dag for dag, og frameworket selv bliver aktivt videreudviklet af både Facebook, andre store spillere (bl.a. AirBnB og Wix er især aktive i React Native open source communitiet med både omfattende biblioteker og features), og selvfølgelig communitiet selv.

På trods af sine svagheder, så anbefaler jeg alle, der har med appudvikling at gøre, at se nærmere på React Native, og måske selv prøve at implementere en lille app, eller en lille feature i “hjørnet” af en eksisterende app, inden man afskriver muligheden. Hvis man har mod på at overkomme den indlæringskurve, der følger med, så er der en gevinst at hente på den anden side - både for udviklerne og forretningen.