iOS-päivityksen julkaisu: vaiheittainen julkaisu

Kun haluat julkaista iOS-päivityksen, luot App Store Connectissa uuden version, jolla on edellistä suurempi numero. Liität siihen uuden buildin, kirjoitat Uutta-tekstin (What's New) ja lähetät sen App Review'hun. Jokainen uusi versio käy uudelleen Applen tarkastuksessa, myös pelkkä bugikorjaus. Ennen lähettämistä valitset, miten versio julkaistaan hyväksynnän jälkeen: käsin, heti, aikaisintaan tiettynä päivänä tai vaiheittain 7 päivän aikana.

Vaiheittainen julkaisu koskee vain automaattisia päivityksiä: ensimmäisenä päivänä 1 % näistä käyttäjistä, seitsemäntenä kaikki. Voit keskeyttää sen yhteensä enintään 30 päiväksi tai viedä sen loppuun kerralla. Tämä opas perustuu Applen ohjesivuihin, jotka tarkistin 3. marraskuuta 2026.

Julkaisen iOS-sovellusteni päivitykset Expolla ja EAS:llä, muun muassa Solysin, TradaZenin ja Noleran. Alla mainitut tapaukset ovat näistä julkaisuista.

iOS-päivityksen julkaisu: vaiheet järjestyksessä

App Store Connectin ohje uusista versioista kuvaa tämän polun:

1. Valitse Apps-kohdasta sovelluksesi ja klikkaa alustan vieressä olevaa +-painiketta.
2. Syötä edellistä suurempi versionumero ja klikkaa Create.
3. Tarkista metatiedot: julkaistun version tiedot kopioidaan automaattisesti.
4. Lähetä uusi build, jonka build-numeroa on kasvatettu.
5. Testaa build TestFlightissa, lisää se versioon ja lähetä versio App Review'hun.

Kaksi ehtoa ennen aloittamista. Julkaistun version tilan pitää olla Ready for Distribution. Ja tarvitset jonkin näistä rooleista: Account Holder, Admin, App Manager tai Marketing.

Paluuta edelliseen ei ole. Apple sanoo sen samalla sivulla: jos versiossa on ongelma, et voi palata edelliseen. Sinun on luotava ja lähetettävä uusi versio.

Versionumero ja build-numero

Versio on numero, jonka asiakkaasi näkevät sovellussivullasi. Build yksilöi jokaisen lähetyksen. Version ja buildin yhdistelmän on oltava yksilöllinen: säännöt ja niihin liittyvät virheet löytyvät artikkelista versio- ja build-numero.

Oma käytäntöni, ei Applen sääntö: viimeinen numero kasvaa korjauksessa, 1.4.0:sta 1.4.1:een. Keskimmäinen kasvaa uudessa ominaisuudessa, 1.4.1:stä 1.5.0:aan. Build-numero taas vain kasvaa versiosta toiseen. Expossa versio on tiedostossa app.json, ja EAS voi kasvattaa build-numeroa jokaisessa tuotantokäännöksessä. Käyttöönotto on selitetty artikkelissa Expo-sovelluksen julkaisu EAS:llä.

Uutta-teksti: mitä Apple vaatii

Versiotietojen sivu kuvaa kentän What's New in This Version:

• Enintään 4 000 merkkiä.
• Ei ensimmäisessä versiossa, pakollinen kaikissa seuraavissa.
• Käännettävissä jokaiselle sovellussivusi kielelle.

App Review Guidelinesin sääntö 2.3.12 lisää vaatimuksen: uudet ominaisuudet ja tuotteen muutokset on kuvattava selkeästi. Pelkissä bugi-, tietoturva- tai suorituskykykorjauksissa yleinen muotoilu riittää. Merkittävä muutos on lueteltava. ”Bugikorjauksia ja parannuksia” ei siis riitä versiossa, joka muuttaa tilaustasi tai päänäkymääsi.

Apple neuvoo myös arvioita käsittelevällä sivullaan mainitsemaan julkaisutiedoissa korjatut ongelmat, joista asiakkaat ovat kertoneet arvioissaan.

Tässä kolme muokattavaa pohjaa, yksi kullekin versiotyypille.

Korjausversiolle:

Korjauksia ja vakautta.
- [Ominaisuus]: [mikä ei toiminut] on korjattu.
- [Näkymä] latautuu nopeammin.
Kiitos kaikille, jotka ilmoittivat ongelmasta.

Uudelle ominaisuudelle:

Uutta: [ominaisuus viidellä sanalla].
[Mitä voit nyt tehdä, yhdellä lauseella.]
Mistä löydät sen: [välilehti] > [painike].

Myös tässä versiossa:
- [Näkyvä parannus].
- Bugikorjauksia.

Muuttuvalle käyttöpolulle:

[Näkymä tai polku] muuttuu.
- Mikä muuttuu sinulle: [konkreettinen vaikutus].
- Mikä säilyy: [tiedot, asetukset, ostos].
Kysyttävää? [Asetukset] > [Ohje].

Korjauspohjan viimeinen rivi pätee vain, jos joku on oikeasti ilmoittanut ongelmasta. Älä koskaan kirjoita uutuutta, jota ei ole buildissa: sääntö 2.3 vaatii, että metatiedot vastaavat sovellusta.

Julkaisu käsin, automaattisesti tai tiettynä päivänä

Julkaisuvaihtoehtojen ohje tarjoaa kolme vaihtoehtoa:

Vaihtoehto	Applen hyväksynnän jälkeen
Manuaalinen	Tila Pending Developer Release, julkaiset milloin haluat
Automaattinen	Versio julkaistaan heti hyväksynnän jälkeen
Automaattinen, aikaisintaan..	Se odottaa valittua päivää ja julkaistaan sitten itsestään

Manuaalisessa julkaisussa avaat version, jonka tila on Pending Developer Release, klikkaat Release This Version ja vahvistat. Apple varoittaa, että sen ilmestyminen App Storeen voi kestää jopa 24 tuntia. Version sivulla oleva viesti tarjoaa peruutukseen vaihtoehdon Cancel This Release. Jos versio odottaa yli 30 päivää, Apple lähettää sinulle muistutuksen sähköpostilla.

Manuaalisella julkaisulla valitset ajankohdan, esimerkiksi kun haluat julkaista jonkin tiedotteen päivänä. Solys 2.0.0, jossa oli uusi versio vuositilauksesta, lähti tarkastukseen syyskuun lopussa 2026 manuaalisella julkaisulla.

Rutiiniversioissa jätän julkaisun automaattiseksi. Nolera 1.0.2 hyväksyttiin 12. lokakuuta 2026, ja se ilmestyi App Storeen alle minuutissa Applen sähköpostin jälkeen iTunesin julkisen hakurajapinnan mukaan. Se on vain yksi havainto: varaa reilusti aikaa.

Vaiheittainen julkaisu 7 päivän aikana

Applen ohje vaiheittaisesta julkaisusta kertoo tarkan aikataulun:

Päivä	Osuus käyttäjistä
1	1 %
2	2 %
3	5 %
4	10 %
5	20 %
6	50 %
7	100 %

Päivitys lähtee satunnaiselle otokselle niistä käyttäjistä, jotka ovat ottaneet automaattiset päivitykset käyttöön, yhteensopivilla laitteilla. Heille ei kerrota, että he kuuluvat otokseen.

Vaiheittainen julkaisu jarruttaa vain automaattisia päivityksiä. Apple tarkentaa, että kuka tahansa voi ladata uuden version App Storesta milloin tahansa. Joku, joka asentaa sovelluksesi tai napauttaa sovellussivullasi Update, voi siis saada sen jo ensimmäisenä päivänä. Kyse ei ole testistä 1 %:lla käyttäjistäsi: se on jarru muille.

Ota se käyttöön avaamalla versio, vierittämällä kohtaan Phased Release for Automatic Updates, valitsemalla ”Release update over a 7-day period using phased release” ja tallentamalla. Tarvitset roolin Account Holder, Admin tai App Manager. Vaihtoehto on käytettävissä tilaan Pending Developer Release asti: voit ottaa sen käyttöön vielä Applen hyväksynnän jälkeen, kunhan versio odottaa manuaalista julkaisuasi.

Kun versio on hyväksytty, sen Ready for Distribution -tilassa näkyy merkintä ”Phased Release”. Seitsemän päivän päätteeksi sovelluksen Admin- ja App Manager -käyttäjät saavat ilmoituksen.

Keskeytys, jatkaminen ja julkaisu kaikille

• Keskeytys: yhteensä enintään 30 päivää, niin monessa osassa kuin haluat. 10 päivän keskeytyksen jälkeen seuraaville jää 20 päivää.
• Jatkaminen: julkaisu jatkuu siitä päivästä, johon sen pysäytit.
• Julkaisu kaikille: version oikeassa yläkulmassa oleva painike Release to All Users lähettää päivityksen kaikille laitteille, joissa automaattiset päivitykset ovat käytössä.
• Myynnistä poistaminen: se lopettaa julkaisun lopullisesti, myös jos kehittäjäohjelman jäsenyytesi päättyy. Jos sovellus palaa myyntiin, versio on saatavilla kaikille kerralla.

Kaikille julkaisun jälkeen mitään ei voi enää säätää, kertoo muokattavien ominaisuuksien taulukko.

Nolera 1.0.2 julkaistiin ilman vaiheittaista julkaisua. Näin käyttäisin sitä viikon aikana:

Mitä näet	Mitä teet	Mitä tapahtuu
Kaatumisia tai huolestuneita arvioita	Keskeytys	Automaattiset päivitykset pysähtyvät
Korjaus on valmis	Uusi versio	Se käy tarkastuksessa ja saa oman vaiheittaisen julkaisunsa
Ei mitään poikkeavaa 3 tai 4 päivän jälkeen	Release to All Users	Kaikki saavat sen
Odotat vastausta Applelta	Keskeytys, yhteensä 30 päivää	Jatkuu päivästä, johon pysähdyit

Keskeytyksen aikana manuaaliset lataukset jatkuvat. Valitse vaiheittainen julkaisu jokaiseen versioon, joka koskee maksamista tai ensimmäistä käynnistystä: siellä virhe tulee kalleimmaksi, etkä voi palata takaisin.

Kun korjaus on kiireellinen: nopeutettu tarkastus

Apple antaa pyytää nopeutettua tarkastusta. Se on tarkoitettu vain todellisiin hätätilanteisiin: kriittisen bugin korjaamiseen tai tapahtumaan sidottuun julkaisuun.

1. Lähetä ensin versiosi. Kuvaa bugi tarkastajalle tarkoitetussa Notes-kentässä.
2. Täytä nopeutetun tarkastuksen pyyntölomake ja valitse sovelluksesi ja sen alusta.
3. Apple nopeuttaa tarkastusta resurssiensa mukaan. Mitään ei luvata.

Tapahtuman kohdalla kerro muistiinpanoissa sen päivämäärä ja yhteytesi siihen. Tavalliset käsittelyajat löytyvät artikkelista App Storen tarkastusaika.

Mikä käy uudelleen tarkastuksessa ja mikä ei

Muutos	Mitä tarvitaan
Natiivikoodi, käyttöoikeudet, SDK-versio	Uusi build, uusi versio, täysi tarkastus
Kuvakaappaukset, kuvaus, avainsanat, uutuudet	Uusi versio, tarkastetaan sen mukana
Mainosteksti	Ei mitään: se muuttuu ilman uutta lähetystä
Keskeytys, jatkaminen, julkaisu kaikille	Ei mitään: ne ovat julkaisuasetuksia
iOS 27:n sovellussivun otsakekuva	Yksin Asset Libraryssa tai version mukana
JavaScript-korjaus, Expolla	Etäpäivitys on mahdollinen

Mainosteksti muuttuu ilman uutta lähetystä versiotietojen sivun mukaan. Expossa etäpäivitys muuttaa JavaScriptiä, tekstejä ja kuvia ilman App Storea. Expon dokumentaatio asettaa kaksi rajaa: natiivikoodi, käyttöoikeudet ja SDK-versio vaativat uuden binäärin, ja päivitysten on noudatettava App Storen sääntöjä.

Oma tapaukseni: etäkorjaus, jota tarkastaja ei koskaan nähnyt

Syyskuussa 2026 Noleran build odotti tarkastusta. Olin korjannut skannausnäkymän virheen ja julkaissut korjauksen etäpäivityksenä odotuksen aikana. Build hylättiin silti, juuri tämän jo korjatun virheen vuoksi.

Selitys löytyy expo-updatesin dokumentaatiosta: oletuksena sovellus lataa päivityksen käynnistyksessä ja ottaa sen käyttöön seuraavassa käynnistyksessä. Tarkastaja asentaa sovelluksen, käynnistää sen kerran ja testaa buildiin sisältyvää koodia. Sama sääntö koskee uusia käyttäjiäsi: heidän ensimmäinen istuntonsa pyörii buildin koodilla.

Siitä lähtien kaikki aloitusnäkymän, maksumuurin tai päätoiminnon muutokset lähtevät uudessa buildissa. Etäpäivitys palvelee vain niitä, joilla sovellus jo on.

Arvosanan nollaus version yhteydessä

Jokaisessa uudessa versiossa on vaihtoehto Reset rating when this version is released. Applen nollausohjeen mukaan se koskee kaikkia maita, säilyttää kirjoitetut arviot eikä sitä voi perua julkaisun jälkeen. Apple neuvoo käyttämään sitä säästeliäästi, koska sovellussivu, jolla on vähän arvosanoja, voi karkottaa käyttäjiä.

Tarkistuslista ennen päivityksen lähettämistä

• Versionumero on suurempi ja build-numeroa on kasvatettu.
• Build on testattu TestFlightissa pienellä iPhonella ja iPadilla, jos sovelluksesi toimii siinä.
• Uutuudet on kirjoitettu jokaisella kielellä ja merkittävät muutokset on lueteltu.
• Kuvakaappaukset näyttävät nykyisen käyttöliittymän, jos se on muuttunut.
• Tarkastajan muistiinpanoissa kerrotaan, mikä muuttui ja mistä sen löytää.
• Julkaisuvaihtoehto on valittu: manuaalinen, jos sinun on pidettävä kiinni päivästä.
• Vaiheittainen julkaisu on valittu, jos versio koskee maksamista tai ensimmäistä käynnistystä.
• Tiedät, voiko mahdollisen korjauksen julkaista etänä vai vaatiiko se buildin.

Tarkastuksen läpäisy jokaisessa päivityksessä

Jokainen päivitys käy uudelleen App Review'n läpi, ja hylkäys pysäyttää korjauksesi. Review Kit sisältää tarkistuslistani ennen lähettämistä, korjatut hylkäykseni ja kaksi Claude Code -skilliä, jotka käyvät läpi projektisi ja sovellussivusi ja valmistelevat vastauksesi, jos Apple hylkää. Koko polku on sivulla sovelluksen julkaisu App Storessa.

Jos valmistelet ensimmäistä julkaisuasi, tee ilmainen diagnostiikka: se laittaa vaiheet järjestykseen ja lähettää sinulle tarkistuslistani Applen hylkäysten välttämiseen.

Usein kysytyt kysymykset

Kuinka kauan vaiheittainen julkaisu kestää App Storessa?

Seitsemän päivää: ensimmäisenä päivänä 1 % automaattisia päivityksiä käyttävistä, sitten 2, 5, 10, 20 ja 50 % ja seitsemäntenä 100 %. Voit keskeyttää sen yhteensä enintään 30 päiväksi tai viedä sen loppuun milloin tahansa painikkeella Release to All Users.

Käykö iOS-sovelluksen päivitys uudelleen Applen tarkastuksessa?

Kyllä. Jokainen uusi versio buildeineen ja metatietoineen käy App Review'n läpi. Mainostekstiä ja julkaisuasetuksia voi sen sijaan muuttaa ilman uutta lähetystä.

Voiko App Storessa palata sovelluksen vanhaan versioon?

Ei. Sinun on luotava uusi versio korjauksineen ja lähetettävä se tarkastukseen. Siksi vaiheittainen julkaisu ja sen keskeytys ovat hyödyllisiä.

Saavatko uudet käyttäjät päivityksen vaiheittaisen julkaisun aikana?

Kyllä, jos he lataavat sovelluksen App Storesta. Vaiheittainen julkaisu säätelee vain automaattisia päivityksiä: kuka tahansa voi ladata uuden version milloin tahansa.

Voiko vaiheittaisen julkaisun ottaa käyttöön Applen hyväksynnän jälkeen?

Kyllä, kunhan version tila on Pending Developer Release eli julkaisu on manuaalinen eikä versiota ole vielä julkaistu. Kun versio on julkaistu, on liian myöhäistä tämän version osalta.

Mitä päivityksen julkaisutietoihin kannattaa kirjoittaa?

Uudet ominaisuudet ja merkittävät muutokset selkeästi lueteltuina: näin vaatii sääntö 2.3.12. Pelkässä bugi-, tietoturva- tai suorituskykykorjauksessa yleinen muotoilu riittää. Kenttään mahtuu 4 000 merkkiä, ja sen voi kääntää jokaiselle kielelle.