Hoe lang duurt het om een app te maken: echte termijnen

Hoe lang duurt het om een app te maken: het korte antwoord

Hoe lang duurt het om een app te maken? Niemand kan je eerlijk één universeel getal geven, want de duur hangt vooral af van twee dingen die alleen jij weet: hoe groot je eerste versie is en hoeveel uur je er elke week in kunt steken. Een deel van de planning ligt wel vooraf vast: de stappen bij Apple tel je in dagen, niet in maanden. Apple zegt bijvoorbeeld 90% van de inzendingen binnen 48 uur te beoordelen.

De echte hefboom is dus de afbakening. Een app die één ding doet, alleen op iOS, met een stack die je niet pas die dag leert kennen, bouw je in een paar weken regelmatig werk. Een catalogus van twaalf functies op twee platforms kan maanden blijven hangen en nooit uitkomen. Deze gids laat stap voor stap zien waar de tijd heen gaat, zodat je je eigen planning kunt inschatten.

Ik publiceer mijn eigen iOS-apps: Solys, een wekker met minigames, en TradaZen, een tradingsimulator, staan in de App Store. Nolera en Clic werden door Apple afgewezen en daarna verbeterd. De stappen hieronder doorloop ik bij elke release.

Ontwikkeltijd van een mobiele app: waar hangt die van af?

Voordat we het over stappen hebben: dit zijn de factoren die de ontwikkeltijd van een mobiele app bepalen, van zwaarst naar lichtst.

• Het aantal functies in de eerste versie. Dit is veruit de belangrijkste factor. Elke functie voegt schermen, lege toestanden, af te handelen fouten en tests toe.
• Accounts en backend. Een app waarvan de data op de telefoon blijft, is veel eenvoudiger dan een app met registratie en synchronisatie tussen apparaten.
• Betalingen. Een abonnement vraagt configuratie bij Apple, in RevenueCat en in je code, plus aankooptests.
• Eén of twee platforms. Publiceren op iOS en Android betekent twee dossiers, twee reviews en twee testrondes. Ik leg die keuze uit in iOS- en Android-app tegelijk.
• Je beschikbare tijd. Tien uur per week en veertig uur per week geven natuurlijk niet dezelfde planning.
• Je startniveau en het gebruik van AI. AI versnelt het schrijven van code enorm, de rest veel minder. Daar kom ik verderop op terug.

Stap voor stap: waar gaat de tijd heen als je een iOS-app maakt

1. Het idee afbakenen

Deze stap bepaalt alle andere. Je legt het publiek vast, het probleem, de hoofdfunctie, het verdienmodel en wat buiten de eerste versie valt. Duurt dit weken, dan zijn de beslissingen niet genomen. Een programma van eisen van één pagina is genoeg om het af te ronden.

2. Het Apple Developer-account openen

Zonder dit account, voor 99 $ per jaar, kun je niet publiceren, en het Enterprise-programma van Apple is geen vervanging. Voor een particulier zegt Apple dat je contact moet opnemen met support als je je lidmaatschapsbevestiging niet binnen 24 uur na aankoop hebt ontvangen. Voor een bedrijf heb je eerst een D-U-N-S-nummer nodig: Apple rekent tot 5 werkdagen om het te ontvangen, en daarna tot 2 werkdagen voordat de informatie bij Apple binnen is. Start dit parallel aan de ontwikkeling, niet aan het eind. Alle details staan in Apple-ontwikkelaarsaccount: prijs en inschrijving.

3. De hoofdfunctie bouwen

Hier zijn de verschillen het grootst, en ze komen bijna allemaal door de scope. Een goed gedefinieerde functie, met lege toestanden en fouten, bouw je snel, zeker met React Native, Expo en AI. Elke functie die je er "nu we toch bezig zijn" bij doet, maakt deze stap en alle volgende langer. De pagina MVP van een iOS-app helpt je op de juiste plek te snijden.

4. Testen op je iPhone met TestFlight

De simulator is niet genoeg: sommige crashes zie je alleen op een echte telefoon. Interne tests starten zodra je build verwerkt is. Voor externe testers geeft Apple aan dat de eerste build die naar een groep gaat door App Review moet, en dat volgende builds niet per se een volledige review nodig hebben. Reken de eerste keer dus op wat vertraging. Alles staat in TestFlight: je iPhone-app testen.

5. Abonnementen koppelen

De producten aanmaken in App Store Connect, ze koppelen in RevenueCat, de paywall bouwen, aankopen en herstel testen. Eén planningspunt om te kennen: Apple eist dat de eerste in-app-aankoop van elk type samen met een nieuwe versie van de app wordt ingediend. Vergeet je dat, dan gaat je eerste inzending zonder abonnement de deur uit en begin je aan een nieuwe cyclus. Het hele traject staat op de pagina in-app-abonnementen op iOS.

6. De App Store-pagina voorbereiden

Screenshots in de juiste formaten, beschrijving, zoekwoorden, privacyverklaringen, links naar de gebruiksvoorwaarden, notities voor de reviewer. Als alles vooraf klaarstaat, is het een kwestie van uren. Ontdek je de velden pas op de dag van indienen, dan kan het meerdere dagen kosten.

7. De review van Apple

De review zelf is vaak snel, volgens de cijfers van Apple hierboven. Wat tijd kost, zijn afwijzingen: elke afwijzing betekent de reden lezen, corrigeren, opnieuw indienen en wachten op een nieuw antwoord. De echte termijnen en wat ze verlengt, beschrijf ik in doorlooptijd van de App Store-review.

De planning van een app win je aan het begin, door functies te schrappen, en verlies je aan het eind, door de regels van Apple te ontdekken.

Hoe lang duurt het om een app te maken met AI?

AI heeft de duur van stap 3 echt veranderd. Claude, ChatGPT of Cursor schrijven schermen, navigatie en eenvoudige logica in een paar seconden, waar je een paar jaar geleden uren moest zoeken.

Stappen 2, 4, 5, 6 en 7 zijn veel minder veranderd. Zonder toegang tot de consoles en zonder tests op de betreffende apparaten kan een agent de status van het Apple-account, de abonnementen of de weergave niet bevestigen. Die controles vragen een testopstelling, ook als de agent helpt ze te automatiseren. Gevolg: met AI wordt het bouwen korter, maar het deel van de planning voor configuratie, tests en review wordt naar verhouding groter. Ik ga er uitgebreid op in in een iOS-app maken met AI.

De drie dingen die de planning laten ontsporen

1. Van gedachten veranderen tijdens het bouwen. Elk "nu we toch bezig zijn" opent de scope opnieuw. De oplossing: alles wat niet in de eerste versie zit, zet je zwart op wit als buiten scope, en dat wordt het materiaal voor de volgende.
2. De regels van Apple pas aan het eind ontdekken. Ontbrekend demo-account, scherm afgesneden op een kleine iPhone, beoordelingsverzoek op de verkeerde plek, abonnement zonder de verplichte vermeldingen: elke late ontdekking kost een volledige reviewcyclus. De pagina app afgewezen door Apple zet de meest voorkomende redenen op een rij.
3. In je eentje vastlopen op een configuratieprobleem. Een certificaat, een abonnements-ID, een build die niet wil installeren: zulke blokkades vragen vaak maar één goed stukje informatie, maar ze kunnen een project dagenlang stilleggen als niemand je kan helpen.

Waarom "sneller" niet altijd beter is

Een app kan heel snel uitkomen als je de tests op kleine schermen, de afhandeling van netwerkfouten en de controle van aankopen schrapt. Hij komt uit, en gaat stuk bij het eerste contact met echte gebruikers. De eerste beoordelingen in de App Store vergeten dat niet.

Het juiste doel is niet pure snelheid. Het is de vroegste releasedatum die noch de Apple-review, noch de eerste indruk opoffert. Schrap functies, nooit stevigheid.

Een echt ijkpunt: de 26 dagen voor de publicatie van TradaZen

Bij TradaZen was de eerste commit op 21 juni 2026, de eerste TestFlight op 25 juni en de publicatie op 17 juli: 26 kalenderdagen van eerste commit tot App Store. Dat zijn geen 26 voltijdse werkdagen en ook geen gemiddelde voor alle apps. De scope bleef na de release veranderen.

De gedetailleerde tijdlijn van TradaZen onderscheidt de bouwstappen, de reviewproblemen en de pivots. Het is een voorbeeld om met je project te vergelijken, geen releasedatum om over te nemen.

Hoe schat je je eigen termijn in?

In plaats van een getal dat je online vindt, maak je deze berekening voor je project:

1. Schrijf je programma van eisen van één pagina en zet de schermen van de eerste versie op een rij.
2. Schat elk scherm in uren, met lege toestanden en fouten, en tel daar de paywall en de App Store-pagina bij op.
3. Deel door je echte uren per week, niet door de uren waarop je hoopt.
4. Voeg marge toe voor minstens één heen-en-weer met Apple, zeker als het je eerste app is.
5. Start de Apple Developer-inschrijving meteen aan het begin, zodat die het eind nooit blokkeert.

Vind je de uitkomst te lang? Ga dan niet sneller werken: schrap een functie.

Een deadline vastleggen

Een vaste deadline helpt enorm om een strakke scope vast te houden. De iOS Kit verdeelt de weg in vier stappen: de app kiezen die geld kan opleveren, de kern van de app bouwen en testen met TestFlight, het geld koppelen, en daarna publiceren en gevonden worden. Aan jou om voor elke stap een datum te kiezen. De homepage toont die vier stappen om een mobiele app te maken met Claude Code.

Om je eigen termijn in te schatten, vertrekt de gratis diagnose vanuit jouw situatie en de tijd die je elke week hebt, en vertelt je met welke stap je moet beginnen.

Een deadline is een werkkader, geen publicatiegarantie: Apple keurt goed, en jouw tempo telt. Voor het overzicht van het hele traject blijft de pagina een iPhone-app maken het beste startpunt.

Veelgestelde vragen

Hoe lang duurt het om een iPhone-app te maken?

Dat hangt vooral af van de grootte van je eerste versie en het aantal uur dat je er elke week in kunt steken. Een app die één ding doet, alleen op iOS, met tools die je niet pas die dag leert kennen, bouw je in een paar weken regelmatig werk. Een catalogus van twaalf functies op twee platforms kan maanden blijven hangen en nooit uitkomen.

Wat zijn de stappen om een iPhone-app te maken?

Zeven stappen: het idee afbakenen, het Apple Developer-account openen, de hoofdfunctie bouwen, testen op je iPhone met TestFlight, abonnementen koppelen, de App Store-pagina voorbereiden en daarna door de review van Apple komen. De afbakening bepaalt alle andere stappen. Start de Apple Developer-inschrijving parallel aan de ontwikkeling, niet aan het eind.

Hoe lang duurt de goedkeuring van een app door Apple?

Apple zegt minstens 50% van de inzendingen binnen 24 uur te beoordelen, en 90% binnen 48 uur. De review zelf is dus vaak snel. Wat tijd kost, zijn afwijzingen: je moet de reden lezen, corrigeren, opnieuw indienen en dan op een nieuw antwoord wachten. De echte termijnen staan in doorlooptijd van de App Store-review.

Kun je met AI sneller een app maken?

Ja, maar vooral voor het bouwen. Claude, ChatGPT of Cursor schrijven schermen, navigatie en eenvoudige logica in een paar seconden. AI verandert veel minder aan het Apple-account, de tests, de abonnementen, de App Store-pagina en de review. Gevolg: het bouwen wordt korter, maar het deel van de planning voor configuratie, tests en review wordt naar verhouding groter.

Waardoor loopt de planning van een app uit?

Vooral drie dingen: van gedachten veranderen tijdens het bouwen, de regels van Apple pas aan het eind ontdekken en in je eentje vastlopen op een configuratieprobleem. Elke late ontdekking van een Apple-regel kost een volledige reviewcyclus. Om de scope te bewaken, zet je zwart op wit wat niet in de eerste versie zit: dat wordt het materiaal voor de volgende.

Is er een echt voorbeeld van hoe lang het duurt om een iOS-app te publiceren?

Ja: bij TradaZen, een van mijn apps, zitten er 26 kalenderdagen tussen de eerste commit op 21 juni 2026 en de publicatie op 17 juli. Dat zijn geen 26 voltijdse werkdagen en ook geen gemiddelde voor alle apps, en de scope bleef na de release veranderen. Vergelijk dit ijkpunt met je project, zonder het als releasedatum over te nemen.