Een website zet je met één handeling terug, een app-update niet. Zodra iemand jouw versie heeft geïnstalleerd, staat die op zijn toestel tot hij zelf bijwerkt, ook als je de uitrol meteen daarna stopzet. Daarom breng je een app voorzichtiger uit dan een site: eerst naar een kleine groep, en met een serverkant die de oudere versies gewoon blijft bedienen.
Een app-versie leeft op het toestel van je gebruiker, niet op jouw server. Dat verandert alles aan hoe je uitbrengt.
Bij een webapplicatie is terugdraaien één handeling: je zet de vorige versie terug en bij het volgende laden heeft iedereen die weer. In een store bestaat die knop niet. Je publiceert geen versie naar gebruikers, je zet er een klaar die zij ophalen, en wat opgehaald is staat op hun toestel.
De uitrol stopzetten, de versie uit de verkoop halen en een herstel indienen doen daarom alle drie hetzelfde niet: ze halen de kapotte versie niet van de telefoons die hem al hebben. Die mensen blijven erop tot ze zelf bijwerken, en een deel doet dat pas veel later of nooit. De vraag verschuift daarmee van hoe snel je kunt herstellen naar hoeveel mensen het probleem te zien krijgen. Daar gaat de rest van deze pagina over: klein uitrollen, en zorgen dat wat mis kan gaan aan de serverkant zit, want dat is het enige deel dat je wel kunt terugzetten.
Een spoedherstel is geen deploy maar een inzending, en daar zit een beoordelaar tussen.
Apple beoordeelt niet alleen je eerste versie. In de eigen beschrijving van het reviewproces staat het expliciet: alle apps en app-updates die bij App Store Connect worden ingediend, worden beoordeeld. Bij Google Play gaan updates eveneens langs een controle. Zolang een store tussen jou en je gebruikers staat, bestaat "even snel fixen" dus niet.
Apple publiceert wel hoe snel een beoordeling gemiddeld gaat, maar een gemiddelde is geen toezegging. En bij een spoedherstel is de vervelende uitkomst niet traagheid maar een afwijzing: dan begint de ronde opnieuw op het moment dat je dat het minst kunt gebruiken.
Voor echte noodgevallen bestaat een verzoek tot versnelde beoordeling. Apple noemt het herstellen van een kritieke bug zelf als voorbeeld en vraagt om de stappen waarmee de fout te reproduceren is. Het is geen knop voor elke release, en het levert voorrang op, geen goedkeuring.
Klein beginnen is de enige manier om een fout bij weinig mensen tegen te komen in plaats van bij iedereen.
Phased release geeft de nieuwe versie eerst aan een klein, willekeurig deel van je gebruikers en daarna aan een steeds groter deel, tot iedereen aan de beurt is. Twee dingen worden vaak gemist: het geldt alleen voor mensen met automatische updates, want iedereen kan de versie ook handmatig ophalen. En je kunt pauzeren, of de versie alsnog in één keer naar iedereen zetten.
Bij een gefaseerde uitrol kies en verhoog je het percentage zelf; het loopt niet vanzelf op. Gaat er iets mis, dan zet je de uitrol stop en krijgen er volgens Google geen extra gebruikers meer die versie. Hervatten kan later.
Crashmeldingen en het cijfer waar je op let, moeten al staan voordat je begint, anders is dat eerste kleine deel geen test maar uitstel. Zie meten of je app gebruikt wordt.
En dan de zin uit Google's documentatie die dat verschil vastlegt: gebruikers die de versie al hadden ontvangen, blijven op die versie. Stopzetten beperkt de schade, het draait niets terug. Een herstel is altijd een nieuwe versie, en die moet zelf ook weer langs de beoordeling.
Jouw server praat met alle versies die nog in omloop zijn, ook die van iemand die lang niet heeft bijgewerkt.
Op het web draait er één versie: die van jou. Bij een app draaien er altijd meerdere tegelijk. Daar volgt één harde regel uit: wijzigingen aan de serverkant moeten achterwaarts verenigbaar zijn. Hernoem je een veld, haal je een endpoint weg of verander je een antwoordformaat, dan breek je niet de nieuwe app maar elke oudere versie die nog op toestellen staat. Dat is precies de groep die je niet met een herstel kunt bereiken, want daarvoor moeten ze eerst bijwerken. En iemand bij wie de app ineens fouten geeft, zoekt geen update, die verwijdert hem.
Ook in een jaar waarin je zelf niets wilt wijzigen, dwingen Apple en Google je tot een nieuwe versie.
Google Play eist dat nieuwe apps en updates op een recente Android-versie zijn gericht, en dat vereiste niveau schuift periodiek op. Voldoe je niet, dan kun je geen update meer uitbrengen en blijft je app alleen beschikbaar op toestellen waarvan het besturingssysteem gelijk of ouder is dan waar je app op gericht is. Iemand met een nieuwer toestel krijgt te zien dat de app niet te installeren is. Uitstel aanvragen kan, maar dat is uitstel.
Apple regelt hetzelfde via de SDK: wat je naar App Store Connect uploadt, moet met een recente Xcode-versie en SDK gebouwd zijn, en die eis schuift eveneens op. Versienummers en datums noemen we hier bewust niet, want die veranderen; de twee bronpagina's zijn leidend.
Het mechanisme is wat telt: er komt periodiek een moment waarop je app opnieuw gebouwd, getest en ingediend moet worden om beschikbaar te blijven, ook als je zelf niets wilde veranderen. Dat werk hoort in je begroting, bij de terugkerende kosten van een eigen app.
Wat je opschrijft en wanneer je uitbrengt, bepalen samen hoeveel onrust een release oplevert.
"Bugfixes en verbeteringen" wordt door twee groepen gelezen: gebruikers die beslissen of ze de update binnenhalen, en de beoordelaar die kijkt of je inzending klopt met wat je beweert. Voor allebei zegt die zin niets. Schrijf op wat er is veranderd in de woorden van de gebruiker: wat is opgelost, wat is nieuw en waar kwam het vandaan. Wie zijn eigen gemelde probleem terugleest, meldt het volgende ook.
Over het ritme: uitbrengen zodra iets toevallig af is voelt efficiënt, maar het maakt je onrustig. Elke release is een beoordeling, een uitrol en een periode waarin je moet opletten. Met een vast ritme bepaal jij wanneer dat moment valt en weten je gebruikers wat ze kunnen verwachten. Wat niet kan wachten, doe je aan de serverkant.
Loop je nog tegen de eerste publicatie aan, dan heeft die eigen valkuilen per platform: je app in de App Store zetten en je eerste app publiceren in de Google Play Console. De app store launch checklist loopt ze punt voor punt met je door.
Niet zoals bij een website. Je kunt de verspreiding stopzetten en de versie uit de verkoop halen, maar wie hem al heeft geïnstalleerd houdt hem tot hij zelf bijwerkt. Herstellen doe je met een nieuwe versie.
Ja. Apple schrijft dat alle apps en app-updates die je indient worden beoordeeld, en bij Google Play gaan updates ook langs een controle. Een spoedherstel is dus een inzending, geen deploy.
Apple laat je een versnelde beoordeling aanvragen bij bijzondere omstandigheden en noemt een kritieke bug als voorbeeld. Lever de stappen mee om de fout te reproduceren. Het geeft voorrang in de rij, geen goedkeuring.
Ja. Je kiest zelf welk deel van je gebruikers de versie krijgt. Zet je de uitrol stop, dan krijgen geen extra gebruikers hem meer, en hervatten kan later. Wie de versie al had ontvangen, blijft erop.
Dan breken die oude versies, en dat is precies de groep die je niet direct kunt bereiken. Voeg velden toe in plaats van ze te wijzigen, en zet de serverwijziging live vóór de app-versie die hem nodig heeft.
Meestal wel. Google Play eist dat nieuwe versies op een recente Android-versie zijn gericht en Apple eist een recente SDK. Die eisen schuiven periodiek op, dus je app moet af en toe opnieuw gebouwd en ingediend worden.
Weet je nog niet zeker of dit idee het uitbrengen en onderhouden waard is? Stuur ons je idee. Wij leveren in één werkdag een klikbaar prototype waarmee je de flow met echte mensen kunt toetsen, voordat je aan een app en alles wat daarna komt begint.
Een korte intake volgt na je inschrijving. Daarna stemmen we scope en datum af.
We nemen contact op om de intake in te plannen.
We gebruiken cookies om je ervaring te verbeteren en het gebruik van de site te meten.