Publicera en iOS-uppdatering: stegvis lansering på 7 dagar
Av Mehdi Azizi
Publicerad , 10 min
Publicera en iOS-uppdatering: ny version, nytt build, text om nyheter, sedan manuell, automatisk eller stegvis lansering över 7 dagar.
För att publicera en iOS-uppdatering skapar du en ny version i App Store Connect, med ett högre nummer. Du kopplar ett nytt build till den, skriver texten för nyheter (What's New) och skickar den sedan till App Review. Varje ny version går igenom Apples granskning igen, även en enkel buggfix. Innan du skickar in väljer du hur den ska släppas efter godkännandet: manuellt, direkt, tidigast ett visst datum eller som en stegvis lansering över 7 dagar.
Den stegvisa lanseringen påverkar bara automatiska uppdateringar: 1 % av de användarna första dagen, alla den sjunde. Du kan pausa den i upp till 30 dagar totalt, eller avsluta den på en gång. Den här guiden följer Apples hjälpsidor, som jag läste igenom den 3 november 2026.
Jag publicerar uppdateringar av mina iOS-appar med Expo och EAS, bland annat Solys, TradaZen och Nolera. Exemplen längre ner kommer från de lanseringarna.
Publicera en iOS-uppdatering: stegen i ordning
App Store Connects hjälp om nya versioner beskriver det här flödet:
- Under Apps väljer du din app och klickar sedan på knappen + bredvid plattformen.
- Ange ett versionsnummer som är högre än det förra och klicka sedan på Create.
- Gå igenom metadatan: den från versionen som är live kopieras automatiskt.
- Skicka upp ett nytt build, med ett uppräknat buildnummer.
- Testa buildet i TestFlight, lägg till det i versionen och skicka den sedan till App Review.
Två krav innan du börjar. Versionen som är live måste ha statusen Ready for Distribution. Och du behöver en av de här rollerna: Account Holder, Admin, App Manager eller Marketing.
Det finns ingen väg tillbaka. Apple skriver det på samma sida: om en version ställer till problem kan du inte gå tillbaka till den förra. Du måste skapa och skicka in en ny version.
Versionsnummer och buildnummer
Versionen är numret dina kunder ser på din sida i App Store. Buildet identifierar varje uppladdning. Kombinationen av version och build måste vara unik: reglerna och felen som hör till finns i version och buildnummer.
Min konvention, som inte är en regel från Apple: sista siffran ökar vid en buggfix, från 1.4.0 till 1.4.1. Den mittersta ökar vid en ny funktion, från 1.4.1 till 1.5.0. Buildnumret går bara uppåt, från en version till nästa. Med Expo ligger versionen i app.json, och EAS kan räkna upp buildet vid varje produktionsbygge. Hur du sätter upp det finns i publicera en Expo-app med EAS.
Texten om nyheter: vad Apple kräver
Sidan om versionsinformation beskriver fältet What's New in This Version:
- Högst 4 000 tecken.
- Finns inte för första versionen, obligatoriskt för alla följande.
- Kan översättas till varje språk på din sida.
Regel 2.3.12 i App Review Guidelines lägger till ett krav: att tydligt beskriva nya funktioner och ändringar i produkten. En allmän formulering räcker för enkla rättningar av buggar, säkerhet eller prestanda. En viktig ändring måste listas. ”Buggfixar och förbättringar” räcker alltså inte för en version som ändrar din prenumeration eller din huvudskärm.
Apple rekommenderar också, på sin sida om recensioner, att du i versionsanteckningarna nämner rättade problem som kunder har beskrivit i sina recensioner.
Här är tre mallar att anpassa, en per typ av version.
För en buggfix:
Rättningar och stabilitet.
- [Funktion]: [det som inte fungerade] är rättat.
- [Skärm] laddas snabbare.
Tack till er som rapporterade det.
För en ny funktion:
Nytt: [funktionen, med fem ord].
[Det du kan göra nu, i en mening.]
Var du hittar den: [flik] > [knapp].
Även i den här versionen:
- [Synlig förbättring].
- Buggfixar.
För ett flöde som ändras:
[Skärm eller flöde] ändras.
- Det här ändras för dig: [konkret effekt].
- Det här behåller du: [data, inställningar, köp].
En fråga? [Inställningar] > [Hjälp].
Sista raden i buggfixmallen gäller bara om någon verkligen har rapporterat problemet. Skriv aldrig om en nyhet som inte finns i buildet: regel 2.3 kräver metadata som stämmer med appen.
Manuell, automatisk eller datumstyrd lansering
Hjälpen om lanseringsalternativ erbjuder tre:
| Alternativ | Efter Apples godkännande |
|---|---|
| Manuell | Status Pending Developer Release, du publicerar när du vill |
| Automatisk | Versionen släpps direkt vid godkännandet |
| Automatisk, tidigast den... | Den väntar till valt datum och släpps sedan av sig själv |
Vid manuell lansering öppnar du versionen med statusen Pending Developer Release, klickar på Release This Version och bekräftar. Apple varnar för att det kan ta upp till 24 timmar innan den syns i App Store. Ett meddelande på versionens sida erbjuder Cancel This Release för att avbryta. Om versionen väntar i mer än 30 dagar skickar Apple en påminnelse via e-post.
Manuell lansering är till för att välja tidpunkten, till exempel för att publicera samma dag som ett tillkännagivande. Solys 2.0.0, som innehöll en ny version av årsprenumerationen, skickades till granskning i slutet av september 2026 med manuell lansering.
För en rutinversion låter jag lanseringen vara automatisk. Nolera 1.0.2, godkänd den 12 oktober 2026, dök upp i App Store mindre än en minut efter mejlet från Apple, enligt iTunes publika sök-API. Det är en enda observation: räkna med marginal.
Stegvis lansering över 7 dagar
Apples hjälp om stegvis lansering ger det exakta schemat:
| Dag | Andel av användarna |
|---|---|
| 1 | 1 % |
| 2 | 2 % |
| 3 | 5 % |
| 4 | 10 % |
| 5 | 20 % |
| 6 | 50 % |
| 7 | 100 % |
Uppdateringen går ut till ett slumpmässigt urval av de användare som har slagit på automatiska uppdateringar, på kompatibla enheter. De får inte veta att de ingår i urvalet.
Stegvis lansering bromsar bara automatiska uppdateringar. Apple påpekar att vem som helst kan ladda ner den nya versionen från App Store, när som helst. Någon som installerar din app, eller trycker på Update på din sida, kan alltså få den redan första dagen. Det är inget test på 1 % av dina användare: det är en broms på de andra.
För att slå på den öppnar du versionen, scrollar ner till avsnittet Phased Release for Automatic Updates, kryssar i ”Release update over a 7-day period using phased release” och sparar. Du behöver rollen Account Holder, Admin eller App Manager. Alternativet finns kvar fram till statusen Pending Developer Release: du kan alltså slå på det även efter Apples godkännande, så länge versionen väntar på att du släpper den manuellt.
När versionen är godkänd har statusen Ready for Distribution tillägget ”Phased Release”. När de 7 dagarna är slut får appens Admin och App Manager en notis.
Paus, återupptagning och lansering för alla
- Paus: upp till 30 dagar totalt, så många gånger du vill. En paus på 10 dagar lämnar 20 dagar till de följande.
- Återupptagning: lanseringen fortsätter från den dag där du stoppade den.
- Lansering för alla: knappen Release to All Users, uppe till höger i versionen, skickar uppdateringen till alla enheter med automatiska uppdateringar.
- Ta bort från försäljning: det stoppar lanseringen för gott, även om ditt medlemskap i utvecklarprogrammet går ut. Om appen kommer tillbaka till försäljning blir versionen tillgänglig för alla på en gång.
Efter lansering för alla går ingenting längre att ändra, enligt tabellen över redigerbara egenskaper.
Nolera 1.0.2 släpptes utan stegvis lansering. Så här skulle jag använda den under veckan:
| Det du ser | Det du gör | Det som händer |
|---|---|---|
| Krascher eller oroliga recensioner | Paus | De automatiska uppdateringarna stoppas |
| Rättningen är klar | Ny version | Den granskas igen, med en egen lansering |
| Inget onormalt efter 3 eller 4 dagar | Release to All Users | Alla får den |
| Du väntar på svar från Apple | Paus, 30 dagar totalt | Fortsätter från dagen där du stoppade |
Under en paus fortsätter manuella nedladdningar. Kryssa i stegvis lansering för varje version som rör betalningen eller första starten: det är där ett fel kostar mest, och du kan inte gå tillbaka.
När rättningen är brådskande: snabbgranskning
Apple låter dig begära en snabbgranskning (expedited review). Den är bara till för riktiga nödlägen: en kritisk bugg som måste rättas, eller en lansering kopplad till ett evenemang.
- Skicka först in din version. Beskriv buggen i fältet Notes som är till för granskaren.
- Fyll i formuläret för snabbgranskning och välj sedan din app och dess plattform.
- Apple snabbar på granskningen efter tillgänglighet. Inget är garanterat.
För ett evenemang anger du i anteckningarna datumet och din koppling till det. De vanliga väntetiderna finns i granskningstiden i App Store.
Vad som granskas igen, och vad som inte gör det
| Ändring | Det som krävs |
|---|---|
| Native kod, behörigheter, SDK-version | Nytt build, ny version, full granskning |
| Skärmbilder, beskrivning, nyckelord, nyheter | En ny version, granskas tillsammans med den |
| Kampanjtext | Inget: den ändras utan ny inskickning |
| Paus, återupptagning, lansering för alla | Inget: det är lanseringsinställningar |
| Sidhuvud för iOS 27-sidan | Ensamt i Asset Library, eller med en version |
| JavaScript-rättning, med Expo | En fjärruppdatering är möjlig |
Kampanjtexten ändras utan ny inskickning, enligt sidan om versionsinformation. Med Expo ändrar en fjärruppdatering JavaScript, texter och bilder utan att gå via App Store. Expos dokumentation sätter två gränser: native kod, behörigheter och SDK-version kräver en ny binär, och uppdateringarna måste följa App Stores regler.
Mitt fall: en fjärrättning som granskaren aldrig såg
I september 2026 väntade ett build av Nolera på granskning. Jag hade rättat ett fel på skanningsskärmen och publicerat rättningen som fjärruppdatering under väntan. Buildet blev ändå avvisat, för just det redan rättade felet.
Förklaringen finns i dokumentationen för expo-updates: som standard laddar appen ner uppdateringen vid start och tillämpar den vid nästa start. Granskaren installerar appen, startar den en gång och testar koden som ligger i buildet. Samma regel gäller för dina nya användare: deras första session kör koden i buildet.
Sedan dess går varje ändring av startskärmen, paywallen eller huvudfunktionen ut i ett nytt build. Fjärruppdateringen är bara till för dem som redan har appen.
Nollställa betyget med en version
Varje ny version har alternativet Reset rating when this version is released. Enligt Apples hjälp om nollställning gäller det alla länder, behåller skrivna recensioner och kan inte ångras efter lanseringen. Apple rekommenderar att använda det sparsamt, eftersom en sida med få betyg kan avskräcka.
Checklistan innan du skickar in din uppdatering
- Versionsnumret är högre, buildet är uppräknat.
- Buildet är testat i TestFlight, på en liten iPhone och på iPad om din app körs där.
- Nyheterna är skrivna på varje språk, och viktiga ändringar är listade.
- Skärmbilderna visar det nuvarande gränssnittet om det har ändrats.
- Anteckningarna till granskaren säger vad som har ändrats och var det finns.
- Lanseringsalternativet är valt: manuellt om du måste hålla ett datum.
- Stegvis lansering är ikryssad om versionen rör betalningen eller första starten.
- Du vet om en eventuell rättning kan gå ut som fjärruppdatering, eller om den kräver ett build.
Klara granskningen vid varje uppdatering
Varje uppdatering går igenom App Review igen, och ett avslag blockerar din rättning. Review Kit samlar min checklista inför inskickning, mina rättade avslag och två Claude Code-skills som går igenom ditt projekt och din App Store-sida och sedan förbereder ditt svar om Apple avvisar. Hela vägen finns på sidan publicera en app i App Store.
Om du förbereder din första lansering, gör din kostnadsfria diagnos: den sätter stegen i rätt ordning och skickar dig min checklista mot avslag från Apple.
Vanliga frågor
Hur länge pågår stegvis lansering i App Store?
Sju dagar: 1 % av användarna med automatiska uppdateringar första dagen, sedan 2, 5, 10, 20 och 50 %, och 100 % den sjunde. Du kan pausa den i upp till 30 dagar totalt, eller avsluta den när som helst med Release to All Users.
Går en uppdatering av en iOS-app igenom Apples granskning igen?
Ja. Varje ny version, med sitt build och sin metadata, går igenom App Review. Kampanjtexten och lanseringsinställningarna kan däremot ändras utan ny inskickning.
Kan man gå tillbaka till en äldre version av en app i App Store?
Nej. Du måste skapa en ny version, med rättningen, och skicka in den för granskning. Det är därför stegvis lansering och dess paus är användbara.
Får nya användare uppdateringen under en stegvis lansering?
Ja, om de laddar ner appen från App Store. Stegvis lansering styr bara automatiska uppdateringar: vem som helst kan ladda ner den nya versionen när som helst.
Kan man slå på stegvis lansering efter Apples godkännande?
Ja, så länge versionen har statusen Pending Developer Release, alltså med manuell lansering och ännu inte publicerad. När versionen väl är släppt är det för sent för den versionen.
Vad ska stå i versionsanteckningarna för en uppdatering?
Nya funktioner och viktiga ändringar, tydligt listade: det är regel 2.3.12. För en enkel rättning av buggar, säkerhet eller prestanda räcker en allmän formulering. Fältet rymmer 4 000 tecken och kan översättas till varje språk.

