Stegvis lansering i App Store: så fungerar 7-dagarsutrullningen, när du pausar och hur du rättar fel (2026)

En stegvis lansering i App Store (phased release) skickar en versionsuppdatering till en växande andel av användarna med automatiska uppdateringar påslagna under sju dagar, med start på 1 % dag ett och 100 % dag sju. Om du kollar krascher och supportmejl varje dag och pausar så fort något ser fel ut, når ett dåligt bygge en liten grupp människor i stället för hela din användarbas. Stegvis lansering har dock en stor begränsning: den styr bara automatiska uppdateringar. Vem som helst kan fortfarande ladda ner den nya versionen manuellt.

Vad styr stegvis lansering i App Store, och vad styr den inte?

Stegvis lansering styr bara vilka användare med automatiska uppdateringar påslagna som får din versionsuppdatering, och när. Den döljer inte den nya versionen för manuella nedladdningar, och den rullar inte tillbaka någon som redan har den.

Enligt Apples App Store Connect-hjälp får "ett slumpmässigt urval av användare med automatiska uppdateringar på kvalificerade enheter uppdateringen, utan att få någon avisering om att de deltar i den stegvisa lanseringen." Det fungerar för versionsuppdateringar av iOS, macOS och tvOS, så du kan inte använda det för en apps första release. För att ställa in det krävs rollen Account Holder, Admin eller App Manager. Apple skriver också: "Appar och appuppdateringar i stegvis lansering kan laddas ner manuellt från App Store av vem som helst när som helst."

Hur ser schemat för stegvis lansering i App Store ut?

Från och med november 2026 är schemat fast: 1 %, 2 %, 5 %, 10 %, 20 %, 50 % och 100 % under sju dagar, och du kan inte ändra det. Det du styr är när du pausar och när du hoppar direkt till 100 %.

Se varje dag som en kontrollpunkt som slutar med ett beslut: fortsätta eller pausa.

Hur slår du på stegvis lansering i App Store Connect?

Stegvis lansering slås på från versionssidan, under Phased Release for Automatic Updates, när som helst innan uppdateringen går live. Du behöver inte bestämma dig innan du skickar in.

Apple tillåter det medan versionen har statusen Prepare for Submission, Waiting for Review, In Review, Waiting for Export Compliance, Pending Developer Release, Developer Rejected, Rejected eller Metadata Rejected.

1. Under Apps väljer du din app och klickar sedan på versionen du skickar in i sidofältet.
2. Scrolla till Phased Release for Automatic Updates.
3. Välj Release update over a 7-day period using phased release.
4. Klicka på Save. Efter godkännande visas statusen Ready for Distribution med Phased Release bredvid.

Du kan också hantera stegvisa lanseringar via App Store Connect API, vilket är praktiskt om din releaseprocess redan är skriptad.

När ska du pausa en stegvis lansering, och hur fungerar 30-dagarsgränsen?

Pausa så fort någon av era i förväg överenskomna triggers slår till. Pauserna kan sammanlagt uppgå till 30 dagar, och när du återupptar fortsätter utrullningen från den dag där den stannade.

Skriv ner dina triggers före lanseringsdagen, så att ingen sitter och diskuterar dem medan användarna drabbas av buggen. Bra triggers är konkreta: andelen kraschfria sessioner faller under föregående versions baslinje, kassan eller inloggningen misslyckas för en mätbar andel av försöken, eller flera användare rapporterar samma bugg.

För att pausa öppnar du versionen med statusen Ready for Distribution, väljer Pause Phased Release och klickar på Save. För att återuppta väljer du Use Phased Release. Apples exempel: om du pausar i 10 dagar och sedan återupptar har du 20 pausdagar kvar. Du kan pausa hur många gånger du vill inom den totala tiden. För att hoppa över de återstående faserna klickar du på Release to All Users uppe till höger på versionssidan.

Hur ser en stegvis lansering ut när en bugg dyker upp?

När en bugg dyker upp pausar du, rättar den och släpper en ny version med stegvis lansering påslagen igen. De användare som fortfarande väntar på automatiska uppdateringar stannar kvar på föregående version medan du jobbar.

Säg att version 3.4 ersätter din synkmotor. Dag ett får 1 % av användarna med automatiska uppdateringar den, och du kollar kraschrapporteringen och synkfelloggarna två gånger. Dag tre, vid 5 %, dyker ett kluster av synkfel upp på en äldre iOS-version. Du pausar direkt. Betydligt färre användare drabbas än om alla hade fått den, och de användare med automatiska uppdateringar som ännu inte nåtts stannar på 3.3.

Därefter rättar du buggen och skickar in 3.4.1 med stegvis lansering påslagen. Testa fixen i ett release-bygge, inte bara i debug; vår testplan för release-byggen går igenom det steget. Skriv tydligt i versionsinformationen för 3.4.1 att synken är åtgärdad; våra exempel på versionsinformation visar hur. Om fixen är brådskande och du är säker på den kan du använda Release to All Users efter godkännandet i stället för att vänta ytterligare en vecka.

Ytterligare ett skydd: lägg den nya synkmotorn bakom en flagga på serversidan. En paus stoppar uppdateringen från att spridas, men en flagga låter dig stänga av den riskabla koden för dem som redan har installerat 3.4. De två fungerar bra tillsammans.

Vad har andra utvecklare stött på när de pausat en stegvis lansering?

Offentliga trådar visar samma mönster: utvecklare pausar en buggig version och är sedan osäkra på vad en efterföljande stegvis lansering innebär för användare som redan fått den. Apples dokumentation besvarar inte det, så planera som om fixen behöver en egen utrullning.

• En utvecklare på Apple Developer Forums berättade att de "märkte en krasch, pausade utrullningen av uppdateringen, patchade appen, laddade upp den och startade en ny stegvis utrullning" med under 10 % av användarna på det dåliga bygget. De frågade om samma användare skulle få den nya utrullningen. Tråden fick aldrig något officiellt svar; ett svar menade att användare på 8.0 "borde få en uppdatering om att 8.1 finns tillgänglig så fort den släpps."
• I en annan forumtråd skrev en utvecklare att de "stannade på 1 %" med version 15.0.1 på grund av en kritisk bugg och ville sprida ut 15.0.2 stegvis också, i hopp om att 15.0.1 skulle "i praktiken hoppas över för majoriteten av användarna." Ett tidigare svar i tråden föreslog att begära en påskyndad granskning medan den buggiga versionen var pausad, och eventuellt ta bort appen från försäljning "så att inga nya användare hämtar den trasiga versionen." Innan du gör det, kom ihåg regeln om borttagning från försäljning i rutan ovan.
• Teamet bakom releaseverktyget Tramlines anteckningar om butikernas egenheter dokumenterar att en ny release "helt enkelt avbryter den pågående utrullningen", och att den äldre versionen går över till REPLACED_WITH_NEW_VERSION med sin stegvisa lansering markerad som COMPLETE. Samma anteckningar säger att en paus "inte kan göra något åt de användare som redan fått uppdateringen."

I alla tre fallen köpte pausen bara tid. Lösningen var alltid en ny version, och ingen kunde räkna med att samma grupp skulle uppdateras först. Därför är flaggor på serversidan och en hotfix-gren som snabbt kan släppas viktigare än pausknappen.

Hur står sig stegvis utrullning på Google Play i jämförelse?

Stegvis utrullning (staged rollout) på Google Play använder en procentsats som du själv väljer och höjer manuellt. Efter ett stopp når en återupptagning samma grupp användare. Planera utrullningarna i de två butikerna var för sig.

Enligt Play Console-hjälpen "ökar appens procentsats för stegvis utrullning inte automatiskt", och stegvisa utrullningar "kan bara användas för appuppdateringar, inte när en app publiceras för första gången." Efter ett stopp stannar användare som redan fått versionen kvar på den, och Google rekommenderar att du släpper en ny version med ett åtgärdat bundle i stället för att återuppta en trasig. Produktionsutrullningar kan begränsas till specifika länder, men när en utrullning har startat kan du inte ta bort länder. Om din nästa Android-uppdatering också måste uppfylla det nya mål-SDK:t, se vår guide om mål-API-nivå 36 på Google Play.

Vad ska du kontrollera innan du startar en stegvis lansering?

Innan utrullningen startar, se till att stegvis lansering är sparad på versionen, att dina baslinjer och paustriggers är nedskrivna och att en fix kan släppas snabbt. Använd den här checklistan:

• Stegvis lansering vald och sparad på versionssidan
• Dashboards för kraschrapportering och backendfel bokmärkta, med baslinjer från föregående version
• Nedskrivna paustriggers som alla som kan trycka på knappen är överens om
• Riskabla funktioner bakom flaggor på serversidan
• En namngiven person som kontrollerar mätvärdena var och en av de 7 dagarna
• En hotfix-gren redo, plus vår checklista för App Store-inskickning för det uppföljande bygget
• Ändringar i butikssidan väntar tills utrullningen når alla

Om du hellre lämnar över själva releasen täcker vår tjänst för App Store-inskickning uppsättning av App Store Connect och Play Console, förberedelse inför granskning och releaser i båda butikerna för $599 (avgifter för utvecklarkonton tillkommer). För en second opinion på en riskabel uppdatering, mejla yagyeshsrbobde@gmail.com med din app och vad som ändras.