Wat er gebeurt voordat je app in de App Store staat

"Het is toch maar een simpele app?" Die zin krijg ik regelmatig, en ik snap hem ook. Je gebruikt tientallen apps per dag en de meeste doen precies een ding. Wat je niet ziet, is alles wat er omheen zit. Ik heb er inmiddels vier in de App Store staan, en ik kan het dus vrij precies laten zien.

De beoordeling van Apple is niet het probleem

Laat ik beginnen met het deel waar iedereen bang voor is, want dat blijkt in de praktijk het makkelijkste stuk. Sommetjes Leren diende ik op 13 oktober 's avonds in. De volgende ochtend even voor negen ging hij in beoordeling en ruim een uur later stond hij in de store. Nog geen twaalf uur tussen indienen en live.

Ik heb wel afwijzingen gehad, best vaak zelfs in het begin, maar nooit een op de app zelf. Het waren altijd kleine dingen die ik vergeten was: een versienummer dat niet klopte, een ontbrekende toelichting waarom de app de camera nodig heeft. Je komt dan niet eens tóé aan de inhoudelijke beoordeling. Je struikelt in de aanloop.

Dat is eigenlijk geruststellend en vervelend tegelijk. Geruststellend, want Apple gaat niet moeilijk doen over je idee. Vervelend, want de struikeldraden liggen in het administratieve deel, en dat is nou net het deel waarvan mensen denken dat het niks voorstelt.

De drieëntwintig talen die er niet waren

Het mooiste voorbeeld daarvan is meteen de vervelendste bug die ik in een app heb gehad, en hij zat niet eens in de code die iets doet.

Sommetjes Leren staat in drieëntwintig talen in de store. Alleen: na de eerste release waren die talen niet zichtbaar. Alle vertalingen zaten erin, je zag er niets van.

Dus ik zocht het uit en bracht versie 1.0.11 uit. De fix leek te kloppen: de vertaalbestanden stonden netjes op schijf. Wat ik over het hoofd zag, was dat ze niet geregistreerd waren in het Xcode-project zelf. Twee plekken die je met de hand moet bijwerken, en zonder die registratie komen de bestanden gewoon niet mee in de build. Ze stonden er wel, ze deden niet mee.

Dat kostte een tweede ronde. Versie 1.0.12 loste het echt op. In de tijdlijn ziet dat er zo uit:

• 14 oktober, 1.0 live
• 15 oktober, 1.0.11 live, fix die niet werkte
• 16 oktober, 1.0.12 live, fix die wel werkte

Drie dagen, drie versies. En de les die ik eruit haalde: op schijf staan is niet hetzelfde als in de build zitten. Je merkt het verschil pas als de store je vermelding toont, want lokaal werkte alles gewoon.

De vierde versie, 1.0.13 in december, was geen bug. Sommetjesleren.nl ging van zes naar vijf niveaus, dus de app moest mee. Dat hoort er ook bij: een app die aan een website of systeem hangt, verandert mee als dat systeem verandert.

Waar de tijd echt in gaat zitten

Programmeren is niet het dure deel. Het opzetten van een nieuwe app in de App Store en de Play Store kost echt veel tijd, en dat is werk dat je maar half kunt versnellen.

Je moet beschrijvingen schrijven. Je moet vooral afbeeldingen maken die laten zien wat de app kan, in de precieze formaten die de stores eisen. Komt er meertaligheid bij, dan vermenigvuldigt dat werk zich gewoon. Bij drieëntwintig talen weet je wat dat betekent.

Push-notificaties zijn ook zoiets. Het koppelen van de certificaten daarvoor is een stuk minder rechttoe rechtaan dan het op papier lijkt. En elke app heeft een eigen privacyverklaring nodig, plus een opgave aan Apple en Google over welke data je precies verzamelt en waarvoor.

Het eerlijke antwoord anno nu: AI neemt een flink deel van dat schrijfwerk van me over. Beschrijvingen, vertalingen, privacyteksten. Dat scheelt echt. Maar het moet nog steeds gecontroleerd, ingevoerd en aangeleverd worden, en dat blijft mensenwerk.

Tel het bij elkaar op en je bent ongeveer een dag bezig voordat er ook maar een regel code geschreven is. Dat werk verdwijnt niet als de app klein is.

En dan is hij af. Of niet.

Hier wordt het interessant, want "wat kost onderhoud" heeft geen enkel antwoord. Kijk naar twee van mijn apps.

Tickies Scanner staat sinds februari 2025 in de store en draait nog altijd op versie 1.0. Negentien maanden, geen enkele update. Dat komt doordat hij vanaf het begin goed in elkaar zit en doordat de API het zware werk doet. De app scant en stuurt door, de logica zit aan de andere kant. Ik krijg er nauwelijks verzoeken over van klanten, want hij doet wat hij moet doen.

Credies Urenbeheer ging in maart 2026 live en kreeg begin september nog een update. Een half jaar later dus nog steeds in beweging.

Dat verschil is geen kwestie van kwaliteit. Het is een kwestie van wat de app is. Een scanner die een code leest en doorstuurt, is klaar. Een app waarin mensen uren en tegoeden beheren, groeit mee met wat die mensen nodig hebben.

Het onderhoud dat je niet zelf kiest

Er is nog een categorie onderhoud, en die is minder leuk, want je kiest er niet voor.

Onlangs moest ik twee apps bijwerken voor de Google Play Store. Niet omdat er iets stuk was, en niet omdat iemand er iets aan wilde veranderen. Google heeft aangescherpt hoe zij vinden dat je een app moet bouwen en uitrollen, zodat hij overal blijft werken. Dan moet je mee, anders vliegt hij er op termijn uit.

In de praktijk betekent dat: je app updaten naar de laatste versies van alle pakketten die je gebruikt, met alle eigenaardigheden die daarbij komen kijken. Dat is echt werk, aan een app waaraan functioneel niets veranderd is.

Apple en Google doen dit elk jaar. Reken er dus op dat zelfs een app die je nooit aanpast, af en toe aandacht vraagt. Wie je dat niet vertelt voordat je begint, doet je tekort.

Op wiens naam staat de app eigenlijk?

Een vraag die zelden vooraf gesteld wordt, maar wel uitmaakt. Mijn ontwikkelaarsaccount staat op mijn naam, en de apps die ik bouw staan daar dus onder.

Wil een klant de app onder zijn eigen naam in de store hebben, dan kan dat, maar dan komen er nogal wat stappen bij. Eigen accounts bij Apple en Google, eigen certificaten, overdracht van de app. En gaat het om een betaalde app, dan komt de Amerikaanse belastingdienst er ook nog bij kijken, want die wil weten wie het geld ontvangt.

Niets onoverkomelijks, maar het is geen vinkje. Weet vooraf wat je wil, dan is het een keuze in plaats van een verrassing.

Dus: is het een simpele app?

Soms wel. Tickies Scanner is een simpele app en dat is precies zijn kracht: negentien maanden lang doet hij zonder mopperen zijn werk aan de deur van musea en attracties.

Maar simpel in gebruik is iets anders dan weinig werk. Tussen "ik wil een app" en "hij staat in de store" zit een dag voorbereiding, een reeks administratieve struikeldraden, en daarna een platform dat elk jaar zijn eisen verhoogt.

Als je weet wat je koopt, valt dat allemaal reuze mee. Als je het niet weet, voelt elke rekening als een tegenvaller. Daarom schrijf ik het maar gewoon op.

Wil je weten wat dat voor jouw idee betekent? Op app laten maken staat wat een app kost en welke apps ik wel en niet bouw.