Overslaan en naar hoofdinhoud gaan

Technologie & Engineering June 17, 2021

React Native versus native: welk framework voor jouw app?

Image

Met de komst van React Native lijkt het efficiënt en goedkoop bouwen en uitrollen van apps over meerdere platformen opeens binnen handbereik. Bedrijven die nieuwe apps willen ontwikkelen bevinden zich nu in een tweesprong: gaan we voor het oude vertrouwde native of de alom geprezen ‘holy grail’ React Native? Het is een vraag die we vaak terugzien bij onze klanten. Helaas verzanden discussies over de keuze tussen het één of het ander vaak in discussies over tijd en geld. Zonde. Voor beide technologieën, of zelfs een combinatie ervan, valt namelijk wat te zeggen. De discussie moet daarom terug naar de kern. Wat voor type app wil je bouwen, wat is de gewenste functionaliteit en wat is het toekomstbeeld? Alleen vanuit dit vertrekpunt is het mogelijk een verstandige, financieel gezonde keuze te maken voor app-ontwikkeling.

(React) Native in het kort

Traditioneel gezien is native de go-to manier voor app-ontwikkeling. Developers bouwen per platform een afzonderlijke app waarbij ze de volledige controle hebben over development en beschikking over alle native features. Van push notificaties tot NFC-scans. Wil je dezelfde app ook op een ander platform laten draaien, dan moet je specifiek voor dat platform een nieuwe native app ontwikkelen. Het is daarom geen geheim dat de gehele app-ontwikkeling industrie constant op zoek is naar manieren om het ontwikkelproces sneller, makkelijker en kostenbesparend te maken.

Het antwoord? React Native, een platform-onafhankelijk framework. Deze relatief nieuwe technologie werkt vanuit één set broncode (JavaScript) die gemakkelijk kan worden gewijzigd en hergebruikt. De ontwikkeling van de User Interface is opgedeeld in componenten waardoor de app optimaal werkt op meerdere platformen. React Native vertaalt de geschreven code als het ware automatisch naar de juiste native taal. Een kostenefficiënt alternatief, maar ook hier zitten beperkingen aan. Het framework weet alle ontwikkelingsmogelijkheden die native te bieden heeft namelijk nooit helemaal te vervangen.

Wat voor type app wil je bouwen?

Zowel native als React Native kennen dus beperkingen. Om een weloverwogen keuze te maken moet je je daarom afvragen wat voor type app je wil bouwen. Een handig onderscheid om daarbij te maken is transactioneel versus experience.

Transactioneel: React Native
Wil je een meer transactionele app zonder al teveel poespas bouwen, dan is het verstandig om voor React Native te gaan. Een voorbeeld is de app die we voor Hogeschool Rotterdam hebben gebouwd, waarin studenten al hun studiegerelateerde zaken kunnen regelen. Dit soort apps vragen om hele functionele opties zoals het kunnen bekijken van studieresultaten en collegeroosters. Door React Native te gebruiken konden onze developers één codebase bouwen die werd gerenderd naar twee platforms: Android en iOS. Het hybride-karakter van React zorgde ervoor dat de app snel en gemakkelijk door onze frontend-developers kon worden ontwikkeld. Er zijn namelijk geen additionele iOS- en Android-developers nodig in het proces. Oftewel: React Native is bij uitstek geschikt om snel zakelijke apps te bouwen die geen ‘spannende’ uitbreidingen behoeven in de toekomst. Eventuele updates zijn met React Native rechtstreeks naar de telefoons van gebruikers te pushen.

 

Image

Experience: full native
Onder experience apps verstaan we apps die volledig inzetten op de ervaring van de gebruiker en het gevoel dat hierbij komt kijken. Het gaat hier namelijk om die eerdergenoemde ‘spannende’ uitbreidingen: native features App Clips, animaties, Augmented Reality, NFC-scans en image recognition. Deze features zijn lastiger te implementeren in React Native zonder allerlei (complexe) trucs toe te passen, zoals het bouwen van custom React Native modules. Een voorbeeld van een volledige native app is de Speelgoedboek app die we voor Bol.com hebben ontwikkeld. Door image recognition in de app kunnen kinderen alles in het Speelgoedboek scannen en digitaal tot leven brengen. Daarnaast bevat de app andere technologische snufjes zoals 8D luisterverhalen, Augmented Reality en Lottie animaties.  

 

Image

Best-of-breed
Hoewel discussies in de industrie en op het web het vaak doen lijken alsof je moet kiezen voor native óf React Native, is niets minder waar. Bij Dept zijn we juist groot voorstander van een best-of-breed aanpak. Zo kun je kiezen voor een full native basis waarop je verschillende componenten bouwt. Per component maak je vervolgens een keuze voor native of React. Wil je bewegend beeld toevoegen aan de app? Dan bouw je deze feature op native. Is er een simpel formulier nodig wat veel tijd kost: dan bouw je deze één keer in React Native en integreer je het vervolgens in zowel iOS als Android. Deze combinatie hebben we ook toegepast voor de app-variant van de urenregistratie portalen van Maandag®. De app is een combinatie van bestaande technieken uit de portalen die zijn ingeladen in de app en verrijkt met extra native-toevoegingen voor een betere ervaring. Denk hierbij bijvoorbeeld aan push-notificaties/herinneringen voor het registreren van de gewerkte uren, maar ook het invoeren van de uren zelf.

Toch nog even over tijd en geld...

Goed, de focus moet dus liggen op de kern. Maar we begrijpen dat bij het maken van een keuze budget en de planning toch een belangrijke rol spelen. Neem dan het volgende in overweging:  

Image

De algemene opvatting is dat React Native sneller, goedkoper en qua ontwikkeling efficiënter is dan native. Maar wanneer we de ontwikkelkosten afzetten tegen de doorontwikkeling en complexiteit, zien we een verschuiving ontstaan tussen de twee. De initiële kosten bij React Native zijn misschien lager, maar op de langere termijn loop je tegen beperkingen aan. Voor de doorontwikkeling heb je bijvoorbeeld native developers nodig voor maatwerk en ontstaan grotere technische uitdagingen. En het oplossen van deze uitdagingen heeft logischerwijs invloed op de kosten en tijd. Conclusie? Aan het einde van de rit ben je misschien evenveel budget kwijt voor beide opties, dus je keuze hierop stoelen is onverstandig. 

Een blik op de toekomst

Tot slot misschien een open deur, maar vergeet niet om keuzes te maken die inspelen op de technologie van morgen. We zetten de belangrijkste ontwikkelingen voor de komende tijd op een rijtje:

  • Native: SwiftUI (iOS) en Jetpack Compose (Android). Dit zijn moderne toolkits om User Interfaces (UI) te ontwikkelen op basis van Declarative UI. Dit komt in de buurt van hoe React Native werkt, maar dan écht native. Naar verwachting zijn beide toolkits in 2022 stabiel genoeg. 
  • Native: Kotlin Multiplatform. Hiermee kan één enkele codebase gebruikt worden voor de business-logica van iOS en Android-applicaties, waardoor je alleen nog platform-specifiek hoeft te schrijven voor de UI. Deze tooling is te combineren met SwiftUI en Jetpack Compose.
  • React Native: Hermes. Dit is een open-source Javascript engine geoptimaliseerd voor React Native. Het toepassen van Hermes zal voor veel apps resulteren in verbeterde opstarttijd, verminderd geheugengebruik en een kleinere app-grootte. 

Het is dus zaak om te kiezen voor (een combinatie van) de juiste app-technologie, je daarbij niet teveel laten afleiden door budget en tijd en in te spelen op toekomstige ontwikkelingen. En of je nu gaat voor native, React Native of een best-of-breed aanpak – bij Dept helpen we je graag op weg!

Vragen? We helpen je graag!

Oeps!

If you're reading this, you unfortunately can't see the form that's supposed to be here. You probably have an ad blocker installed. Please switch off your adblocker in order to see this form.

Still encountering problems? Open this page in a different browser or get in touch with us: [email protected]