App Storen nopeutettu tarkistus: näin pyydät sitä Applelta
Kirjoittaja: Mehdi Azizi
Julkaistu , 9 min
Apple mainitsee kaksi tapausta: kriittinen bugi julkaistussa versiossa tai tapahtumaan sidottu julkaisu. Näin pyydät, mitä kirjoitat ja mitä sitten tapahtuu.
Nopeutettu tarkistus on olemassa, mutta Apple varaa sen poikkeuksellisiin tilanteisiin ja mainitsee niistä kaksi: kriittisen bugin korjaaminen jo julkaistussa versiossa tai sellaisen version julkaisu, joka on ajoitettu tapahtumaan, johon sovelluksesi liittyy suoraan. Ensin lähetät version tarkistukseen, sitten selität kiireen tarkistajan muistiinpanoissa (Notes) ja lopuksi lähetät pyyntölomakkeen. Apple käy jokaisen pyynnön läpi ja nopeuttaa tarkistusta resurssiensa mukaan. Se ei ole koskaan taattua.
Sovellukseni Solys, TradaZen ja Nolera on tehty Expolla. Kun bugi on JavaScript-koodissa, korjaus lähtee etäpäivityksenä eikä kulje App Review'n kautta. Nopeutetusta tarkistuksesta on siis minulle hyötyä vain natiivibuildissa, ja tämä on myös ensimmäinen kysymys, joka sinun kannattaa esittää itsellesi ennen pyyntöä. Tämä opas seuraa Applen ohjesivua nopeutetusta tarkistuksesta, tarkistettu 6. marraskuuta 2026.
Mitä Apple mainitsee ja mikä ei mene läpi
Apple puhuu poikkeuksellisista tilanteista ja pyytää varaamaan pyynnöt todellisiin hätätilanteisiin. Sen App Review -sivu antaa kaksi esimerkkiä ja kertoo, mitä kumpaankin pitää liittää. Taulukon kolme hylättyä riviä ovat minun tulkintani näistä sivuista, eivät Applen lista.
| Syy | Applen kannalta | Mitä pitää antaa tai ymmärtää |
|---|---|---|
| Kriittinen bugi julkaistussa versiossa | Mainittu esimerkkinä | Toisto-ohjeet, nykyinen versio |
| Tapahtumaan sidottu julkaisu | Mainittu esimerkkinä | Tapahtuma, sen päivämäärä, sovelluksen yhteys siihen |
| Myöhästynyt ensijulkaisu | Ei, minun mielestäni | Mikään ei tee siitä Applen silmissä kiireellistä |
| Markkinointipäivä ilman tapahtumaa | Ei, minun mielestäni | Kampanja ei ole sovellukseen liittyvä tapahtuma |
| Tavallista pidempi odotus | Ei, minun mielestäni | Normaali odotusaika ei ole hätätilanne |
Apple ei määrittele termiä. Käytännössä kriittinen bugi tarkoittaa, että julkaistu versio kaatuu, estää olennaisen toiminnon tai estää maksamisen oikeilla käyttäjillä. Kirjoitusvirhe jollain näkymällä ei ole sellainen. Ja jos sovelluksesi on vielä tarkistuksessa tapahtuman lähestyessä, Apple tarkentaa, että voit pyytää nopeutusta myös tästä syystä.
Menettely kolmessa vaiheessa
- Lähetä versio App Store Connectissa. Vain jo lähetetty versio voidaan tarkistaa nopeutetusti. Jos jotkin toiminnot vaativat kirjautumisen, lisää demotili App Review Information -osioon.
- Täytä Notes-kenttä lähetyksen yhteydessä. Kriittisessä bugissa kuvaa korjattu bugi ja miten se toistetaan nykyisessä versiossa. Tapahtumassa kerro sen nimi, päivämäärä ja mikä sovelluksesi yhdistää siihen.
- Lähetä Request an Expedited App Review -lomake, johon pääset Applen ohjesivulta kirjauduttuasi kehittäjätilillesi. Valitset siinä kyseisen sovelluksen ja alustan ja lähetät.
Apple käsittelee pyynnön ja vastaa sinulle, ja sinä seuraat lähetystä App Store Connectissa. Jos pyyntö hyväksytään, versio siirtyy tilaan In Review aiemmin kuin jono olisi sen päästänyt. Jos se hylätään, tarkistus jatkuu normaalisti: mitään ei menetetä.
App Store Connectin Reply to App Review -painike ei ole nopeutetun tarkistuksen pyytämistä varten. App Review'n yhteydenottosivu varaa sen käynnissä olevaa lähetystä koskevaan viestintään; nopeutuspyynnöllä ja valituksella on kummallakin oma lomakkeensa.
Mitä kirjoittaa: kaksi mallia
App Review lukee englantia. Tässä kaksi tekstiä, jotka pidän valmiina ja joita muokkaan Notes-kenttään, ja lomakkeeseen, jos siinä on vapaa tekstikenttä. Ne mahtuvat viiteen riviin, koska tarkistajan pitää ymmärtää kiire avaamatta sovellusta.
Kriittinen bugi julkaistussa versiossa:
Version 2.0.3, currently live, crashes at launch for users who enabled notifications on iOS 26.1. Steps to reproduce: install 2.0.3, allow notifications, force quit, relaunch. The app closes immediately. Version 2.0.4 fixes the crash (notification permission is now read after the first screen loads). No other change in this build.
Tapahtumaan sidottu julkaisu:
This version adds the official schedule and live results for the Nantes Trail Festival on June 5, 2027. Our app is the event's official companion app (see the link to the organizer's page in the App Review Information section). Attendees need the update before the start on June 5 at 8:00 AM CEST.
Nämä kaksi tekstiä ovat esimerkkejä, eivät pyyntöjä, jotka olisin itse lähettänyt. Omiisi kaksi sääntöä. Tarkistettavia faktoja: versio, käyttöjärjestelmä, vaiheet, päivämäärä, yhteys tapahtumaan. Ei mitään muuta kuin kiire: jos buildissasi on myös uusi ominaisuus, mainitse se yhdellä lauseella, mutta älä puolustele sitä.
Ennen kuin pyydät, varmista että tarvitset sitä
Apple pyytää varaamaan sen todellisiin hätätilanteisiin. Kolme kysymystä ja yksi ansa ennen lomakkeen lähettämistä.
Meneekö korjaus läpi ilman tarkistusta? Expolla etäpäivitys korvaa jo asennettujen sovellusten JavaScript-koodin ilman uutta buildia. Tätä reittiä käytän korjauksiini. Se ei kata natiivikoodia, käyttöoikeuksia eikä natiiviriippuvuuksia: niihin tarvitaan build ja tarkistus. Lisäksi sen sisällön pitää pysyä Applen hyväksymissä rajoissa, kuten EAS Updaten esittely muistuttaa: etäpäivitys ei muuta sovelluksen tarkoitusta. Opas iOS-päivityksen vaiheittaisesta julkaisusta kertoo tarkemmin, mikä kulkee minkäkin kautta.
Onko odotus poikkeuksellinen? Applen mukaan se tarkistaa yleensä vähintään 50 % lähetyksistä alle 24 tunnissa ja 90 % alle 48 tunnissa. Jos versiosi on ollut tilassa Waiting for Review päivän, olet App Store -tarkistuksen kestossa normaalin rajoissa. Lähetyksen seurantasivu muistuttaa myös, mikä pidentää tarkistusta: ensimmäinen sovellus ilman historiaa, tarkistettavat asiakirjat, säännelty aihe.
Onko lähetys täydellinen? Nopeutettu tarkistus keskeneräiselle lähetykselle ei nopeuta mitään. Apple varoittaa, että puutteellinen lähetys viivästyttää tarkistusta tai hylätään. Demotili, muistiinpanot, asiakirjat: kaiken pitää olla paikallaan ennen lomaketta.
Ja ennen kaikkea: älä vedä versiotasi pois lähettääksesi sen uudelleen. Pois vedetty versio putoaa jonosta ja aloittaa alusta. Jos Apple kysyy jotain tarkistuksen aikana, vastaa App Store Connectissa äläkä lähetä uudelleen, kuten opas App Review'lle vastaamisesta Resolution Centerissä selittää.
Jos Apple hylkää nopeutuksen
Pidät paikkasi jonossa: hylätty nopeutuspyyntö ei muuta käynnissä olevaa tarkistusta mitenkään. Jotta tilanne ei toistu:
- Ajasta julkaisusi. Tapahtumia varten Apple neuvoo valitsemaan App Store Connectissa ajastetun julkaisun: versio tarkistetaan etukäteen ja julkaistaan haluamanasi päivänä. Version julkaisuvaihtoehto asetetaan version sivulla, App Store Version Release -osiossa.
- Lähetä ajoissa. Viikkoa ennen tapahtumaa valmis versio jättää aikaa normaalille tarkistukselle ja jopa hylkäyksen korjaamiselle.
- Pidä JavaScriptille kanava ilman tarkistusta. Expolla juuri se tekee kriittisestä bugista muutaman minuutin korjauksen.
Tarkistajan muistiinpanomallini, lähetystä edeltävä tarkistuslistani ja vastaukset yleisimpiin hylkäyksiin löytyvät Review Kitistä. Ja jos haluat tietää, mitä lähetyksestäsi puuttuu ennen kuin lähetät sen, ilmainen diagnoosi kertoo sen ja lähettää sinulle tarkistuslistani Applen hylkäysten välttämiseen. Kaikki julkaisun vaiheet ovat sivulla sovelluksen julkaiseminen App Storessa.
Usein kysytyt kysymykset
Kuinka kauan App Storen nopeutettu tarkistus kestää?
Apple ei anna mitään aikaa. Se kertoo käsittelevänsä jokaisen pyynnön ja nopeuttavansa tarkistusta resurssiensa ja senhetkisen kysynnän mukaan. Hyväksytty pyyntö siirtää version tilaan In Review ennen sen vuoroa, ilman lupausta kellonajasta.
Voiko nopeutettua tarkistusta pyytää ensimmäiselle sovellukselle?
Mikään ei estä sitä, mutta Apple varaa nopeutuksen todellisiin hätätilanteisiin ja mainitsee kaksi esimerkkiä: kriittinen bugi jo julkaistussa versiossa tai päivättyyn tapahtumaan sidottu julkaisu. Aikataulustasi myöhästynyt ensijulkaisu ei minun mielestäni kuulu kumpaankaan.
Kuinka monta kertaa nopeutettua tarkistusta voi pyytää?
Apple ei julkaise lukumäärää. Se pyytää varaamaan pyynnöt todellisiin hätätilanteisiin. Minun mielestäni jokainen pyyntö ilman oikeaa syytä tekee seuraavasta vähemmän uskottavan: säästä se bugiin, joka osuu käyttäjiisi.
Pitääkö lähetys vetää pois ennen nopeutuksen pyytämistä?
Ei, päinvastoin. Vain jo lähetetty versio voidaan tarkistaa nopeutetusti, ja pois vedetty versio menettää paikkansa jonossa. Lähetä, täytä Notes ja lähetä sitten lomake.
Missä nopeutetun tarkistuksen lomake on?
Applen kehittäjäsivustolla, kun olet kirjautunut tilillesi: nopeutetun tarkistuksen ohjesivu vie sinne linkillä Request an Expedited App Review. Siellä valitset kyseisen sovelluksen ja alustan.
Takaako nopeutettu tarkistus, että sovellus hyväksytään?
Ei. Se muuttaa vain paikkaa jonossa. Version pitää noudattaa App Review Guidelinesia kuten minkä tahansa muun, ja hylkäys on edelleen mahdollinen.
Voiko bugin korjata ilman App Review'ta?
Expolla tai React Nativella etäpäivitys korvaa JavaScript-koodin ilman uutta buildia ja tarkistusta. Natiivikoodi, käyttöoikeudet ja natiiviriippuvuudet vaativat aina Applelle lähetetyn buildin.

