We willen als ontwikkelaars alleen producten maken die specifiek zijn voor de klant en het project. Zo kunnen we meteen vanaf de start waarde leveren. En waarom zouden we in ieder project het wiel opnieuw uitvinden? Daarom gebruiken we een framework: een set standaardfuncties, getest, geoptimaliseerd en klaar voor gebruik. In dit blog vertel ik je hoe we een app framework kiezen en waarom React Native onze favoriet is.
Een mobiele app is technisch aardig ingewikkeld. Het doel is om de gebruiker een soepele, instinctieve ervaring te geven op een apparaat met beperkte rekenkracht en een klein scherm, terwijl je er nooit 100% zeker van kunt zijn dat je netwerkverbinding hebt. De geavanceerd technologie die je daarvoor nodig hebt, zit gebundeld in een framework.
Een app framework kiezen: waar je op moet lettenÂ
Maar wat is het ideale app framework? Op die vraag zijn veel verschillende antwoorden. Het verschilt ook per project. Maar hier bij Team Artisans houden we altijd rekening met deze vijf factoren:Â
- Community
- Snelheid en Agile werken
- Open source
- Multiplatform
- Programmeertaal
1. CommunityÂ
Dit is voor ons een hele belangrijke. Wij willen altijd snel vooruit met een app-project. Een grote community rondom een framework helpt daarbij. Een framework als React Native heeft zo veel actieve gebruikers, waaronder hele grote bedrijven, dat je bijna nooit een technisch probleem tegenkomt waar nog niemand over heeft nagedacht. Meestal is er ook een oplossing beschikbaar en kun je gauw verder.Â
2. Snelheid en Agile werkenÂ
Dit ligt eigenlijk in het verlengde van punt 1. Als de community de technische problemen grotendeels heeft opgelost en je kunt veel componenten hergebruiken, kun je sneller de functies bouwen waar de gebruiker wat aan heeft. Wij werken intensief samen met de klant en we willen dus snel waarde leveren. Als we te veel tijd moeten besteden aan de technische basis, lukt dat niet. We willen dus een framework dat veel standaard componenten biedt, in het framework zelf of vanuit de community, en dat zich goed leent voor het opleveren van apps in ‘agile’ stapjes. Het is daarbij ook belangrijk dat een framework snel te configureren is.
3. Open sourceÂ
Wij geloven in open source. Je wilt als developer, en als eindklant, niet afhankelijk zijn van één leverancier om je app in de lucht te houden. Want wat moet je dan als zo’n leverancier of product van de markt verdwijnt? Daarom kiezen we voor software die door de community wordt onderhouden. Dan weten we niet alleen precies wat de code doet, we kunnen ook meewerken aan de doorontwikkeling ervan. Want open source is natuurlijk niet alleen een kwestie van nemen: we leveren ook graag een bijdrage.Â
4. MultiplatformÂ
Apps ontwikkel je bijna altijd voor 2 platformen: iOS en Android. We proberen altijd zo veel mogelijk voor de 2 platformen tegelijk te bouwen. Dat scheelt niet alleen tijd bij het bouwen zelf, maar ook later bij het onderhoud. Niet ieder framework is daar even goed voor ingericht, dus is dit iets waar we kritisch naar kijken. Allebei de platformen hebben zo hun eigen eisen en kronkels. De twee uiteindelijke apps hebben dus altijd platformspecifieke code, om te zorgen dat ze allebei een goede gebruikerservaring bieden.
5. ProgrammeertaalÂ
Veel frameworks zijn gebaseerd op een specifieke programmeertaal. Om ermee te kunnen werken, moet je die taal wel beheersen. Moet een project bijvoorbeeld per se in Xamarin? Dan zullen wij die niet aannemen. Dat is een framework dat in C# geprogrammeerd moet worden, en daar hebben we geen ervaring mee.Â
Omgaan met legacy
Je hebt het natuurlijk niet altijd voor het kiezen. Soms heb je te maken met legacy. Dan moet je er het beste van zien te maken. Je moet daar altijd een goede afweging in maken. Het is niet efficiënt om alles meteen op de schop te gooien. Stapje voor stapje werkt dan het beste. De app van een van onze klanten was bijvoorbeeld gemaakt met een webview. Dat betekent dat het eigenlijk een website is, die ‘verpakt’ is als app. Dat is een hele snelle en makkelijke manier om een app te maken, maar het is niet ideaal voor de user experience. De besturingselementen reageren trager en wachtwoordmanagers werken bijvoorbeeld minder goed. Daarom hebben we afgesproken de app beetje bij beetje meer native te maken. Veelgebruikte functies, zoals inloggen en het gebruikersdashboard, zijn nu native en dus veel sneller en gebruiksvriendelijker. Â
Frameworks die we in de praktijk tegenkomen
Er zijn veel verschillende frameworks, maar er zijn er 6 die wij in de praktijk het meeste tegenkomen.Â
Titanium
Titanium, een open source framework dat is ontwikkeld door Appcelerator, dat erop gericht is om op alle verschillende platformen zoveel mogelijk dezelfde code te kunnen gebruiken. Het is gebaseerd op JavaScript. Een beperking van Titanium is de relatief kleine community. Daardoor moet je meer dingen zelf uitzoeken en maken, terwijl je bij andere frameworks juist heel veel standaard componenten tot je beschikking hebt. Omdat Titanium geen webvariant heeft, zul je voor app en web altijd met twee aparte frameworks moeten werken.Â
Ionic
Ook Ionic is een multi-platform JavaScript-framework. Eigenlijk is het een webframework dat ook wel gebruikt wordt om apps mee te maken. Zo’n app is dan in principe een website die binnen een app gerendered wordt. Wij zijn daar geen fan van, omdat je niet de mogelijkheid hebt om met native componenten te werken. De performance zal altijd een beetje achterblijven, ook op plekken waar dat voor de gebruikerservaring eigenlijk niet kan.Â
Cordova
Cordova is de basis waarop Ionic is gebouwd. Het is in feite een tussenlaag, die zorgt dat een app kan praten met de native onderlaag. Bouw je een app op basis van Cordova, dan heb je heel veel vrijheid, maar je moet wel echt alles zelf maken. Meestal past dat niet goed bij onze projectaanpak.Â
Xamarin
Ik had het al even over Xamarin. Het is een framework van Microsoft. Alleen gebruikt Microsoft het zelf niet meer. Ook Xamarin is open source en het wordt, zoals gezegd, geprogrammeerd in de taal C#. Xamarin heeft een kleine community, wat het lastig maakt om snel van start te gaan.Â
Flutter
Naast React native is er inmiddels ook Flutter. Flutter is een UI library gebouwd door Google waarmee je net zoals met React native apps kan ontwikkelen voor iOS en Android. Het grote voordeel van Flutter ten opzichte van React Native is dat Flutter geen gebruik hoeft te maken van een brug tussen JavaScript en de Native components hierdoor is Flutter meer responsief wat resulteert in een betere gebruikerservaring.
Het nadeel van Flutter ten opzichte van React Native is dat we React Native al erg goed kennen omdat we React al vaker hebben ingezet in de web context. Daarnaast gebruikt Flutter de programmeertaal Dart deze programmeertaal wijkt af van Typescript wat we momenteel gebruiken in onze projecten. Uiteraard sluiten we niet uit dat we in de toekomst meer ervaring gaan opdoen met Flutter omdat er zich een use case voordoet waarbij Flutter beter past.
Waarom we van React Native houden
Nummer 6 is React Native. En dat is het framework dat we het meeste gebruiken. Het komt maar weinig voor dat een klant iets vraagt wat we daar niet mee kunnen maken. Eén voordeel van React Native is dat de manier van ontwikkelen bijna hetzelfde is als bij React-webapps. Er zijn wel kleine verschillen, maar als je eenmaal aan de terminologie gewend bent, is het eigenlijk hetzelfde als bouwen voor het web. De componenten die je in de app gebruikt, zijn wel allemaal native. Dus zit je op een iPhone, dan zijn alle user interface-elementen ‘echte’ iOS-componenten die via JavaScript communiceren. Dat maakt je app snel en gebruiksvriendelijk.
Krachtige community
React Native is ontwikkeld door Facebook, maar heeft vrij snel daarna wereldwijd tractie gekregen en wordt heel veel gebruikt. Het gaat nog harder, nu ook Microsoft het omarmd heeft en de mobiele Word- en Outlook-apps gebouwd heeft in React Native, net als heel veel andere Microsoft-apps. Zo’n krachtige community zorgt dat er heel veel beschikbaar is dat je kunt gebruiken in je eigen apps. En bijna alles is open source. Dat scheelt heel veel tijd, want vooral het ontwikkelen van native functionaliteit is tijdrovend.
We werken het liefst met een MVP-aanpak, waarbij we heel snel bruikbare functionaliteit uitrollen naar de gebruiker. Dan scheelt het dat we niet eerst allerlei technische problemen hoeven te gaan oplossen. React Native heeft zo’n grote community, dat er altijd wel een library is die je kunt gebruiken.
Twee platformen tegelijk
En je ontwikkelt in React Native, net als in andere moderne frameworks, altijd voor iOS en Android tegelijk. Vaak werken we ook met Expo. Expo neemt ons nog meer werk uit handen rondom het bouwen voor de twee verschillende platformen. Dat zorgt ervoor dat we nog sneller kunnen ontwikkelen. Omdat Expo (nog) niet alle libraries ondersteunt, is het vooral een goede tool voor het maken van het MVP, het minimum viable product dat als eerste projectresultaat in gebruik genomen wordt door de organisatie. Als een app later uitgebreider wordt, halen we hem soms uit Expo. Maar dan zijn gebruikers al lang met de app aan het werk. Â
In principe kun je React trouwens gebruiken op ieder device. Ik heb er zelf geen ervaring mee, maar ik zou niet weten waarom je niet bijvoorbeeld een smart TV-app zou kunnen bouwen met React Native.
Ook nadelen? Ja, ook nadelenÂ
Heeft React Native dan helemaal geen nadelen? Natuurlijk wel. Het belangrijkste heeft met performance te maken. Omdat JavaScript een geïnterpreteerde taal is en dus niet gecompileerd wordt naar native code, is er een ‘brug’ nodig van de native componenten naar JavaScript. In die brug gaat wat performance verloren. Omdat React Native zo veel gebruikt wordt, zijn daar gelukkig ook al oplossingen voor bedacht. De apps van Instagram en Facebook gebruiken bijvoorbeeld native code voor de meest gebruikte acties, zodat die een optimale performance hebben. Minder vaak gebruikte functionaliteit, zoals het scherm voor gebruikersinstellingen, kan dan via de JavaScript-brug gebouwd worden. Zo ben je als developer altijd op zoek naar een balans tussen het snel neerzetten van functionaliteit en het bieden van de beste user experience.
Een app bouwen: zo begin je
Het platform kiezen is natuurlijk maar een eerste stap. Om te kunnen beginnen met het bouwen van je app, moet je meer doen dan alleen een technologie kiezen. Wij doen veel van het voorbereidend werk in een ‘Sprint 0’. Lees hier hoe dat werkt.
Whitepaper App Development
Een mobiele app is dé manier om altijd in contact met je klanten te zijn. We schreven daarom een whitepaper over App development. Vraag hem aan!
