App laten ontwikkelen

Een app in de winkels is zinvol als gebruikers hem vaak openen, als hij iets van het apparaat nodig heeft dat de browser niet goed biedt, of als hij moet werken zonder verbinding. Denk aan een app voor buitendienstmedewerkers die in een gebied zonder bereik inspecties vastleggen, of een app voor vaste klanten die meldingen ontvangen.

Een app is vaak niet nodig als mensen hem een paar keer per jaar gebruiken, als alle functies ook in een webapplicatie kunnen, of als het vooral om informatie gaat. Een app moet worden geïnstalleerd, bijgewerkt en in twee winkels onderhouden. Voor eenmalige of incidentele gebruikers is dat een drempel die een website niet heeft.

Zijn de wensen nog breed, bijvoorbeeld een systeem met een beheeromgeving, een website en een app, lees dan eerst web- en app-ontwikkeling. Daar staat de basisafweging tussen webapplicatie, progressive web app en native app. Deze pagina gaat verder in op de app zelf: welke techniek, welke winkel-eisen en welke regels. Twijfelt u of u überhaupt moet laten bouwen, dan helpt maatwerk of standaard software bij die keuze.

TechinFlow is een nieuw bureau en noemt geen eerder gebouwde apps als referentie. Wat u kunt beoordelen, is een werkend prototype op uw eigen toestel voordat er een groot budget is uitgegeven. Dat is ook de eerste stap in de aanpak verderop.

Er zijn drie technische routes. Ze verschillen vooral in hoeveel code u onderhoudt en hoe dicht u bij het apparaat komt.

Ons uitgangspunt is de lichtste route die alle eisen haalt. Voor een interne app met formulieren en een kaart is dat vaak een progressive web app. Moet de app in de winkels staan of op de achtergrond locaties bijhouden, dan wordt het meestal cross-platform. Native is de uitzondering, omdat u dan twee codebases betaalt voor elke wijziging.

Capacitor verdient een aparte toelichting. Het verpakt een webapplicatie als app voor de winkels, met toegang tot functies van het toestel. Dat is efficiënt als er al een webapplicatie is, maar het kan botsen met de winkelregels over apps die alleen een website tonen. Daarover gaat de volgende sectie.

Apple beoordeelt elke app en elke update voordat die in de App Store komt. De App Store Review Guidelines zijn daarbij de maatstaf. Voor apps die op een website lijken, is richtlijn 4.2 het belangrijkst:

Your app should include features, content, and UI that elevate it beyond a repackaged website.

Bron: Apple, App Store Review Guidelines, richtlijn 4.2 Minimum Functionality, gelezen 11-10-2026.

Een app die alleen een bestaande website in een kader toont, loopt dus risico op afwijzing. Een app die offline werkt, de camera of locatie gebruikt, of meldingen stuurt, heeft een sterkere positie. Twee andere richtlijnen leiden vaak tot vertraging als ze niet vooraf zijn ingepland:

• Demo-account (richtlijn 2.1). Heeft de app een inlog, dan moet u Apple een demo-account geven en de achterkant laten draaien tijdens de beoordeling. Kan dat om juridische of veiligheidsredenen niet, dan is een ingebouwde demomodus mogelijk, na toestemming van Apple.
• Account verwijderen (richtlijn 5.1.1). Kan een gebruiker in de app een account aanmaken, dan moet hij dat account ook in de app kunnen verwijderen.

Voor een organisatieaccount in het Apple Developer Program vraagt Apple een rechtspersoon die contracten kan sluiten, een D-U-N-S-nummer (overheidsorganisaties uitgezonderd) en een werkende website op een eigen domein. Het lidmaatschap kost volgens Apple 99 dollar per jaar; non-profitorganisaties, onderwijsinstellingen en overheden kunnen onder voorwaarden vrijstelling aanvragen.

Google Play kent een eenmalige registratievergoeding van 25 dollar voor een ontwikkelaarsaccount. Daarnaast gelden technische eisen die elk jaar strenger worden. De belangrijkste is het target API-niveau: de Android-versie waarvoor de app is gebouwd.

Het target API-niveau betekent dat een app niet jaren ongewijzigd kan blijven staan. Wie de app niet bijwerkt, kan geen updates meer publiceren en raakt zichtbaarheid kwijt bij gebruikers met nieuwe toestellen. Reken daarom in de begroting op jaarlijks onderhoud, ook als er geen nieuwe functies bij komen. Zie ook kosten van maatwerk software.

De testverplichting met twaalf testers geldt volgens Google voor persoonlijke accounts. Laat de app daarom publiceren via een organisatieaccount op naam van uw eigen organisatie. Dan blijft de app ook van u als u later van ontwikkelaar wisselt.

Lange tijd was het grootste bezwaar tegen een progressive web app dat iPhones geen pushmeldingen ondersteunden. Dat is veranderd. WebKit, de browser-engine van Apple, kondigde op 16 februari 2023 aan dat iOS en iPadOS 16.4 Web Push toevoegen voor webapps op het beginscherm.

Daar zitten twee voorwaarden aan. De gebruiker moet de webapp eerst zelf aan het beginscherm toevoegen, en de vraag om toestemming voor meldingen moet volgen op een directe handeling van de gebruiker, zoals een tik op een knop. Een melding kan dus niet ongevraagd bij het eerste bezoek worden aangeboden.

Voor zakelijke toepassingen betekent dit dat een progressive web app vaker volstaat dan een paar jaar geleden. Een buitendienst-app die formulieren offline bewaart, foto's maakt en een melding geeft als er een nieuwe taak klaarstaat, kan zonder winkel. De beperkingen zitten bij langdurige achtergrondtaken, zoals continu locatie bijhouden, en bij gebruikers die een app in de winkel verwachten.

Werkt de app met kaarten, bijvoorbeeld voor inspecties in de openbare ruimte, dan komen daar eisen bij voor offline kaarttegels en coördinaten. Die staan bij GIS- en kaartoplossingen. Een voorbeeld van zo'n toepassing is meldingen openbare ruimte.

Voor overheidsinstanties gelden de toegankelijkheidseisen van EN 301 549 voor websites en mobiele applicaties; die zijn uitgewerkt op de pagina over gemeenten. Sinds 2025 geldt ook voor veel bedrijven een toegankelijkheidsplicht. De ACM schrijft dat vanaf 28 juni 2025 nieuwe regels gelden voor de toegankelijkheid van websites en apps, en dat het bij e-handelsdiensten gaat om websites en apps waar je producten en diensten kunt kopen, afsluiten of reserveren.

Volgens de ACM gelden de verplichtingen voor bedrijven die tien of meer mensen in dienst hebben en/of een jaaromzet van meer dan twee miljoen euro. Ook elektronische communicatiediensten, zoals chatten en videobellen, vallen eronder. Of uw app onder de regels valt, hangt dus af van wat de app doet en hoe groot uw organisatie is. Laat dat bij twijfel juridisch toetsen.

Los van de plicht is toegankelijkheid ook gewoon kwaliteit. In de praktijk betekent het voor een app:

• elke knop en elk pictogram heeft een naam die VoiceOver en TalkBack voorlezen;
• tekst schaalt mee met de lettergrootte die de gebruiker in het toestel instelt;
• kleuren hebben voldoende contrast en informatie hangt nooit alleen aan kleur;
• bediening werkt ook met een extern toetsenbord of schakelaar;
• tijdslimieten zijn te verlengen of uit te zetten.

Uitgangspunt is dat we dit tijdens de bouw testen met de schermlezers van iOS en Android, niet pas aan het eind. Een formeel onderzoek door een onafhankelijke partij raden we aan. Bevat de app kaarten, zie dan toegankelijke kaarten.

1. Verkenning. Wie gebruikt de app, waar, hoe vaak, met welke toestellen en met of zonder verbinding? Daaruit volgt de keuze tussen progressive web app, cross-platform en native, met de beheerkosten van elke route naast elkaar.
2. Klikbaar prototype op het toestel. Geen plaatjes, maar een eerste versie die u op uw eigen telefoon installeert. Zo test u bediening en snelheid voordat het grote werk begint.
3. Achterkant en koppelingen. De meeste apps praten met een server voor gegevens en accounts. Die API bouwen of koppelen we volgens open specificaties; zie API-koppelingen.
4. Bouw in korte rondes. Elke paar weken een nieuwe testversie via TestFlight voor iOS en een gesloten test in Google Play, zodat gebruikers vroeg meekijken.
5. Toegankelijkheid, beveiliging en winkelbeoordeling. Test met schermlezers, controle op opslag van gegevens op het toestel en voorbereiding van de winkelpagina's, privacyverklaringen en demo-accounts.
6. Publicatie en onderhoud. De app gaat live onder het account van uw organisatie. Daarna volgen updates voor nieuwe versies van iOS en Android en voor de jaarlijkse eisen van Google Play.

Hosting van de achterkant kan bij uw organisatie of in beheer; zie cloud- en data-infrastructuur. Gaat er later een aanbesteding komen: wat u in de verkenning van ons krijgt, is zo opgesteld dat u het met alle inschrijvers kunt delen. Een verkenning geeft geen voorkeurspositie en kan gevolgen hebben voor onze deelname aan een latere aanbesteding.

Een paar zaken moeten op naam van uw organisatie staan, anders is de app in de praktijk niet van u.

• De ontwikkelaarsaccounts bij Apple en Google, op naam van de organisatie, met de ontwikkelaar als gebruiker met beperkte rechten. Google vraagt voor een organisatieaccount altijd een D-U-N-S-nummer, Apple alleen van niet-overheidsorganisaties. Vraag het tijdig aan: volgens Google kan dat tot 30 dagen duren en het is gratis.
• De broncode in een repository van uw organisatie, inclusief de configuratie voor het bouwen en ondertekenen van de app.
• Een privacyverklaring op uw website en de privacygegevens die beide winkels per app vragen, afgestemd met uw privacyfunctionaris.
• Een inhoudelijk eigenaar die beslist over functies, teksten en prioriteiten en die de winkelbeoordelingen opvolgt.

Met deze zaken op orde kunt u later van ontwikkelaar wisselen zonder dat gebruikers een nieuwe app moeten installeren. Wilt u verder praten over een app-idee, gebruik dan de contactpagina.