View profile

"Anders bouwen we even een app"

Jos van Essen
Jos van Essen
In deze versie van de nieuwsbrief wil ik het hebben over app-development.
Eind 2006 kreeg ik mijn eerste baan bij Ilsemedia en zat ik vlak naast de afdeling business development. Dit was dus nog vóór de eerste iPhone. Op die afdeling werd wel eens nagedacht over hoe het web zou zijn op mobiel. Je had al wel de eerste stapjes op het gebied van mobiel internet (domeinnaam .mobi) maar dat was allemaal nog heel bewerkelijk en werd nauwelijks gebruikt. Niemand geloofde er ooit in dat die kleine schermpjes van onze Nokia’s ooit nog volwaardig onderdeel zouden worden van het Internet. Tenminste, ik niet. Maar ik zit er wel vaker volledig naast.
Met de fameuze “Apple reinvents the phone” slogan van Steve Jobs was de eerste iPhone begin 2007 een feit. Maar deze had initieel geen eigen AppStore zoals we die nu kennen. Pas in latere versies werd de AppStore ook onderdeel van het Apple ecosysteem. Met behoorlijk financieel succes overigens: vorig jaar was de geschatte omzet van alleen de AppStore 64 miljard dollar.
Voor wat betreft app-development zijn er in 2021 nog twee platformen waar je op moet focussen. De AppStore van Apple en de Play Store van Google voor (bijna) alle Android telefoons.
Als eerste is het dus een keuze voor welke van de twee platformen je iets gaat ontwikkelen. Er zijn hippe startups die hun apps eerst voor de iPhone ontwikkellen (recent Clubhouse) en pas veel later een Android versie hadden maar het is in veel gevallen natuurlijk logischer om beide versies te hebben.
Dan de volgende zaken die je je moet afvragen.
Wil ik m'n app ‘native’ hebben? Native wil zeggen: in de programmeertaal waarin de aanbieder van de app graag wil dat je de apps aanlevert. Voor Apple is dit Swift, en voor Android is dit C/C++. Beide techreuzen hebben een eigen ecosysteempje gebouwd om het app-developers zo eenvoudig mogelijk te maken, bijvoorbeeld met een eigen editor. Voor Apple heet deze Xcode en voor Android Studio. Zowel Apple als Google willen het zo eenvoudiger en laagdrempelig mogelijk maken om apps op hun platformen te krijgen zodat ontwikkelaars er sneller voor kiezen om specifiek voor hun platform te kiezen (en de andere over te slaan).
Het grote voordeel aan native apps is dat ze snel zijn, gebruik kunnen maken van bijna alle technologie aan boord van de telefoons (GPS, camera, vingerafdrukscanner, etc) en heel stabiel voelen.
Het grote nadeel is dat je voor ieder platform geheel eigen code moet schrijven en daarom eigenlijk twee keer zo lang bezig bent. Daarbij is het vinden van ontwikkelaars die native code kunnen schrijven behoorlijk ingewikkeld en duur.
Dan de tweede oplossingsrichting: niet-native. Voor niet-native apps geldt eigenlijk allemaal dat ze een uniforme codebase hebben die zowel naar Apple als Google gestuurd kan worden. Je ontwikkelt dus apps voor beide platformen tegelijkertijd.
De niet-native apps hebben in het verleden bij diverse ontwikkelaars een slechte naam opgebouwd door PhoneGap. Dit was een library die ook als bedoeling had om via 1 codebase meerdere apps te lanceren maar deze manier was ingewikkeld en de apps die je er mee kon bouwen waren pijnlijk traag en instabiel.
Gelukkig zijn de tijden veranderd en is er nu een keur aan prima opties om met één (JavaScript gebaseerde) taal meerdere apps te bouwen. We gaan het rijtje langs.
React Native, de codebase die ooit door Facebook werd gebouwd is inmiddels voor veel ontwikkelaars de ‘weapen of choice’ geworden. Veelzijdig, relatief eenvoudig en veel handleidingen beschikbaar om ook geavanceerdere implementaties te bouwen.
Ionic stelt je in staat om ook apps te bouwen in React, maar ook in Angular of Vue. Met Capacitator kunnen native functionaliteit binnen een app worden aangeroepen.
Xamarin is in de .NET community het belangrijkste platform. En je hebt nog meer experimentele opties zoals bijvoorbeeld NativeScript.
De hipste ontwikkelaars kiezen nu voor Flutter.
Belangrijk aan het kiezen van het juiste platform (eventueel met je ontwikkelclub) is vooral de toekomstige ondersteuning: hoeveel ontwikkelaars zijn er over een jaar of 2 nog te vinden voor je platform? En hoeveel daarvan zijn ook beschikbaar om aan jouw code te werken? Verkeerde keuzes maken kan zorgen voor grote rebuilds, die tijdstechnisch kostbaar zijn. Kiezen voor een ‘bekende naam’ is dus wel aan te raden.
Na het ‘bouwen’ van de app ben je er vaak nog lang niet. Er zit best wat (administratief) werk achter het daadwerkelijk releasen van de app: om deze gepubliceerd te krijgen in de stores heb je een account nodig, en deze moet ook geverifieerd worden: bij Apple duurt dit een aantal dagen. Ook de opmaak in de appstore moet in orde zijn: er moeten screenshots bij, en op verschillende plekken moeten promotie-praatjes komen zodat Apple jouw app het beste kan weergeven in de store (vandaar die 64 miljard ;-) ). “Even een app” bouwen zoals ik in de titel suggereer heeft dus een heleboel meer implicatie dan je misschien op het eerste gezicht zou verwachten.
Tot volgende week!

Did you enjoy this issue? Yes No
Jos van Essen
Jos van Essen

JSON, API's, webtokens, CI deployments, JavaScript, Tag Manager: we horen allemaal regelmatig termen voorbij komen waarvan we niet 100% zeker weten of we het ook daadwerkelijk begrijpt. Deze nieuwsbrief laat een licht schijnen op deze materie: tech voor op het web uitgelegd

In order to unsubscribe, click here.
If you were forwarded this newsletter and you like it, you can subscribe here.
Created with Revue by Twitter.