Wat is app-development?
App-development is het bouwen van toepassingen die op een telefoon of tablet worden geïnstalleerd, meestal via de App Store van Apple of Google Play. Anders dan een website draait een app op het toestel zelf, wat betekent dat hij toegang kan krijgen tot camera, locatie, contacten en meldingen, en dat hij ook kan werken als er geen verbinding is.
Er zijn grofweg drie routes. Native betekent dat er voor iOS en Android apart wordt gebouwd, wat de beste prestaties geeft maar in feite neerkomt op twee projecten. Hybride of cross-platform betekent dat er één keer wordt geschreven en dat die code op beide platformen draait, wat aanzienlijk goedkoper is tegen enige concessie. En een progressive web app is eigenlijk een website die zich als app gedraagt, zonder installatie via een winkel.
De keuze tussen die routes hangt af van wat de app moet kunnen en van wie hem gaat gebruiken. Het is een van de weinige gebieden in webdesign waar de technische keuze rechtstreeks doorwerkt in het budget, in het onderhoud en in wat er later nog mogelijk is. Een verkeerde keuze aan het begin is achteraf duur te corrigeren.
Wat valt er precies onder?
Een app-project omvat meer dan het programmeren zelf; de distributie en het onderhoud vormen een wezenlijk deel.
- Platformkeuze: bepalen of er native, hybride of als progressive web app wordt gebouwd, en voor welke platformen.
- Interfaceontwerp per platform: iOS en Android hebben eigen conventies voor navigatie en bediening die gebruikers verwachten.
- Toestelfuncties: toegang tot camera, locatie, biometrische ontgrendeling, bestanden en meldingen.
- Offline werking: gegevens lokaal opslaan en synchroniseren zodra er weer verbinding is.
- Pushmeldingen: het versturen en beheren van berichten, inclusief toestemming vragen en frequentie bewaken.
- Backend en API: de serverkant die de app van gegevens voorziet, doorgaans gedeeld met de website.
- Distributie: de accounts, de aanmelding, de beoordelingsprocedure en het beheer van versies in beide winkels.
- Onderhoud: aanpassingen aan nieuwe besturingssysteemversies, gewijzigde winkelregels en beveiligingsupdates.
Hoe verloopt een app-traject?
Een app-project heeft twee fases die een website niet kent: de beoordeling door de winkels en het permanente meebewegen met de platformen.
- Afbakenen en kiezen. Er wordt vastgesteld wat de app moet kunnen, welke toestelfuncties daarvoor nodig zijn en welke bouwwijze daarbij past.
- Ontwerpen per platform. De interface wordt ontworpen met inachtneming van de conventies van iOS en Android, die op punten van elkaar verschillen.
- Bouwen. De app wordt ontwikkeld, meestal in delen die tussentijds te testen zijn op echte toestellen.
- Testen op toestellen. Er wordt getest op verschillende schermformaten en besturingssysteemversies, want emulatoren dekken lang niet alles af.
- Indienen bij de winkels. De app wordt aangemeld met beschrijving, schermafbeeldingen en privacygegevens, en doorloopt de beoordeling.
- Uitbrengen en onderhouden. Na publicatie volgen updates voor fouten, nieuwe functies en aanpassing aan jaarlijkse platformwijzigingen.
Wanneer heb je dit nodig?
Een app is te verdedigen bij herhaald gebruik. Toepassingen die mensen dagelijks of wekelijks openen, rechtvaardigen de drempel van installeren; iets wat iemand één keer per jaar nodig heeft, vrijwel nooit.
Een tweede aanleiding is de behoefte aan toestelfuncties: scannen met de camera, precieze locatiebepaling, biometrisch inloggen of het uitlezen van sensoren. Dat is in een browser niet of slechts beperkt beschikbaar.
Ook werken zonder verbinding is een sterk argument, bijvoorbeeld voor monteurs, inspecteurs of medewerkers in gebouwen met slecht bereik. En pushmeldingen kunnen doorslaggevend zijn wanneer tijdige berichtgeving wezenlijk is, al kan dat inmiddels op Android en in beperkte mate op iOS ook via een progressive web app.
Wat levert het op?
Een app levert een directere en snellere ervaring op dan een website, met toegang tot functies die een browser niet biedt. Voor toepassingen die intensief worden gebruikt, weegt dat zwaar: het pictogram op het beginscherm is een blijvende aanwezigheid, en meldingen geven een kanaal dat een website mist. Voor interne toepassingen, zoals werk in het veld, is offlinewerking vaak het doorslaggevende voordeel.
De kosten worden echter stelselmatig onderschat. Een app is nooit af: elk jaar brengen Apple en Google nieuwe versies van hun besturingssysteem uit, en apps die niet meebewegen kunnen op termijn uit de winkel worden gehaald. Daar komen de winkelregels bij, die eenzijdig kunnen wijzigen en waar je je aan hebt te houden. En de installatiedrempel is reëel: veel apps worden gedownload, één keer geopend en daarna verwijderd. Bureaus die een app aanbieden als vanzelfsprekende uitbreiding van een website, gaan aan die kosten en aan die drempel voorbij. Voor veel organisaties is een goede mobiele site of een progressive web app de verstandiger keuze.
Waar let je op als je dit uitbesteedt?
Vraag als eerste of een app werkelijk nodig is, en laat het bureau uitleggen waarom een progressive web app niet volstaat. Een partij die die vraag serieus behandelt in plaats van meteen naar de bouw te gaan, is een beter teken dan een enthousiaste offerte. Vraag bij een positief antwoord welke bouwwijze wordt voorgesteld en wat dat betekent voor kosten op langere termijn.
Regel daarnaast de eigendomskwesties. De accounts bij Apple en Google horen op naam van jouw organisatie te staan, niet op die van het bureau: anders ben je bij een breuk de toegang tot je eigen app kwijt, inclusief de beoordelingen en de installaties. Vraag ook naar de onderhoudsafspraak en wat die dekt, met name het meebewegen met jaarlijkse platformversies. Vraag ten slotte hoe de app wordt getest en op welke toestellen, want de verscheidenheid aan Android-apparaten is aanzienlijk.
Veelgemaakte fouten
De meeste teleurstellingen bij apps ontstaan voordat er een regel code is geschreven.
- Een app bouwen zonder gebruiksfrequentie. Als mensen de toepassing zelden nodig hebben, wegen ze de installatie niet op tegen het gemak van de website.
- De accounts op naam van het bureau zetten. Dat maakt overstappen praktisch onmogelijk en zet de zeggenschap over de eigen app bij een derde.
- Onderhoud niet begroten. Een app die niet meebeweegt met nieuwe besturingssysteemversies, gaat na een paar jaar stuk of verdwijnt uit de winkel.
- De winkelregels te laat lezen. Vooral Apple stelt eisen aan eigen functionaliteit en aan betalingen, en afwijzing halverwege de planning kost weken.
Wat bepaalt de prijs?
De prijs volgt uit het aantal platformen, de gekozen bouwwijze en de hoeveelheid functionaliteit die het toestel zelf moet gebruiken. Offline werken met synchronisatie is de post die het vaakst wordt onderschat.
| Wat de prijs opdrijft | Waarom het meetelt |
|---|---|
| Native of hybride | Native bouwen voor beide platformen komt in de kern neer op twee projecten in plaats van een. |
| Offline werking | Lokaal opslaan en later synchroniseren vraagt afhandeling van conflicten en is aanzienlijk complexer dan het lijkt. |
| Toestelfuncties | Camera, locatie en biometrie vragen per platform eigen implementatie, toestemmingen en testwerk. |
| Onderhoud per jaar | Jaarlijkse platformversies en gewijzigde winkelregels vragen aanpassingen, ook zonder nieuwe functies. |
App-projecten worden doorgaans op projectbasis begroot voor een eerste versie, met daarnaast een doorlopende onderhoudspost. Die laatste is bij apps niet optioneel: zonder onderhoud verloopt een app binnen enkele jaren. Vraag expliciet wat de onderhoudsafspraak dekt en of aanpassing aan nieuwe besturingssysteemversies erin zit, want dat is de post die het vaakst als meerwerk terugkomt.
App-development en aanverwante diensten
App-development staat naast de website en deelt daar in de praktijk veel mee. Backend en maatwerk levert doorgaans dezelfde gegevens aan de app als aan de site, waardoor één serverkant beide bedient. Koppelingen en API’s zijn daarbij de verbinding, en de kwaliteit daarvan bepaalt hoe soepel de app werkt. UI-design vraagt hier extra aandacht omdat iOS en Android eigen conventies hebben die gebruikers verwachten. Headless en Jamstack raakt eraan wanneer dezelfde inhoud zowel de site als de app moet voeden, wat een van de sterkste argumenten voor die architectuur is. En digitale toegankelijkheid geldt ook voor apps, met eigen richtlijnen per platform. In Nederland biedt een deel van de webdesignbureaus dit aan; anderen verwijzen bewust door naar gespecialiseerde app-bureaus.