App

development:

hoe

laat

je

een

app

ontwikkelen?

Welke fasen doorloop je bij app development?

Bij Cube bestaat een app-traject uit zes fasen: contact, discovery, ontwikkeling, oplevering, nazorg en doorontwikkeling. De eerste twee bepalen het grootste deel van het eindresultaat. Wie de analyse overslaat om sneller te beginnen, betaalt dat later terug in herwerk.

Welke keuzes maak je vóór de bouw?

De belangrijkste keuzes maak je voordat er één regel code is geschreven: platform, framework, architectuur en de systemen waarmee de app moet praten. Die keuzes bepalen de structuur van de hele app en zijn later duur om terug te draaien.

Vier vragen die je in deze fase beantwoordt:

• Wie gebruikt de app, en waar? Een app voor monteurs in het veld vraagt iets anders (offline werken, scannen, grote knoppen) dan een app voor supporters op de tribune.

• Welke functies van de telefoon heb je echt nodig? Camera, NFC, bluetooth, pushmeldingen en locatie bepalen of een web app volstaat.

• Met welke systemen moet de app praten? Is er al een API, of moet die er eerst komen?

• Hoe lang moet de app mee? Dat bepaalt hoeveel je investeert in architectuur en automatische tests.

Bij Cube beantwoorden we die vragen in de Kickoff. We onderzoeken bestaande systemen, brengen technische obstakels in kaart en maken de architectuurkeuzes voor het hele project. De meest complexe onderdelen pakken we als eerste aan. Wie die naar het einde schuift, ontdekt de problemen pas als er geen tijd meer is.

Native, cross-platform of web app: wat kies je?

Je kunt een app op drie manieren bouwen, en de keuze volgt uit de functies die je nodig hebt, niet uit de voorkeur van de bouwer.

• Native betekent per platform bouwen: Swift of Objective-C voor iOS, Kotlin of Java voor Android. Je krijgt volledige toegang tot de hardware van de telefoon en maximale controle. Daar staan twee codebases, twee releasecycli en dubbel onderhoud tegenover.

• Cross-platform, ook wel hybride ontwikkeling genoemd, betekent één codebase die op iOS en Android draait. Je kunt bijna overal bij de hardware, de app staat gewoon in de App Store en Google Play, en je onderhoudt alles één keer. Nieuwe versies verschijnen op beide platformen tegelijk. Voor zakelijke apps zonder zware eisen aan de hardware is dit meestal de verstandige keuze.

Een web app draait in de browser. Gebruikers hoeven niets te installeren en je hebt geen store nodig, maar je kunt niet bij alle functies van de telefoon. Twijfel je, lees dan wanneer een web-app de betere keuze is.

Welke frameworks en programmeertalen gebruik je?

Voor cross-platform apps zijn React Native (JavaScript of TypeScript) en Flutter (Dart) de twee grote frameworks. Ionic met Capacitor kom je vooral tegen als een bestaande webcodebase hergebruikt moet worden. Cube bouwt in React Native met Expo of in Flutter. Welke van de twee het wordt, hangt af van de opdracht: de gewenste kwaliteit, de technische complexiteit, de wens van de opdrachtgever en hoe lang de app mee moet.

React Native met Expo.

Bij React Native kiezen we bewust voor Expo. Daarmee bouwen we via de buildserver van Expo, gebruiken we een volwassen ecosysteem van pakketten en hoeven we de native code nauwelijks aan te passen. Dat maakt zowel de ontwikkeling als het onderhoud sneller. Een webvariant is bovendien eenvoudig te koppelen, zodat de app bijvoorbeeld als onderdeel van een bestaande website kan draaien. De LeaseApp van Wevi is zo gebouwd: één codebase voor iOS en Android, en een webversie die grotendeels dezelfde code deelt.

Past bij: snel ontwikkelen, een groot ecosysteem en een app die ook op het web moet werken.

Flutter.

Flutter zetten we in voor de complexere apps. Het biedt voordelen in typeveiligheid en architectuur, onder meer dankzij null safety. De native iOS- en Android-projecten beheren we zelf, maar we passen er zo min mogelijk in aan. Zo kunnen we specifieke technische onderdelen native oplossen en die gecontroleerd met Flutter laten communiceren. Flutter-apps bouwen we lokaal, wat extra controle geeft over het build- en releaseproces.

Past bij: apps die meer technische controle en architectonische vrijheid vragen.

Een uitgebreidere vergelijking lees je in App battle: React Native vs Flutter.

Waarin verschilt app development voor iOS en Android?

Ook met één codebase blijven iOS en Android twee verschillende platformen, met eigen ontwerprichtlijnen, eigen storeregels en eigen hardware.

• iOS volgt Apple's Human Interface Guidelines, Android het Material Design van Google. Gebruikers zijn per platform andere patronen gewend, bijvoorbeeld bij terug navigeren en meldingen, en dat neem je vanaf het begin mee. Ook technisch verschillen de platformen: de levenscyclus van een app, permissies en schermformaten werken anders.

• Android draait op toestellen van veel verschillende fabrikanten, iOS alleen op apparaten van Apple. Daarom test en optimaliseer je per platform op specifieke toestellen en OS-versies. En bij publicatie heeft elke store eigen regels, reviewprocedures en eisen aan de metadata.

Hoe je die verschillen in het ontwerp opvangt, lees je in wat app design is en hoe het ontwerpproces verloopt.

Hoe lang duurt het om een app te ontwikkelen?

Hoe lang het duurt, hangt af van vijf factoren: complexiteit, het aantal koppelingen, het aantal platformen, de eisen aan het ontwerp en hoe snel er input komt vanuit je eigen organisatie. Die laatste wordt vaak onderschat en bepaalt in de praktijk regelmatig het tempo. Een realistische planning voor jouw app volgt uit de Kickoff. Daarvóór is elke planning een schatting zonder fundament. In de werkwijze hieronder zie je de fasen van een traject bij Cube en hoe lang die gebruikelijk duren.

Wat kost het om een app te ontwikkelen?

De kosten van een app hangen af van dezelfde factoren als de doorlooptijd. Dit zijn de vijf grootste kostendrijvers:

• Schermen en flows. Niet het aantal functies telt, maar het aantal routes dat een gebruiker door de app kan afleggen.

• Koppelingen. Elke koppeling met een ander systeem kost ontwerp, bouw en onderhoud. Ontbreekt er een API, dan moet die eerst gemaakt worden.

• Platformen. Eén codebase voor twee platformen is aanzienlijk goedkoper dan twee native apps, maar niet gratis: je test nog steeds op beide.

• Ontwerp. Een app die strak op een bestaande huisstijl moet aansluiten, vraagt meer ontwerptijd dan een app die de standaardpatronen van het platform volgt.

• Onderhoud na de livegang. Reken op structurele kosten voor nieuwe OS-versies, updates van gebruikte pakketten en gewijzigde storeregels. Een app die niet wordt bijgewerkt, loopt steeds verder achter en wordt uiteindelijk lastig te publiceren.

Hoe bewaak je kwaliteit en veiligheid tijdens de bouw?

Door elke wijziging langs dezelfde vaste controles te laten gaan voordat hij in een release komt. Bij Cube wordt een issue opgepakt, via een merge request gereviewd door zowel AI als een developer, handmatig getest op een toestel en daarna getest door de opdrachtgever. Pas als alles is goedgekeurd, komt het in een release.

Testen op iOS en Android.

Testversies spelen daarin een grote rol. Voor iOS gebruiken we TestFlight, voor Android de interne testtrack van Google Play. Zo test je als opdrachtgever nieuwe functies op je eigen telefoon en geef je direct feedback, waardoor problemen vroeg boven water komen.

Daarnaast draait Sentry mee voor crashmonitoring, en bewaart de app compacte logs op het toestel. Dat helpt bij problemen die alleen op bepaalde toestellen optreden, zoals bij bellen vanuit de app, waar het gedrag per toestel verschilt. In de pipeline draaien automatische tests, zodat nieuwe functies bestaande onderdelen niet breken.

Wat AI doet, en wat niet.

AI ondersteunt de developers zonder hun werk over te nemen. Het signaleert mogelijke fouten, helpt bij code reviews en vult code aan tijdens het schrijven. Ook analyseert het logbestanden en verbetert het de documentatie. Een menselijke review vervangt het niet: elke merge request wordt ook door een developer bekeken.

Hoe komt een app in de App Store en Google Play?

Een app komt in de stores na een review: Apple beoordeelt elke iOS-app handmatig, Google werkt met een deels geautomatiseerd proces en strikte richtlijnen. Privacyverklaring, metadata, versienummers en changelogs moeten op orde zijn en voldoen aan de AVG.

Dit heb je klaar voordat je instuurt:

• een privacyverklaring die klopt met de gegevens die de app echt verzamelt;

• screenshots per schermformaat;

• een beschrijving, categorie en leeftijdsclassificatie;

• een changelog per versie;

• developeraccounts bij Apple en Google, met een duidelijke afspraak op wiens naam ze staan.

Over dat laatste punt: spreek vóór de start af of de accounts op naam van je eigen organisatie komen of tijdelijk bij de bouwer liggen, met een afspraak over overdracht. Achteraf omzetten kost tijd. Plan daarnaast ruimte in voor de review zelf. Een eerste inzending kan worden afgewezen op een detail in de metadata; dat is te herstellen, maar kost een extra ronde.

Niet elke app hoort in een publieke store.

Een app voor je eigen medewerkers kan ook buiten de stores om op de toestellen komen. De haspelretour-app van TKF is alleen voor Android gemaakt en wordt via Microsoft Intune verspreid, met inloggen via de bestaande Microsoft-accounts van medewerkers. Zo bepaal je zelf wie de app krijgt, zonder openbare vermelding in een store.

Wat gebeurt er na de livegang?

Na de livegang begint het onderhoud: bugfixes, feedback van echte gebruikers en updates voor nieuwe versies van iOS en Android. Een app is nooit af. Vier dingen die daarbij spelen:

• Uitrollen in stappen. De LeaseApp van Wevi ging eerst naar een interne testgroep, daarna naar één grote opdrachtgever van Wevi met ongeveer 10 procent van de gebruikers. Pas toen dat goed liep, kregen alle overige berijders binnen twee dagen een uitnodiging.

• Platformupdates en pakketten. iOS en Android krijgen elk jaar een nieuwe hoofdversie. We volgen die actief, testen de app erop en werken gebruikte pakketten tijdig bij, zodat een update nooit een project op zich wordt.

• Koppelingen. Heeft de opdrachtgever geen eigen API, dan praat de app via een datamanagementplatform (DMP). De bedrijfslogica blijft dan op één plek, en de app blijft stabiel als er aan de kant van andere systemen iets verandert. Is er wel een API, dan gebruikt de app die direct.

• Code en documentatie. Elk project heeft README's met werk- en codeafspraken, zodat een nieuwe developer snel kan instappen. Dat klinkt als een detail, maar het bepaalt of je als opdrachtgever vastzit aan één persoon of partij.

Hoe Cube dat onderhoud structureel regelt, lees je bij softwarebeheer.