Onze Inzichten

Blogs

Mobile app development: kies de juiste tool voor de job

Hans van der Gragt
Hans van der Gragt
2 mrt 2023 - 8 min read

Apps bouwen is inherent aan veel keuzes moeten maken. Zo moet je als eerst kiezen voor een platform waarop je de app bouwt. Ga je voor native ontwikkeling? Hybride technologie? Of kies je toch liever voor een mobiele website? Er zijn geen goede of foute antwoorden, want het is compleet afhankelijk van welk probleem de app oplost. En van de gewenste specificaties en vereisten natuurlijk!  

In deze blog bespreken we de belangrijkste verschillen tussen vier verschillende mobiele frameworks & technologieën die we vaak adviseren bij Triple: native iOS & Android, Flutter, React Native en progressive web apps.

1. Native iOS en Android

Naadloze user experience en hergebruik van SDK's & frameworks

Native app-ontwikkeling is het ontwikkelen van mobiele toepassingen met code en tools voor een geselecteerd platform. Met native app-ontwikkeling voor iOS en Android profiteren bedrijven van platformspecifieke functies van Apple en Google. Zo bieden zij klanten een naadloze gebruikerservaring.

Voor iOS-ontwikkeling gebruik je Xcode om apps in Swift te schrijven. Xcode bevat ondersteuning voor alle native iOS SDK's. iPhone, iPad, Apple TV en Apple Watch delen dezelfde set SDK's en frameworks. Programmeercode kun je tussen apparaten onderling hergebruiken.

Voor Android-ontwikkeling biedt Android Studio ondersteuning voor alle native Android SDK's en schrijf je apps in Kotlin. Android telefoons & tablet, Android TV en WearOS delen ook dezelfde set SDK's. Net als bij iOS hergebruik je moeiteloos code tussen de verschillende Android apparaten. En beide SDK's bieden een specifieke set UI-componenten en interacties die voor de gebruiker herkenbaar zijn. Richt jij je op een ander OS, denk aan iPhone vs. WatchOS of Android-smartphone vs. Android TV, dan heb je te maken met andere UI-componenten.

Meer controle, diepgaande framerate-optimalisatie en kortere time-to-market

Door het gebruik van native ontwikkelomgevingen, hebben ontwikkelaars meer controle over CPU, geheugen, netwerk en batterijgebruik. Beide platformen bieden tools om de framerate in depth te optimaliseren, zodat zelfs complexe interfaces en animaties 60 frames per seconde halen. Ook op de oudere toestellen! In het algemeen zijn de ontwikkelingskosten per functie hoger dan bij hybride ontwikkeling. Dit komt doordat twee afzonderlijke ontwikkelomgevingen dubbele kosten meebrengen.

Toegang tot kernfunctionaliteiten van apparaten, zoals locatie, Bluetooth en OpenGL drawing, zijn direct beschikbaar met de frameworks die Apple en Google bieden. Beide omgevingen geven ook directe toegang tot nieuwe functionaliteiten, zoals integratie met spraakassistenten of Augmented Reality. De mogelijkheid om deze technologieën direct te gebruiken, zonder afhankelijkheid van hybride ontwikkelingswrappers, verkort de time-to-market.

Updates altijd in de hand en flexibeler app-onderhoud

Enkele maanden na een iOS OS-release dwingt Apple het gebruik van de nieuwste Swift-versie af bij het indienen van updates in de App Store. Hierdoor moeten ontwikkelaars de app updaten met de nieuwste API’s, zodat deze op nieuwe apparaten werkt. Ontwikkelaars hebben meer controle over het uitvoeren van updates naar de nieuwste Swift-versie, zonder afhankelijkheid van een hybride ontwikkeling.

Google hanteert een lagere updatefrequentie, hoewel ook zij het gebruik van een minimale API-versie afdwingen bij het indienen bij de Play Store. Over het algemeen is de inspanning voor 'app-onderhoud' bij gebruik van native ontwikkeling laag. Apple en Google bieden tools om code te upgraden om compatibel te zijn met nieuwe SDK's. Wijzigingen in de gebruikersinterface die nodig zijn voor nieuwe vormfactoren, zoals de inkeping van de iPhone X of nieuwe opvouwbare apparaten, zijn eenvoudig oplosbaar. De time-to-market is hierdoor veel korter.

2. Flutter

Gebruiksgemak, snelle test- en ontwikkelcyclus en lagere kosten per functie

Flutter is een open-source framework voor de ontwikkeling van mobiele apps; ontwikkeld door Google. Ontwikkelaars kunnen zo met een enkele codebase hoogwaardige, native mobiele apps voor Android en iOS bouwen. Het framework gebruikt een reactief programmeermodel, en biedt een uitgebreide set vooraf gebouwde widgets, die een snelle en eenvoudige app-ontwikkeling mogelijk maken. Het is steeds populairder door zijn gebruiksgemak, snelle ontwikkelcyclus en cross-platform mogelijkheden.

Flutter-apps maak je in Dart en worden ondersteund door verschillende IDE's, waaronder Android Studio. Flutter tekent rechtstreeks naar het GL-canvas en presteert hierdoor uitzonderlijk goed. Integraties met kern-API's van mobiele besturingssystemen worden apart gedaan, via wrappers. Deze wrappers codeer je in Xcode met Swift en Android Studio met Kotlin. Flutter en de native host van het platform, delen een kanaal om verzoeken en antwoorden te communiceren. Native UI-componenten voor Android en iOS verschillen in gedrag en functionaliteit. Deze verschillen zijn te overbruggen door Flutter, Material en Cupertino widgets te implementeren binnen de kern van de SDK. De meeste moderne apps gebruiken een ontwerp dat identiek is op zowel iOS als Android. Daarom hoeven widgets vaak niet te worden aangepast aan de specificaties van het platform.

Flutter is developer-friendly, het heeft een hot reloadfunctie die snelle iteratie en testen binnen een paar seconden mogelijk maakt. De ontwikkelcyclus is hierdoor sneller dan de volledige cyclus van een native build. Dit is echter alleen beschikbaar voor UI-componenten en niet voor andere functionaliteiten. In het algemeen zijn de ontwikkelingskosten per functie, zonder kernfunctionaliteit van het apparaat, lager zijn dan bij native ontwikkeling. Dit is te danken aan de hybride ontwikkelomgeving.

Integraties via native wrappers of via open source

Toegang tot kernfuncties van toestellen, zoals locatie en Bluetooth, is beschikbaar via de native wrappers. Sommige integraties, zijn direct mogelijk met Flutter zonder gebruik te maken van een wrapper. Denk hierbij bijvoorbeeld aan de camera. De meeste functionaliteiten zijn al beschikbaar als opensource-modules, waarvan het Flutter team al een paar heeft gebouwd. Het gebruik van opensource-modules kan de ontwikkeling versnellen. Ervaring leert dat de beschikbare native modules genoeg zijn voor de basisfunctionaliteiten. Voor toepassingen die diepere integraties vereisen, of nieuwe functionaliteiten van Apple & Google, is vaak maatwerk van deze modules nodig. Integratie met diensten van Firebase (eigendom van Google) worden out of the box geleverd. Firebase is onze voorkeursoplossing voor mobiele analytics. Het schrijven of aanpassen van een native module voor iOS & Android, en deze blootstellen via een wrapper, is mogelijk. Het vraagt wel om meer inspanningen van de developer in vergelijking met het direct integreren van de functionaliteit in een native app.

Eenvoudige conversie naar JavaScript

Google heeft Flutter-apps met Hummingbird beschikbaar gesteld voor het web. Dit is een web-based implementatie van de Flutter runtime. Met Hummingbird is het mogelijk om Dart-code te verzamelen in JavaScript, zonder enige wijziging in de code aan te brengen. Wanneer de Dart-code is gecompileerd naar JavaScript, kun je de applicatie gebruiken op web en desktop. De ondersteunde platforms zijn Windows, MacOS en Linux. Er is geen officiële ondersteuning voor TV. Dit kun je vast laten werken, maar we raden het niet aan.

Bijwerken van, en werken met, groot aantal OS-versies is tijdrovend

De onderhoudseisen, beschreven onder Native iOS & Android, zijn hetzelfde voor Flutter apps. Omdat Flutter is gebouwd bovenop de iOS & Android SDK, is er een vertraging in het updaten. Flutter moet namelijk worden bijgewerkt naar de nieuwe SDK's, voordat de app zelf kan worden bijgewerkt. Het toepassen van nieuwe apparaatformats, vereist extra werk voor aangepaste componenten. Flutter moet ook zijn Material en Cupertino widgets bijwerken om te voldoen aan de nieuwste standaarden. En dat kan best een tijdje duren. Apple en Google bieden via Beta-programma's early bird toegang tot de nieuwe SDK functies. Dit zou Flutter genoeg tijd moeten geven om de veranderingen te implementeren, voordat ze beschikbaar zijn voor het publiek. Flutter tekent rechtstreeks naar het GL canvas en heeft een eigen implementatie van de widgets. Hierdoor werkt het op een groot aantal OS-versies.

3. React Native

Platformdifferentiatie en kennis van verschillende programmeertalen vereist

React Native is als opensource-oplossing gebouwd voor intern gebruik door Facebook. Het heeft een fundering van iOS & Android SDK's. De ontwikkeling vereist meerdere ontwikkelomgevingen. En de gebruikersinterface en backend-communicatie bouw je meestal met JavaScript. Integraties met de API's van de belangrijkste mobiele besturingssystemen, maak je afzonderlijk met native code. Deze onderwerp je aan de JavaScript-omgeving met bridges, of JSI wanneer New Architecture is ingeschakeld. De bridges worden geschreven in Xcode met ObjC (Swift in toekomstige versies) en in Android Studio met Java of Kotlin. De richtlijnen voor de gebruikersinterface op iOS en Android verschillen. Dit betekent dat differentiatie voor platformspecifiek ontwerp en gedrag vaak nog steeds nodig is, ook al kan de gebruikersinterface voor beide platforms in één taal worden geschreven. De oplossing heeft hot reloading beschikbaar, voor een betere ontwikkelaarservaring.

React Native biedt een basisset van gedeelde UI-componenten, maar voor sommige details is extra maatwerk nodig. React Native biedt platformspecifieke API's om code te schrijven voor elk platform. Ontwikkelaars die aan de mobiele app werken, moeten voldoende kennis van beide platformen hebben, omdat native modules vaak zijn geschreven in verouderde talen. Apple is overgestapt op Swift, en Google op Kotlin. Het schrijven van de native API-integraties met deze up-to-date talen is mogelijk, maar voegt een extra laag complexiteit toe, waarvoor 5 programmeertalen nodig zijn. Bij het schrijven van de bridges en de code binnenin met ObjC en Java/Kotlin moet de ontwikkelaar nog steeds kennis hebben van 3 programmeertalen en de fijne kneepjes kennen van beide mobiele platforms. Je kunt ervoor kiezen om deze modules door afzonderlijke ontwikkelaars te laten bouwen, maar dat vereist meer communicatie. Door de JavaScript-code te delen kun je de totale ontwikkeltijd van functies zonder native wrappers vergeleken met het gebruik van native iOS & Android aanzienlijk verkorten.

Snellere ontwikkeling met opensource-modules

Toegang tot kernfuncties van apparaten zoals locatie of Bluetooth is beschikbaar via de native modules. Sommige functionaliteiten zijn al beschikbaar als opensource-modules, waardoor de ontwikkeling versnelt, en voor sommige functionaliteiten moeten deze modules worden ontwikkeld. Ervaring leert dat de beschikbare native modules meestal volstaan voor basisfuncties.

Extra werk voor updates en nieuwe functionaliteiten

Voor toepassingen die diepere integraties vereisen, of nieuwe functionaliteiten die door Apple & Google worden aangeboden, is vaak maatwerk van deze modules vereist. Voor de native modules gebeurt dit vaak via forking van de native module en aanpassing van de code, of door de integratie van de module te dupliceren in de JavaScript-implementatie. Het schrijven of aanpassen van een native module voor iOS & Android en deze zichtbaar maken via een wrapper vereist een grotere inspanning dan gewoon de functionaliteit direct integreren in de app, zoals je zou doen in een native app.

De onderhoudseisen voor de ontwikkeling van Flutter en Native iOS & Android zijn hetzelfde voor React Native apps: eerst bijwerken naar de nieuwe SDK’s voor de totale update kan plaatsvinden. Het toevoegen van nieuwe apparaten vraagt meestal extra werk, omdat de gedeelde UI-code vaak apparaatspecifieke aanpassingen nodig hebbe, waarmee je de UI voor deze apparaten bijwerkt.

Bovendien vragen huidige opensource native modules meestal extra onderhoud. Hiervoor is over het algemeen een selecte groep mensen aangewezen. Waarbij het risico bestaat dat de native module niet wordt bijgewerkt als het project stopt, met alle gevolgen van dien. Zoals incompatibiliteit van nieuwe functionaliteit en API's van Apple & Google, niet langer gepatcht worden voor beveiligingsproblemen of dat verouderde methoden worden gebruikt. Het repareren van native modules is mogelijk, maar vergt extra inspanning.

Onafhankelijkheid leidt tot kortere time-to-market

Toegang tot kernfunctionaliteiten van apparaten zoals Locatie, Bluetooth en OpenGL zijn direct beschikbaar met de frameworks die Apple & Google bieden. Beide geven ook directe toegang tot nieuwe functionaliteiten zoals integratie met spraakassistenten of Augmented Reality. De mogelijkheid om deze technologieën rechtstreeks te gebruiken, zonder afhankelijkheid van hybride development wrappers, verkort de time-to-market.

Meer risico door open karakter JavaScript & NPM

React Native gebruikt Node Package Manager (NPM) als dependency manager. Elke afhankelijkheid die aan het project wordt toegevoegd, brengt nieuwe beveiligingsrisico's met zich mee. Hoewel dit ook geldt voor andere dependency managers, verhoogt het open karakter van JavaScript & NPM het risico. Afhankelijkheden zijn nodig voor native modules, en worden vaak gebruikt voor JavaScript-code zelf. En er zijn manieren om de risico's te verlagen, maar die vragen flink wat inspanning.

4. Progressieve web app

Toegang tot sommige kernfuncties mogelijk moeilijk

Een Progressive Web App (PWA) is een mobiele website die voldoet aan de nieuwe HTML5-normen voor bijvoorbeeld offline gebruik en het verversen van gegevens op de achtergrond. Ze worden ontwikkeld met HTML en JavaScript en draaien in een mobiele browser. Toegang tot kernfuncties van apparaten zoals locatie of Bluetooth is moeilijk, omdat deze moeten aan de HTML5-specificaties van Safari op iOS en Chrome op Android. Functies als Geofencing, Meldingen, Bluetooth en Toegang tot contacten worden momenteel niet ondersteund door iOS. Android ondersteunt sommige van deze functies wel, maar Apple is altijd al traag geweest met het overnemen van nieuwe HTML5-specificaties.

Distributie via eigen website niet ideaal

Iedereen weet de weg naar de App Store of Play Store waar je nieuwe apps kunnen downloaden. Maar PWA's installeer je via een actie op je website. En door deze ongebruikelijke manier van installeren leidt dit tot grote verwarring bij gebruikers over hoe je de app kunt krijgen. Daarnaast hebben PWA's ook niet het voordeel van de standaard winkelpagina's met beschrijvingen, screenshots en app-previews.

5. Onze visie

Wat is onze visie op mobiele app-ontwikkeling? Al met al kunnen we alleen maar concluderen dat elk platform zijn voor- en nadelen heeft. De juiste keuze voor een specifiek platform volgt na een zorgvuldige afweging van specificaties en eisen van de te bouwen app, het probleem dat de app moet oplossen en externe factoren zoals de betrokken ontwikkelaars en toekomstig onderhoud. Voor iedere klant is een oplossing, een technologie die past, en dat is waar Triple helpt.