Gefaseerde release in de App Store: de 7-daagse uitrol, pauzeren en een fix uitbrengen (2026)

Een gefaseerde release in de App Store stuurt een versie-update in zeven dagen naar een steeds groter deel van de gebruikers met automatische updates, te beginnen met 1% op dag één en tot 100% op dag zeven. Als je elke dag crashes en supportmail controleert en pauzeert zodra er iets mis lijkt, bereikt een slechte build een kleine groep mensen in plaats van al je gebruikers. Een gefaseerde release heeft wel één grote beperking: hij regelt alleen automatische updates. Iedereen kan de nieuwe versie nog steeds handmatig downloaden.

Wat regelt een gefaseerde release in de App Store wel, en wat niet?

Een gefaseerde release bepaalt alleen welke gebruikers met automatische updates je versie-update krijgen, en wanneer. De nieuwe versie wordt niet verborgen voor handmatige downloads, en wie hem al heeft, wordt niet teruggezet.

Volgens de App Store Connect Help van Apple krijgt "een willekeurige steekproef van gebruikers met automatische updates op geschikte apparaten de update, zonder melding dat ze deelnemen aan de gefaseerde release." Het werkt voor versie-updates van iOS, macOS en tvOS, dus voor de eerste release van een app kun je het niet gebruiken. Om het in te stellen heb je de rol Account Holder, Admin of App Manager nodig. Apple schrijft ook: "Apps en app-updates in een gefaseerde release kunnen op elk moment door iedereen handmatig uit de App Store worden gedownload."

Wat is het schema van een gefaseerde release in de App Store?

Per november 2026 ligt het schema vast op 1%, 2%, 5%, 10%, 20%, 50% en 100% in zeven dagen, en je kunt het niet aanpassen. Jij bepaalt wanneer je pauzeert en wanneer je direct naar 100% springt.

Zie elke dag als een controlepunt dat eindigt met één beslissing: doorgaan of pauzeren.

Hoe zet je een gefaseerde release aan in App Store Connect?

Je zet een gefaseerde release aan op de versiepagina, onder Phased Release for Automatic Updates, op elk moment voordat de update live gaat. Je hoeft dit niet vóór het indienen te beslissen.

Apple staat het toe zolang de versie de status Prepare for Submission, Waiting for Review, In Review, Waiting for Export Compliance, Pending Developer Release, Developer Rejected, Rejected of Metadata Rejected heeft.

1. Selecteer in Apps je app en klik in de zijbalk op de versie die je indient.
2. Scrol naar Phased Release for Automatic Updates.
3. Selecteer Release update over a 7-day period using phased release.
4. Klik op Save. Na goedkeuring toont de status Ready for Distribution met Phased Release ernaast.

Je kunt gefaseerde releases ook beheren via de App Store Connect API, handig als je releasepipeline al gescript is.

Wanneer pauzeer je een gefaseerde release, en hoe werkt de limiet van 30 dagen?

Pauzeer zodra een van je vooraf afgesproken triggers afgaat. Pauzes mogen samen maximaal 30 dagen duren, en als je hervat, gaat de uitrol verder vanaf de dag waarop hij stopte.

Leg je triggers vóór de lanceringsdag vast, zodat niemand erover discussieert terwijl gebruikers tegen de bug aanlopen. Goede triggers zijn concreet: crashvrije sessies zakken onder de basislijn van de vorige versie, afrekenen of inloggen mislukt bij een meetbaar deel van de pogingen, of meerdere gebruikers melden dezelfde bug.

Om te pauzeren open je de versie met status Ready for Distribution, selecteer je Pause Phased Release en klik je op Save. Om te hervatten selecteer je Use Phased Release. Het voorbeeld van Apple: als je 10 dagen pauzeert en dan hervat, heb je nog 20 dagen pauzetijd over. Binnen dat totaal mag je zo vaak pauzeren als je wilt. Om de resterende fasen over te slaan, klik je rechtsboven op de versiepagina op Release to All Users.

Hoe ziet een gefaseerde release eruit als er een bug opduikt?

Als er een bug opduikt, pauzeer je, los je hem op en breng je een nieuwe versie uit, opnieuw met gefaseerde release aan. Gebruikers die nog op hun automatische update wachten, blijven intussen op de vorige versie.

Stel dat versie 3.4 je sync-engine vervangt. Op dag één krijgt 1% van de gebruikers met automatische updates hem, en je controleert twee keer je crashreporter en sync-foutlogs. Op dag drie, bij 5%, verschijnt een cluster sync-fouten op één oudere iOS-versie. Je pauzeert meteen. Er zijn veel minder gebruikers getroffen dan wanneer iedereen de update had gekregen, en gebruikers met automatische updates die nog niet aan de beurt waren, blijven op 3.3.

Daarna los je de bug op en dien je 3.4.1 in met gefaseerde release aan. Test de fix in een release-build, niet alleen in debug; ons testplan voor release-builds behandelt die stap. Zeg in de release notes van 3.4.1 duidelijk dat sync is opgelost; onze voorbeelden van release notes laten zien hoe. Is de fix dringend en heb je er vertrouwen in, gebruik dan na goedkeuring Release to All Users in plaats van nog een week te wachten.

Nog één vangnet: zet de nieuwe sync-engine achter een server-side flag. Pauzeren voorkomt dat de update zich verder verspreidt, maar met een flag zet je de riskante code uit voor mensen die 3.4 al hebben geïnstalleerd. Die twee vullen elkaar goed aan.

Waar liepen andere ontwikkelaars tegenaan bij het pauzeren van een gefaseerde release?

Openbare threads laten hetzelfde patroon zien: ontwikkelaars pauzeren een versie met bugs en weten daarna niet zeker wat een volgende gefaseerde release doet voor gebruikers die de foute versie al hebben. De documentatie van Apple geeft daar geen antwoord op, dus plan alsof de fix een eigen uitrol nodig heeft.

• Een ontwikkelaar op de Apple Developer Forums meldde dat hij of zij "een crash opmerkte, de uitrol van de update pauzeerde, de app patchte, hem uploadde en een nieuwe gefaseerde uitrol startte", terwijl minder dan 10% van de gebruikers de slechte build had. De vraag was of dezelfde gebruikers de nieuwe uitrol als eerste zouden krijgen. De thread kreeg nooit een officieel antwoord; volgens één reactie "zouden gebruikers van 8.0 een melding moeten krijgen dat er een 8.1-update beschikbaar is zodra die uitkomt."
• In een andere forumthread schreef een ontwikkelaar dat versie 15.0.1 vanwege een kritieke bug "op 1% was gestopt" en dat 15.0.2 ook gefaseerd moest uitkomen, in de hoop dat 15.0.1 "voor de meeste gebruikers vrijwel overgeslagen" zou worden. Een eerdere reactie in die thread stelde voor om een versnelde review aan te vragen terwijl de versie met bugs gepauzeerd stond, en eventueel de app uit de verkoop te halen "zodat geen nieuwe gebruikers de foute versie binnenhalen." Denk voordat je dat doet aan de regel over uit de verkoop halen in de waarschuwing hierboven.
• Het team achter de releasetooling van Tramline's store-quirks-notities documenteert dat het starten van een nieuwe release "de bestaande uitrol gewoon annuleert", waarna de oudere versie naar REPLACED_WITH_NEW_VERSION gaat en de gefaseerde release ervan als COMPLETE wordt gemarkeerd. Dezelfde notities zeggen dat een pauze "niets kan doen aan de gebruikers die de update al hebben ontvangen."

In alle drie de gevallen leverde pauzeren alleen tijd op. De oplossing was steeds een nieuwe versie, en niemand kon erop rekenen dat dezelfde groep als eerste werd geüpdatet. Daarom zijn server-side flags en een hotfix-branch die je snel kunt uitbrengen belangrijker dan de pauzeknop.

Hoe verhoudt de gefaseerde uitrol in Google Play zich hiertoe?

De gefaseerde uitrol (staged rollout) in Google Play gebruikt een percentage dat je zelf kiest en handmatig verhoogt. Na een stop bereikt een hervatting dezelfde groep gebruikers. Plan de uitrol in beide stores dus apart.

Volgens de Play Console Help "wordt het percentage van de gefaseerde uitrol van je app niet automatisch verhoogd", en gefaseerde uitrol "kan alleen worden gebruikt voor app-updates, niet bij de eerste publicatie van een app." Na een stop blijven gebruikers die de versie al hebben ontvangen daarop, en Google raadt aan een nieuwe versie met een gecorrigeerde bundle uit te brengen in plaats van een kapotte versie te hervatten. Productie-uitrol kan tot specifieke landen worden beperkt, maar zodra die is gestart, kun je geen landen meer verwijderen. Moet je volgende Android-update ook aan de nieuwe target SDK voldoen, lees dan onze gids over target API level 36 in Google Play.

Wat controleer je voordat je een gefaseerde release start?

Zorg er vóór de start van de uitrol voor dat de gefaseerde release op de versie is opgeslagen, dat je basislijnen en pauzetriggers zijn vastgelegd en dat een fix snel kan worden uitgebracht. Gebruik deze checklist:

• Gefaseerde release geselecteerd en opgeslagen op de versiepagina
• Dashboards voor crashrapportage en backendfouten als bladwijzer, met basislijnen van de vorige versie
• Schriftelijke pauzetriggers waarover iedereen die op de knop kan drukken het eens is
• Riskante functies achter server-side flags
• Een vaste persoon die op elk van de 7 dagen de metrics controleert
• Een klaarstaande hotfix-branch, plus onze App Store-checklist voor indienen voor de vervolgbuild
• Wijzigingen aan de storevermelding uitgesteld tot de uitrol iedereen heeft bereikt

Besteed je de release liever uit? Onze App Store-indieningsservice omvat het inrichten van App Store Connect en Play Console, voorbereiding op de review en releases in beide stores voor $599 (kosten voor ontwikkelaarsaccounts komen daar los bij). Wil je een second opinion over een riskante update, mail dan naar yagyeshsrbobde@gmail.com met je app en wat er verandert.