Mobiilisovelluksen tarkistuslista startupeille: 34 kohtaa MVP:stä App Store -hyväksyntään (2026)

Mobiilisovelluksen tarkistuslista startupeille: 34 kohtaa MVP:stä App Store -hyväksyntään (2026)

Applen App Store Review Guideline 5.1.1(v) on kaatanut useamman startupin julkaisupäivän kuin yksikään bugi, jonka olemme koskaan toimittaneet. Yksi puuttuva tilinpoistopainike, demo dayn aattona lähetetty build, ja koko aikataulu valuu viikolla. Tämä mobiilisovelluksen tarkistuslista startupeille on olemassa, koska tuo virhe on täysin vältettävissä, ja lähes kukaan ei kirjoita ylös sen aiheuttaneen ohjeistuksen numeroa.

Keskeiset opit:

• Apple hylkää sovelluksia, joista puuttuu tilinpoisto tai tietosuojakäytännön linkki: ohjeistukset 5.1.1 ja 1.5 mainitsevat sen suoraan.
• Google Play vaatii tilin poistamiseen sekä sovelluksen sisäisen polun että julkisen verkkopolun, ja valvonta alkoi 31. toukokuuta 2024 päättyneen jatkoajan jälkeen.
• iOS:n ja Androidin lähetystarkistuslistat eroavat toisistaan; niiden käsittely yhtenä yhteisenä listana on yleisin syy viime hetken julkaisuviivästyksiin.

Ennen kuin kirjoitat koodia

Ennen yhdenkään näytön suunnittelua kolme asiaa pitää lyödä lukkoon: mikä MVP oikeasti on, tarvitsetko tietosuojakäytännön (tarvitset), ja soveltuuko käyttäjiisi GDPR vai Turkin KVKK. Tämän vaiheen ohittaminen on syy siihen, että perustajat kokoavat lakitekstejä kiireessä juuri sillä viikolla, jolloin he aikoivat lähettää sovelluksen kauppaan.

MVP on yhdellä lauseella tuotteesi pienin versio, joka testaa ydinoletustasi oikeilla käyttäjillä. Se ei ole karsittu versio täydestä visiostasi. Jos laajuus on vielä hämärän peitossa, projektin laajuuden määrittely kunnolla ennen ensimmäistäkään koodiriviä säästää sinut ominaisuuksien leikkaamiselta kesken rakentamisen eikä vasta ennen sitä.

Applen oma ohjeistus on tietosuojakäytäntövaatimuksen osalta suorasukainen: ohjeistus 5.1.1(i) edellyttää, että sovellusten "on sisällytettävä linkki tietosuojakäytäntöönsä" App Store Connect -metatiedoissa ja monissa tapauksissa myös sovelluksen sisällä. Se ei ole suositus. Se on julkaisun este, jos se puuttuu.

• Määrittele MVP:si laajuus yhdellä lauseella
• Varmista, että tarvitset tietosuojakäytännön (lähes aina tarvitset)
• Laadi tuki-URL (Applen ohjeistus 1.5 vaatii sen)
• Tarkista GDPR:n/KVKK:n soveltuvuus, jos sinulla on EU- tai turkkilaisia käyttäjiä
• Päätä natiivi vai alustariippumaton teknologiapino

MVP:n rakennusviikko

MVP:n rakennusviikolla päätetään, mikä oikeasti julkaistaan ja mikä leikataan, ja rehellinen vastaus on: enemmän kuin perustajat odottavat. Analytiikka ja kaatumisraportointi laitetaan sisään rakennusvaiheessa, ei sen jälkeen. Jälkikäteen asennettuna menetät juuri sen datan, jota tarvitsit ensimmäisen oletuksesi validointiin.

Käytännössä v1-laajuudesta leikataan useimmiten kaikki muu paitsi se yksi asia, jota testataan. Push-ilmoitukset, sosiaalinen kirjautuminen, asetukset-ruutu kuudella kytkimellä, kaikki voi odottaa. Perustajat vastustavat tätä, ymmärrettävästi; tuntuu kuin julkaisisi keskeneräisen tuotteen. Se on keskeneräinen. Se on juuri tarkoitus.

Kuten eräs useita sovelluksia julkaissut perustaja totesi dev.to-tarkistuslistapostauksessaan, palautekanavan ohittaminen alussa on virhe, jota hän "on katunut joka kerta". Kytke se sisään nyt, ei ensimmäisen arvostelun saavuttua. Jos haluat nopeuttaa itse laajuuskeskustelua, tekoälyn käyttäminen laajuuden määrittelyssä kannattaa vilkaista ennen rakennuksen alkua.

• Instrumentoi analytiikka ennen ensimmäistä TestFlight- tai sisäistä buildia
• Kytke kaatumisraportointi (Sentry tai Firebase Crashlytics)
• Rakenna sovellukseen palautekanava
• Leikkaa kaikki ominaisuudet, jotka eivät ole keskeisiä testattavan asian kannalta
• Kirjoita ensimmäinen versiomerkkijonosi (katso versiointi alla)

Viikko ennen lähettämistä

Tämä on vaihe, jonka jokainen kilpailijoiden tarkistuslista ohittaa kokonaan, ja juuri tässä tapahtuvat kaikkein helpoimmin vältettävät viivästykset. Sovellusten semanttinen versiointi noudattaa MAJOR.MINOR.BUILD-kaavaa (1.0.0, sitten 1.0.1 korjaukselle, 1.1.0 uudelle ominaisuudelle). Valitse kaava nyt, koska epäjohdonmukaiset versionumerot hämmentävät sekä sovelluskauppoja että omaa tiimiäsi.

Vaiheittainen julkaisu jakaa päivityksen ensin pienelle osuudelle käyttäjistä (usein 1 %, sitten 10 %, sitten 50 %) ennen kaikille avaamista. Vain yksi kolmesta tarkastelemastamme kilpailijoiden tarkistuslistasta mainitsee sen, ja senkin vain ohimennen. Jos kaatuminen lipsahtaa läpi, vaiheittainen julkaisu rajaa vahingon laajuutta sen sijaan, että se osuisi kerralla sataan prosenttiin käyttäjistä.

Kysymykset, jotka esitämme ennen asiakkaan lähetyksen hyväksymistä, ovat yksinkertaisia: toimiiko kriittinen polku päästä päähän, juuri nyt, oikealla laitteella? Ei simulaattorilla. Onko kaatumisvapaa osuus hyväksyttävällä tasolla? Ovatko kauppalistauksen materiaalit oikeasti lopulliset, eivät paikkamerkkejä?

• Varmista, että versionumerosi noudattaa johdonmukaista kaavaa
• Testaa kriittinen polku päästä päähän vielä kerran
• Valmistele vaiheittaisen julkaisun prosenttiosuus, jos kauppa tukee sitä
• Varmista kaatumisvapaa osuus hyväksyttäväksi ennen lähettämistä
• Ota kuvakaappaukset ja valmistele kaikki kauppalistauksen materiaalit

Lähetyspäivä: iOS vs. Android

iOS- ja Android-lähetykset epäonnistuvat eri syistä, ja niiden käsittely yhtenä yhteisenä tarkistuslistana on yksittäinen suurin syy näkemiimme viime hetken julkaisuviivästyksiin. Applen App Store Review Guidelines ja Google Playn kehittäjäkäytännöt kumpikin nimeävät tiettyjä, tarkistettavissa olevia vaatimuksia, ja useimmat perustajat saavat niistä tietää vasta hylkäyssähköpostin jälkeen.

Omissa sovelluslähetyksissämme kaksi asiaa kaataa ensikertalaiset perustajat useimmin: tilinpoistovaatimus ja tavoittamaton tuki-URL. Molemmat ovat yhden rivin korjauksia, jos huomaat ne ennen lähettämistä. Molemmat aiheuttavat automaattisen hylkäyksen, jos et huomaa.

Applen App Store Review Guidelines on tarkka: ohjeistus 5.1.1(v) vaatii, että tilin luomista tukevat sovellukset tarjoavat myös sovelluksen sisäisen tilinpoiston, ohjeistus 1.6 kattaa Data Security -tietojen julkistamisen, ja ohjeistus 1.5 vaatii toimivan tuki-URL:n. Androidilla Google Playn kehittäjäkäytäntö vaatii sekä sovelluksen sisäisen poistopolun ETTÄ julkisen web-URL:n tilinpoistopyynnöille. Google ilmoitti vaatimuksesta huhtikuussa 2023, asetti 7. joulukuuta 2023 määräpäivän Data safety -lomakkeen tietojenpoistokysymyksille ja salli jatkoajan 31. toukokuuta 2024 asti, minkä jälkeen vaatimustenvastaiset sovellukset joutuvat toimenpiteiden kohteeksi. Tämä ei ole vanha sääntö, josta pienet sovellukset olisi vapautettu; se on yhä voimassa.

Kaksi lähetysprosessia eroavat myös mekaanisesti, eivät vain paperilla. iOS:ssä lataat buildin Xcoden tai Transporterin kautta, App Store Connect käsittelee sen (tämä vie muutamasta minuutista yli tuntiin), ja sen jälkeen joko ohjaat sen TestFlightiin sisäisille ja ulkoisille testaajille tai lähetät sen suoraan App Review'hun. TestFlight ei ole valinnaista puuhastelua: sen avulla Applen odottaa sinun löytävän bugit, joista tarkastaja muuten hylkäisi sinut. Androidilla Google Play Console toimii yksittäisen lähetyksen sijaan raitoina, edeten sisäisestä testauksesta suljettuun tai avoimeen testaukseen ja sieltä tuotantoon, jokaisella oma yleisönsä ja oma edistymisaskeleensa. Vaiheittainen julkaisu tulee kuvaan vasta, kun päivität olemassa olevaa tuotantojulkaisua. Kuten Googlen oma julkaisudokumentaatio sanoo, "jos julkaiset ensimmäistä versiota, et näe vaihtoehtoa valita julkaisuprosenttia", joten älä suunnittele ensimmäistä julkaisuasi prosenttiportaiden varaan, se tulee myöhemmin.

Koodin sijaan paperityöt ovat se, mikä todella estää useimmat ensikertalaisten lähetykset. Apple vaatii privacy manifestin määritellylle listalle yleisesti käytettyjä kolmannen osapuolen SDK:ita (mainosverkostot, analytiikka, kaatumisraportoijat), ja sen oma ohjeistus on suorasukainen siitä, kuka on vastuussa: "kun käytät sovelluksessasi kolmannen osapuolen SDK:ta, olet vastuussa kaikesta koodista, jonka SDK sisällyttää sovellukseesi, ja sinun on tunnettava sen tiedonkeruu- ja käyttökäytännöt", Applen kolmannen osapuolen SDK -vaatimussivun mukaan. Jos ohitat manifestin listatun SDK:n kohdalla, buildisi ei läpäise App Store Connectia. Google Playn vastaava paperityöeste on Data safety -lomake, ja se on pakollinen jokaiselle sovelluksella jokaisella raidalla lukuun ottamatta pelkästään sisäiseen testaukseen tarkoitettuja buildeja: "kaikkien kehittäjien, joilla on Google Playssa julkaistu sovellus, on täytettävä Data safety -lomake, mukaan lukien sovellukset suljetuilla, avoimilla tai tuotantoradoilla", Google Playn Data safety -dokumentaation mukaan. Jos täytät sen väärin, Google sanoo suoraan, että se "voi ryhtyä asianmukaisiin toimenpiteisiin, mukaan lukien valvontatoimet", kun ilmoitetun ja todellisen sovelluskäyttäytymisen välinen ristiriita tulee ilmi.

On kolmas vikamuoto, jolla ei ole mitään tekemistä sääntötekstin kanssa: tarkastaja ei yksinkertaisesti pysty testaamaan sovellustasi. Applen ohjeistus 2.1 sanoo tämän suoraan: "sisällytä demotilin tiedot (ja käynnistä taustapalvelusi!), jos sovelluksessasi on kirjautuminen". Ei toimivia demotunnuksia, ei käynnissä olevaa taustajärjestelmää tarkastusikkunan aikana, ei tavoitettavaa tuki-URL:ää, ja sinut passitetaan takaisin riippumatta siitä, kuinka vaatimustenmukainen tilinpoistosi on. Jos mikä tahansa osa sovelluksestasi on maksumuurin tai kirjautumisen takana, kirjoita tarkastajalle ohjeet, jotka selittävät tarkalleen, miten sinne pääsee. Se on kahden minuutin vaihe, jonka ensikertalaiset ohittavat jatkuvasti.

Vielä yksi vain Androidille kuuluva este kuuluu samaan keskusteluun: kohde-API-taso. Androidin oma kehittäjädokumentaatio toteaa, että "uusien sovellusten ja sovelluspäivitysten on kohdennettava" voimassa olevaan vaadittuun Android-API-tasoon "Google Playhin lähettämiseksi", ja että "vanhentuneet sovellukset eivät ole saatavilla uusille käyttäjille laitteissa, joissa on uudempi Android-versio". Sillä ei ole mitään tekemistä tilinpoiston tai Data safetyn kanssa, mutta se estää lähetyksen yhtä lailla, ja se on vaatimus, joka muuttuu joka vuosi, joten tarkista voimassa oleva numero ennen release-buildin kokoamista.

Yksikään tämän saman haun kärkisijoilla olevista tarkistuslistoista ei siteeraa yhtäkään App Store -ohjeistuksen numeroa. Me siteeraamme, koska arvailu vaatimustenmukaisuudesta on tapa, jolla julkaisut viivästyvät viikolla kerrallaan. Jos rakennat laajempaa tiedonkäsittelyn kokonaisuuttasi, tiedonkäsittelyn tarkistuslista ennen julkaisua kattaa turvallisuuspuolen, jota emme tässä toista.

iOS-lähetyksen tarkistuslista:

• Tietosuojakäytännön URL julkaistu ja tavoitettavissa
• Sovelluksen sisäinen tilinpoistopolku toimitettu (ohjeistus 5.1.1(v))
• Tuki-URL julkaistu (ohjeistus 1.5)
• Data Security -tiedot täytetty (ohjeistus 1.6)
• TestFlight-build hyväksytty ennen julkista lähetystä

Android-lähetyksen tarkistuslista:

• Data safety -lomake täytetty Play Consolessa
• Sovelluksen sisäinen tilinpoistopolku toimitettu
• Julkinen web-URL tilinpoistopyynnöille julkaistu (Google Playn vaatimus)
• Vaiheittaisen julkaisun prosenttiosuus asetettu
• Kohde-API-taso täyttää nykyisen Play-vaatimuksen

Julkaisupäivä

Julkaisupäivä on päivä, jolloin sovelluksesi oikeasti avautuu oikeille käyttäjille, erillään lähettämisestä, joka on voinut tapahtua päiviä tai viikkoja aiemmin, ja erillään ensimmäisestä viikosta, joka on jälkipeliä. Vaiheittaisen julkaisun seuranta ensimmäisenä päivänä kertoo sinulle, jatkatko laajentamista vai painatko taukoa.

Seuraa App Store Connectin tai Play Consolen näkymää tunneittain, ei päivittäin, ensimmäisten 24 tunnin aikana. Jos kaatumisvapaa osuutesi laskee, haluat tietää sen tunnin sisällä, et seuraavana aamuna, kun sata käyttäjää lisää on törmännyt samaan bugiin. Pidä rollback-buildi valmiina. Sama kovenna-vakauta-julkaise-kuri, jota käytämme tekoälyominaisuuksissa, pätee tässä yhtä suoraan.

• Seuraa kaatumisvapaata osuutta tunneittain ensimmäiset 24 tuntia
• Pidä tukikanavasi miehitettynä ja valmiina
• Varmista, että vaiheittainen julkaisusi laajenee suunnitellusti
• Pidä rollback-buildi valmiina kriittisen bugin varalta

Ensimmäinen viikkosi livenä

Ensimmäisellä live-viikolla tapahtuu suurin osa todellisesta työstä, vaikka lähes kukaan ei suunnittele sitä. Päivittäinen kaatumisraporttien läpikäynti ja ensimmäisiin kauppa-arvosteluihin vastaaminen merkitsevät enemmän kuin mikään, mitä teit itse julkaisupäivänä.

"Itse julkaisu merkitsee vähemmän kuin luulet. Ratkaisevaa on, mitä teet viikkoina sen jälkeen", kuten eräs perustaja kirjoitti omassa julkaisun jälkeisessä tarkistuslistassaan. Se on ensimmäisen viikon rehellinen versio: paikkaa nopeasti, vastaa henkilökohtaisesti, ja varmista, että tilinpoistoprosessisi oikeasti toimii, ennen kuin oikea käyttäjä testaa sen puolestasi. Jos nyt mietit, mitä tämän kaiken rakentaminen ja ylläpito maksaa, julkaisun jälkeisen ylläpidon ja päivitysten budjetointi on kumppaniteksti. Tämä teksti kattaa valmiuden; se kattaa laskun.

• Käy kaatumisraportit läpi päivittäin ensimmäisen viikon ajan
• Vastaa henkilökohtaisesti kymmeneen ensimmäiseen kauppa-arvosteluun
• Priorisoi ja paikkaa kriittinen bugi 48 tunnin sisällä
• Varmista, että tilinpoistopyyntöprosessisi toimii oikeasti päästä päähän
• Aseta rytmi analytiikan vertaamiselle alkuperäiseen MVP-oletukseesi

Miten Techsy lähestyy tätä

Käsittelemme lähetystä edeltävää tarkastusta samalla tavalla jokaisen asiakasbuildin kohdalla: ennen kuin hyväksymme lähetyksen, kysymme, toimiiko kriittinen polku oikealla laitteella, pysyykö kaatumisvapaa osuus kasassa, ja toimiiko jokainen ohjeistuksen vaatima kulku (tilin poistaminen, tietosuojakäytäntö, tuki-URL) oikeasti, ei vain mockupissa. Se on lyhyt lista, mutta se on lista, joka ratkaisee, läpäiseekö sovellus tarkastuksen ensimmäisellä kerralla.

Jos haluat mieluummin antaa näitä ohjeistuksia aiemmin läpikäyneen tiimin hoitaa lähetyksesi, mobiilisovelluskehityksemme prosessi on rakennettu juuri tämän lähetystä edeltävän tarkastusvaiheen ympärille. Se ei korvaa omien läksyjen tekemistä, se on sitä, mitä teemme sen jälkeen kun olet tehnyt ne.

Usein kysytyt kysymykset

Mikä on MVP ja miksi se merkitsee julkaisun tarkistuslistalla?

MVP on tuotteesi pienin versio, joka testaa yhden ydinoletuksen oikeilla käyttäjillä. Se merkitsee tässä, koska jokainen tämän tarkistuslistan kohta skaalautuu laajuuden mukaan: tiukempi MVP tarkoittaa vähemmän asioita, jotka voivat mennä pieleen lähetyksessä, ja vähemmän ominaisuuksia instrumentoitavaksi, seurattavaksi ja paikattavaksi ensimmäisellä viikolla.

Miksi sovelluksia hylätään App Storessa?

Yleisimmät vältettävissä olevat syyt ovat puuttuva tietosuojakäytännön linkki (ohjeistus 5.1.1(i)), puuttuva sovelluksen sisäinen tilinpoisto (ohjeistus 5.1.1(v)) ja tavoittamaton tuki-URL (ohjeistus 1.5). Minkään näiden korjaaminen ei vaadi insinöörityötä, ne ovat tarkistuslistakohtia, eivät bugeja.

Mitä tapahtuu, jos en lisää sovellukseeni tilinpoistomahdollisuutta?

iOS:ssä ohjeistus 5.1.1(v) tekee tästä automaattisen hylkäyssyyn, jos sovelluksesi tukee tilin luomista. Androidilla Google Play vaatii sekä sovelluksen sisäisen että julkisen verkkopoistopolun, ja vaatimustenvastaiset sovellukset joutuvat toimenpiteiden kohteeksi 31. toukokuuta 2024 päättyneen jatkoajan jälkeen; sen pois jättäminen estää lähetyksen molemmilla alustoilla.

Tarvitseeko startup tietosuojakäytännön mobiilisovellukselle?

Kyllä, lähes aina. Apple vaatii linkitetyn tietosuojakäytännön ohjeistuksen 5.1.1(i) nojalla, ja Google Play vaatii sen Data safety -lomakkeessa. Jos keräät mitä tahansa käyttäjädataa, edes sähköpostin rekisteröitymistä varten, tarvitset sen ennen lähettämistä.

Mitä eroa on sovelluksen lähettämisellä App Storeen ja Google Playhin?

Applen tarkastus on ohjeistusvetoinen, nimetyillä pykälillä (5.1.1, 1.5, 1.6), ja sen tekee ihminen; Google Play nojaa Data safety -lomakkeeseen ja automaattitarkastuksiin. Tilinpoistovaatimus on hengeltään samankaltainen mutta mekaniikaltaan erilainen; katso vertailutaulukko yllä.

Kuinka kauan sovelluskaupan käsittely oikeasti kestää?

Kumpikaan kauppa ei julkaise taattua käsittelyaikaa, joten käsittele mitä tahansa lukemaasi karkeana odotuksena etkä lupauksena. Omissa asiakaslähetyksissämme Applen hyväksynnät ovat yleensä tulleet päivän tai kahden sisällä, tilinpoistoon tai tietojen julkistamiseen liittyvien asioiden viedessä kauemmin. Google Play on yleensä ollut nopeampi. Suunnittele julkaisupäivääsi joka tapauksessa väljyyttä.

Mikä on vaiheittainen julkaisu ja pitäisikö minun käyttää sitä?

Vaiheittainen julkaisu jakaa päivityksen ensin pienelle osuudelle käyttäjistä ja laajentaa sitä vähitellen sen sijaan, että se menisi kerralla sadalle prosentille. Käytä sitä aina, kun kauppa tukee sitä; se rajaa sitä, kuinka moni käyttäjä törmää bugiin ennen kuin voit pysäyttää ja korjata sen.

Tarvitsenko tuki-URL:n sovellukseni lähettämiseen?

Kyllä. Applen ohjeistus 1.5 vaatii toimivan tuki-URL:n osana lähetystä, ja Google Play odottaa myös tukiyhteystietoa. Kuollut linkki tai valvomaton postilaatikko on tässä helppo, vältettävissä oleva hylkäyssyy.

Mitä minun pitäisi seurata sovellukseni ensimmäisellä live-viikolla?

Kaatumisraportteja päivittäin, kymmentä ensimmäistä kauppa-arvostelua, ja sitä, toimiiko tilinpoistopyyntöprosessisi oikeasti päästä päähän. Tässä vaiheessa alat myös verrata todellista käyttäjädataa siihen oletukseen, jota MVP:si rakennettiin testaamaan.

Ovatko GDPR tai KVKK relevantteja pienen startupin sovellukselle?

Jos sinulla on käyttäjiä EU:ssa, GDPR soveltuu yrityksesi koosta riippumatta. Jos sinulla on käyttäjiä Turkissa, KVKK soveltuu samalla tavalla. Kummassakaan laissa ei ole pienen startupin vapautusta, joten tarkista soveltuvuus laajuuden määrittelyn aikana, ei sen jälkeen kun sinulla on oikeaa käyttäjädataa suojattavanasi.

Tietoa kirjoittajasta

Mert Batur on Techsy.io:n perustajaosakas, jonka tiimi toimittaa tekoälyagentteja, automaatiojärjestelmiä ja ääni-/SDR-putkia B2B-asiakkaille. Hän kirjoittaa LLM-työkalupinosta, jota Techsyn tiimi oikeasti käyttää tuotannossa. Yhdistä LinkedInissä.

Yhteenveto

Mobiilisovelluksen tarkistuslista startupeille ansaitsee paikkansa vain, jos se on riittävän tarkka toimiakseen jo tänään: määrittele MVP:si yhdellä lauseella, instrumentoi analytiikka ennen rakentamista, käy versiomallisi läpi viikkoa ennen lähettämistä, ja erota iOS- ja Android-tarkistuslistasi yhden yhteisen listan sijaan. Pelkästään tilinpoisto ja tietosuojakäytäntö selittävät suurimman osan näkemistämme vältettävissä olevista hylkäyksistä.

Tulosta tarkistuslista, käy se läpi vaihe vaiheelta, äläkä ohita ensimmäistä live-viikkoa. Se on osa, jonka jokainen kilpailijoiden tarkistuslista jättää pois, ja se on osa, joka todella ratkaisee, jääkö julkaisusi pysyvästi eloon. Jos haluat mieluummin toisen silmäparin katsomaan lähetystäsi ennen sen lähettämistä, varaa ilmainen konsultaatio →.