Udgiv en iOS-opdatering: gradvis udrulning over 7 dage
Af Mehdi Azizi
Udgivet , 10 min.
Udgiv en iOS-opdatering: ny version, nyt build, tekst til nyheder, og så manuel, automatisk eller gradvis udgivelse over 7 dage.
For at udgive en iOS-opdatering opretter du en ny version i App Store Connect med et højere nummer. Du knytter et nyt build til den, skriver teksten til "What's New" og sender den til App Review. Hver ny version skal gennem Apples review igen, også en simpel fejlrettelse. Før du sender den, vælger du, hvordan den skal udkomme efter godkendelsen: manuelt, med det samme, tidligst på en bestemt dato eller med gradvis udrulning over 7 dage.
Gradvis udrulning påvirker kun automatiske opdateringer: 1 % af de brugere første dag, alle på syvendedagen. Du kan sætte den på pause i op til 30 dage i alt eller afslutte den med det samme. Guiden følger Apples hjælpesider, gennemlæst den 3. november 2026.
Jeg udgiver opdateringer til mine iOS-apps med Expo og EAS, blandt andet Solys, TradaZen og Nolera. Eksemplerne længere nede kommer fra de udgivelser.
Udgiv en iOS-opdatering: trinene i rækkefølge
App Store Connects hjælp om nye versioner beskriver forløbet sådan:
- Under Apps vælger du din app og klikker på +-knappen ved siden af platformen.
- Indtast et versionsnummer, der er højere end det forrige, og klik på Create.
- Gennemgå metadataene: dem fra den version, der er live, bliver kopieret automatisk.
- Upload et nyt build med et højere buildnummer.
- Test buildet i TestFlight, tilføj det til versionen og send den til App Review.
To betingelser, før du går i gang. Den version, der er live, skal have status Ready for Distribution. Og du skal have en af disse roller: Account Holder, Admin, App Manager eller Marketing.
Der findes ingen vej tilbage. Apple skriver det på samme side: hvis en version giver problemer, kan du ikke vende tilbage til den forrige. Du skal oprette og indsende en ny version.
Versionsnummer og buildnummer
Versionen er det nummer, dine kunder ser på din side. Buildet identificerer hver upload. Kombinationen af version og build skal være unik: reglerne og de tilhørende fejl står i version og buildnummer.
Min konvention, som ikke er en regel fra Apple: det sidste tal stiger ved en fejlrettelse, fra 1.4.0 til 1.4.1. Det midterste stiger ved en ny funktion, fra 1.4.1 til 1.5.0. Buildnummeret stiger bare hele tiden, fra version til version. Med Expo ligger versionen i app.json, og EAS kan tælle buildet op ved hvert production-build. Opsætningen står i udgiv en Expo-app med EAS.
Teksten til "What's New": det kræver Apple
Siden om versionsinformation beskriver feltet What's New in This Version:
- Højst 4.000 tegn.
- Findes ikke til den første version, obligatorisk for alle de efterfølgende.
- Kan oversættes til hvert sprog på din side.
Regel 2.3.12 i App Review Guidelines tilføjer et krav: nye funktioner og ændringer i produktet skal beskrives tydeligt. En generel formulering er nok til simple rettelser af fejl, sikkerhed eller ydeevne. En vigtig ændring skal stå på listen. "Fejlrettelser og forbedringer" er altså ikke nok til en version, der ændrer dit abonnement eller din hovedskærm.
Apple anbefaler også på sin side om anmeldelser, at du i noterne nævner rettede problemer, som kunder har beskrevet i deres anmeldelser.
Her er tre skabeloner, du kan tilpasse, én til hver type version.
Til en fejlrettelse:
Rettelser og stabilitet.
- [Funktion]: [det, der ikke virkede] er rettet.
- [Skærm] indlæses hurtigere.
Tak til alle, der meldte det.
Til en ny funktion:
Nyt: [funktionen, i fem ord].
[Det, du kan nu, i én sætning.]
Her finder du den: [fane] > [knap].
Også i denne version:
- [Synlig forbedring].
- Fejlrettelser.
Til et forløb, der ændrer sig:
[Skærm eller forløb] ændrer sig.
- Det ændrer sig for dig: [konkret effekt].
- Det beholder du: [data, indstillinger, køb].
Spørgsmål? [Indstillinger] > [Hjælp].
Den sidste linje i skabelonen til fejlrettelser gælder kun, hvis nogen faktisk har meldt problemet. Skriv aldrig en nyhed, der ikke er i buildet: regel 2.3 kræver metadata, der svarer til appen.
Manuel, automatisk eller datobestemt udgivelse
Hjælpen om udgivelsesmuligheder giver tre muligheder:
| Mulighed | Efter Apples godkendelse |
|---|---|
| Manuel | Status Pending Developer Release, du udgiver, når du vil |
| Automatisk | Versionen udkommer, så snart den er godkendt |
| Automatisk, tidligst den... | Den venter til den valgte dato og udkommer så af sig selv |
Ved manuel udgivelse åbner du versionen med status Pending Developer Release, klikker på Release This Version og bekræfter. Apple advarer om, at det kan tage op til 24 timer, før den dukker op i App Store. En besked på versionens side tilbyder Cancel This Release, hvis du vil annullere. Hvis versionen venter i mere end 30 dage, sender Apple dig en påmindelse på e-mail.
Manuel udgivelse bruger du til at vælge tidspunktet, for eksempel for at udgive samme dag som en annoncering. Solys 2.0.0, som indeholdt en ny version af årsabonnementet, gik til review sidst i september 2026 med manuel udgivelse.
Til en rutineversion lader jeg den automatiske udgivelse stå. Nolera 1.0.2, godkendt den 12. oktober 2026, dukkede op i App Store mindre end et minut efter e-mailen fra Apple, ifølge iTunes' offentlige søge-API. Det er én enkelt observation: regn med god margin.
Gradvis udrulning over 7 dage
Apples hjælp om gradvis udrulning giver den præcise tidsplan:
| Dag | Andel af brugerne |
|---|---|
| 1 | 1 % |
| 2 | 2 % |
| 3 | 5 % |
| 4 | 10 % |
| 5 | 20 % |
| 6 | 50 % |
| 7 | 100 % |
Opdateringen går til et tilfældigt udsnit af de brugere, der har slået automatiske opdateringer til, på kompatible enheder. De får ikke besked om, at de er med.
Gradvis udrulning bremser kun de automatiske opdateringer. Apple understreger, at alle kan hente den nye version fra App Store når som helst. En person, der installerer din app eller trykker på "Update" på din side, kan altså få den allerede første dag. Det er ikke en test på 1 % af dine brugere: det er en bremse på de andre.
For at slå den til åbner du versionen, scroller ned til sektionen Phased Release for Automatic Updates, sætter flueben ved "Release update over a 7-day period using phased release" og gemmer. Det kræver rollen Account Holder, Admin eller App Manager. Muligheden er tilgængelig indtil status Pending Developer Release: du kan stadig slå den til efter Apples godkendelse, så længe versionen venter på din manuelle udgivelse.
Når versionen er godkendt, står der "Phased Release" ved dens status Ready for Distribution. Når de 7 dage er gået, får appens Admin og App Manager en notifikation.
Pause, genoptagelse og udgivelse til alle
- Pause: op til 30 dage i alt, fordelt på så mange gange, du vil. En pause på 10 dage efterlader 20 dage til de næste.
- Genoptagelse: udrulningen fortsætter fra den dag, hvor du stoppede den.
- Udgivelse til alle: knappen Release to All Users øverst til højre i versionen sender opdateringen til alle enheder med automatisk opdatering.
- Fjernelse fra salg: stopper udrulningen for altid, også hvis dit medlemskab af udviklerprogrammet udløber. Hvis appen kommer i salg igen, er versionen tilgængelig for alle på én gang.
Efter udgivelse til alle kan intet længere justeres, står der i tabellen over redigerbare egenskaber.
Nolera 1.0.2 udkom uden gradvis udrulning. Sådan ville jeg bruge den i løbet af ugen:
| Det, du ser | Det, du gør | Det, der sker |
|---|---|---|
| Crashes eller bekymrede anmeldelser | Pause | De automatiske opdateringer stopper |
| Rettelsen er klar | Ny version | Den går til review igen, med sin egen udrulning |
| Intet unormalt efter 3 eller 4 dage | Release to All Users | Alle får den |
| Du venter på svar fra Apple | Pause, 30 dage i alt | Genoptages fra den dag, du stoppede |
Under en pause fortsætter de manuelle downloads. Slå gradvis udrulning til for alle versioner, der berører betaling eller første opstart: det er dér, en fejl koster mest, og du kan ikke rulle tilbage.
Når rettelsen haster: fremskyndet review
Apple lader dig anmode om et fremskyndet review. Det er forbeholdt reelle nødsituationer: en kritisk fejl, der skal rettes, eller en udgivelse knyttet til en begivenhed.
- Indsend først din version. Beskriv fejlen i feltet Notes til revieweren.
- Udfyld formularen til anmodning om fremskyndet review, og vælg din app og dens platform.
- Apple fremskynder reviewet, alt efter hvad de har kapacitet til. Intet er garanteret.
Ved en begivenhed skriver du i noterne, hvilken dato den er, og hvad din tilknytning til den er. De normale ventetider står i ventetiden på App Store-godkendelse.
Det, der skal til review igen, og det, der ikke skal
| Ændring | Det kræver |
|---|---|
| Native kode, tilladelser, SDK-version | Nyt build, ny version, fuldt review |
| Screenshots, beskrivelse, nøgleord, nyheder | En ny version, reviewet sammen med den |
| Promotional text | Intet: den ændres uden ny indsendelse |
| Pause, genoptagelse, udgivelse til alle | Intet: det er udgivelsesindstillinger |
| Header på iOS 27-siden | Alene i Asset Library eller med en version |
| JavaScript-rettelse med Expo | En fjernopdatering er mulig |
Promotional text ændres uden ny indsendelse, ifølge siden om versionsinformation. Med Expo ændrer en fjernopdatering JavaScript, tekster og billeder uden om App Store. Expos dokumentation sætter to grænser: native kode, tilladelser og SDK-version kræver et nyt binary, og opdateringerne skal overholde App Stores regler.
Mit eksempel: en fjernrettelse, som revieweren aldrig så
I september 2026 ventede et build af Nolera på review. Jeg havde rettet en fejl på scanningsskærmen og udgivet rettelsen som fjernopdatering, mens jeg ventede. Buildet blev alligevel afvist, på grund af den allerede rettede fejl.
Forklaringen står i dokumentationen til expo-updates: som standard henter appen opdateringen ved opstart og anvender den ved næste opstart. Revieweren installerer appen, starter den én gang og tester koden, der er bygget ind i buildet. Samme regel gælder for dine nye brugere: deres første session kører på koden i buildet.
Siden da sendes enhver ændring af startskærmen, paywallen eller hovedfunktionen ud i et nyt build. Fjernopdateringen bruges kun til folk, der allerede har appen.
Nulstil bedømmelsen med en version
Hver ny version tilbyder muligheden Reset rating when this version is released. Ifølge Apples hjælp om nulstilling gælder den for alle lande, beholder de skrevne anmeldelser og kan ikke fortrydes efter udgivelsen. Apple anbefaler at bruge den sparsomt, fordi en side med få bedømmelser kan virke afskrækkende.
Tjekliste før du indsender din opdatering
- Versionsnummeret er højere, og buildet er talt op.
- Buildet er testet i TestFlight, på en lille iPhone og på iPad, hvis din app kører der.
- Nyhederne er skrevet på hvert sprog, og de vigtige ændringer står på listen.
- Screenshots viser den nuværende brugerflade, hvis den har ændret sig.
- Noterne til revieweren fortæller, hvad der er ændret, og hvor det findes.
- Udgivelsesmuligheden er valgt: manuel, hvis du skal ramme en dato.
- Gradvis udrulning er slået til, hvis versionen berører betaling eller første opstart.
- Du ved, om en eventuel rettelse kan sendes som fjernopdatering, eller om den kræver et build.
Kom gennem review ved hver opdatering
Hver opdatering skal forbi App Review igen, og en afvisning blokerer din rettelse. Review Kit samler min tjekliste før indsendelse, mine rettede afvisninger og to Claude Code-skills, der gennemgår dit projekt og din side og forbereder dit svar, hvis Apple afviser. Hele forløbet står på siden udgiv en app i App Store.
Hvis du forbereder din første udgivelse, så tag din gratis diagnose: den sætter trinene i rækkefølge og sender dig min tjekliste mod afvisninger fra Apple.
Ofte stillede spørgsmål
Hvor længe varer gradvis udrulning i App Store?
Syv dage: 1 % af brugerne med automatisk opdatering første dag, derefter 2, 5, 10, 20 og 50 %, og 100 % på syvendedagen. Du kan sætte den på pause i op til 30 dage i alt eller afslutte den når som helst med Release to All Users.
Skal en opdatering af en iOS-app gennem Apples review igen?
Ja. Hver ny version, med sit build og sine metadata, går gennem App Review. Promotional text og udgivelsesindstillingerne kan derimod ændres uden ny indsendelse.
Kan man gå tilbage til den gamle version af en app i App Store?
Nej. Du skal oprette en ny version med rettelsen og sende den til review. Derfor er gradvis udrulning og muligheden for pause nyttige.
Får nye brugere opdateringen under gradvis udrulning?
Ja, hvis de henter appen fra App Store. Gradvis udrulning styrer kun automatiske opdateringer: alle kan hente den nye version når som helst.
Kan man slå gradvis udrulning til efter Apples godkendelse?
Ja, så længe versionen har status Pending Developer Release, altså med manuel udgivelse og endnu ikke udgivet. Når versionen er udkommet, er det for sent for den version.
Hvad skal der stå i versionsnoterne til en opdatering?
De nye funktioner og de vigtige ændringer, tydeligt listet: det er regel 2.3.12. Til en simpel rettelse af fejl, sikkerhed eller ydeevne er en generel formulering nok. Feltet rummer 4.000 tegn og kan oversættes til hvert sprog.

