Een alternatief voor èchte native apps?
Wat betekent dit voor jou als klant of ontwikkelaar? Onze wizards zochten het uit
In de ICT sector gaan de ontwikkelingen hard en om voorop te blijven moet je deze ontwikkelen blijven volgen.
Bij Sping zijn we gaan experimenteren met een nieuwe manier van mobiele apps bouwen.
De huidige manieren om een mobiele app te bouwen zijn als volgt onderverdeeld:
Webapplicatie
Een applicatie die responsive is en op mobiele apparaten geoptimaliseerd is. Distributiekanaal is het internet en er hoeft geen rekening gehouden te worden met de App store of Google Play.
Native applicatie
De native applicaties die specifiek geschreven zijn voor een platform zoals iOS of Android. Hiervoor is kennis nodig van beide platformen en zal ook de ontwikkeltijd toenemen omdat je geen code kan hergebruiken.
Hybrid of cross platform app
Hybride applicaties waren er toen al in twee categorieën. De eerste werkt via een native wrapper met een WebView (een ander type browser) waarin de webapplicatie staat. Voorbeelden hiervan zijn Cordova en Phone Gap. De tweede waren frameworks zoals Titanium Mobile waarbij via javascript native user interfaces gemaakt konden worden.
Nieuw cross platform framework
Facebook heeft een cross platform framework gebouwd genaamd react-native. Deze is sinds 2015 al beschikbaar, maar krijgt de laatste tijd steeds meer aandacht.
React native valt ook in de categorie van cross platform apps die door middel van JavaScript het mogelijk maken om een native ervaring te realiseren. React-native maakt gebruik van een native user interface, waarbij de logica door JavaScript geregeld word.
React-native wordt gebruikt door een aantal grote apps
De blogpost is hierna opgesplitst in “Voor klanten” en “Voor developers”. Als (potentiële) klant kan je direct doorlezen. Als developer kan je meer lezen in het onderdeel Voor developers
Voor klanten
In de volgende hoofdstukken word React-native vergeleken met de bestaande methodes webviews en native.
React-native vs webviews
+ Snelheid van de app
React-native gebruikt native onderdelen die veel meer geoptimaliseerd zijn voor snelheid dan views in een WebView. De snelheid waarmee de WebView applicaties uitgevoerd wordt is wel verbeterd in de loop der tijd, maar haalt het nog steeds niet bij native layouts. Omdat React-native juist de layout native heeft gemaakt is de snelheid een stuk beter dan van een WebView.
+ Herkenning van design patronen
Gebruikers zijn gewend aan de structuur van Android of iOS. Bepaalde knoppen zitten op een bepaalde plek en de navigatie moet op dezelfde plek te vinden zijn. Als een applicatie de design guidelines volgt dan herkent de gebruiker de patronen en snapt intuïtief hoe de applicatie gestructureerd is.
Een voorbeeld wat erg afwijkt is bijvoorbeeld de navigatie. Links Android en rechts iOS:
Meer informatie over design patronen op tutsplus (EN)
Bij webview applicaties wordt meestal één design gemaakt die hetzelfde is voor Android en iOS. Dit betekend dat de gebruikers sommige patronen minder snel herkent en het minder intuïtief aanvoelt.
React-native is zo gebouwd dat de logica wel eenmalig geschreven kan worden, maar dat de design patronen wel kunnen verschillen. Dit maakt het makkelijker om voor Android en iOS twee verschillende designs te implementeren.
+/- Iets langere ontwikkelingstijd
Om een goede ervaring te hebben en WebViews echt aan te laten voelen als een app moet er aardig wat werk in de applicatie gestoken worden. Het ontwikkelen met React-native voelt net zo aan als het maken van een webapplicatie met als voordeel dat het voor de gebruiker aanvoelt als een native app.
Wij schatten in dat de ontwikkeltijd die nodig is voor een react-native applicatie iets hoger ligt dan bij WebViews. Dit heeft vooral te maken met het implementeren van platform specifieke design. Als het gewenst is dat een app hele specifieke branding moeten krijgen, kan dit nog meer tijd in beslag nemen. Standaard componenten van react-native zijn niet altijd zo flexibel dat ze voor alle designs ingezet kunnen worden. Bij WebViews is dit makkelijker omdat het uiterlijk daarvan flexibeler is.
React-native vs native
+ Ontwikkeling gaat sneller via React-native
Bij Native applicaties moet voor zowel Android als iOS het design en de functionaliteit apart gerealiseerd worden. Dit betekend dat er meer tijd in gaat zitten om voor beide platformen apps te realiseren. Met react-native wordt eenmaal de logica geprogrammeerd en is het mogelijk om per platform een design te implementeren. Door deze opbouw worden kosten bespaard en gaat het realiseren een stuk sneller.
+/- Snelheid van de app is vrijwel even goed
React-native gebruikt voor het design native elementen, waardoor de performance heel erg goed aan kan voelen. Het is echter belangrijk dat de layout componenten die niet standaard in react-native zitten goed worden uitgetest voordat ze gebruikt worden. Sommige componenten zijn namelijk niet goed geoptimaliseerd, waardoor ze een slechtere performance hebben. Lees meer over performance van react-native (EN).
– Integreren van diensten van derden kan meer tijd kosten
De applicaties die Sping schrijft vereisen altijd integratie met derde partijen. Dit kan zijn omdat de applicatie bijvoorbeeld push berichten, augmented reality of andere technologie nodig heeft om functionaliteit van de applicatie te realiseren.
Voor veel van deze integraties is goede documentatie over hoe de native integratie moet lopen. Echter voor react-native is dit niet het geval, waardoor de developer genoodzaakt is om meer research te doen om de integratie te laten slagen. Al worden deze ontbrekende integraties met razend tempo uitgebracht de laatste tijd.
Voor developers
React-native vs webviews
+ Fijner om aan te werken door betere kwaliteit
De Sping developers zijn overtuigd dat webviews een minder goede gebruikservaring geeft dan een applicatie gebouwd met react-native. Dit heeft vooral te maken met de verwachtingen van de gebruiker en de performance. De code in een WebView moet altijd eerst door de JavaScript en dom renderer. Sping wilt kwaliteit leveren en we worden enthousiast van als we met een framework werken waarvan we vinden dat het kwaliteit levert. Daarom hebben we de voorkeur voor react-native boven webviews.
+ Makkelijker om specifieke functies te maken voor Android en iOS
Bij webviews is het uitgangspunt om te bepalen of het Android of iOS is de user agent die meegeven wordt door de webbrowser. Deze user agent kan anders zijn per versie, waardoor er andere regex toegepast moet worden. Zo heeft de webview van Android voor 4.4 allerlei verschillende user agents en heeft iOS op dit moment voor elk product een andere user agent (iPhone, iPod, iPad). Als hier nieuwe producten bijkomen zou de regex aangepast moeten worden. Aan de hand van de regex kan er een css class op de layout komen, waarop de css voor Android en iOS afwijkend kan zijn.
Bij React-native zijn het *.ios.js en *.android.js bestanden waarin de layout geïmplementeerd kan worden. De layouts zijn dus zeer gescheiden en kunnen onafhankelijk van elkaar gemaakt worden.
+ Minder layout issues
Webviews kunnen nog wel eens verschillen van elkaar. Android heeft bijvoorbeeld voor versie 4.4 de “Android WebView”, waarbij fabrikanten zelf ook nog wel eens functionaliteit in de WebView wijzigde. Dit betekent dat bij een Samsung met Android 4.3 de layout of functionaliteit anders is dan op een Google Nexus 4.3. Bij iOS was voor versie 8 ook een probleem dat de WebView niet hetzelfde was als Safari. Hierdoor was er minder functionaliteit voor de applicatie beschikbaar.
Na Android 4.4 heeft Google de Chromium browser geïntroduceerd als webview (Chrome is ook gebaseerd op Chromium). Deze update net als een normale app regelmatig via de play store. iOS heeft met versie 8 een andere WebView geïntroduceerd, dit is de WKWebView in plaats van de UIWebview. Deze heeft dezelfde functionaliteit als Safari Mobile en worden beide geupdate met een iOS release.
+/- Debuggen
Een deel van de werkzaamheden als developer wordt besteed aan het debuggen. Vandaar dat dit onderdeel ook belangrijk is voor de developers.
Inspecteren layout
Met webviews is het makkelijk om de code te inspecteren. Android en iOS webviews kan je inspecteren door de telefoon aan te sluiten op de computer en met Chrome of Safari te verbinden. Dit maakt het erg makkelijk om layout problemen te onderzoeken en te fixen.
Bij React-native is dit niet zo makkelijk omdat de layout elementen echt native zijn. Onderzoeken hoe de layout geprogrammeerd is en daarop wijzigingen maken is dan een optie om de problemen te onderzoeken.
Hot reloading
Om tijdens het ontwikkelen veranderingen direct te zien in de applicatie moet de developer zelf de applicatie verversen. Met hot reloading worden de componenten die aangepast zijn vervangen voor de componenten die aangepast zijn. Met WebView is dit ook mogelijk maar zorgt er wel voor dat de webapplicatie tijdens het ontwikkelproces niet opgeslagen is in de native wrapper. Als er met een release de build code uiteindelijk toch in de native wrapper opgeslagen moet worden kan dit voor fouten zorgen. Daarom is het een risico om met WebViews die opgeslagen moeten worden in de native wrapper hot reloading toe te passen.
Bij React-native is hot reloading standaard aanwezig en hoeft het alleen maar aangezet te worden. Als er iets verandert dan zal alleen het desbetreffende onderdeel geüpdatet worden. Dit heeft geen consequenties voor de uiteindelijke productie release.
Tot slot
De developers bij Sping vonden het super om React-native uit te zoeken. De bevindingen die nu gedaan zijn kunnen we als advies meenemen in de projecten die we realiseren.
Een grove verdeling van wanneer je React-native toe zou passen en wanneer niet:
Is het budget erg krap maar toch behoefte aan een app ?
Ga voor react-native in plaats van WebViews. De logica implementeren hoeft maar één keer gedaan te worden en de layout kan verschillen voor Android en iOS. Daarnaast geeft het een betere gebruikservaring.
Maakt de app gebruik van een grote technologische laag?
Als de applicatie gebruik maakt van libraries van derde of een vrij ingewikkelde laag kan het verstandig zijn om deze niet in react-native te maken.
In de meeste gevallen is het dan beter om voor een echt Native applicatie te gaan, waarbij de integratie makkelijker is.
Is er budget om een gebruiksvriendelijke applicatie te maken?
Als er budget is om extra waarde toe te voegen aan de applicatie door middel van gebruiksvriendelijkheid, is het verstandig om voor Native te gaan.
Dit is de beste optie als er budget is om het te realiseren. De snelheid en de patronen van platform specifieke design elementen wegen mee in het beoordelen van een applicatie.