iOS-sovelluksen julkaisu App Storeen: aikataulu, hylkäyssyyt ja tarkistuslista

Julkaisu kaatuu harvoin koodiin ja lähes aina siihen, mitä sovelluksen ympärille piti toimittaa. Käymme läpi yleisimmät hylkäyssyyt, realistisen aikataulun ja tarkistuslistan, joka säästää kokonaisen tarkistuskierroksen.

Lyhyt vastaus: iOS-sovelluksen julkaisu App Storeen vie valmiista sovelluksesta tyypillisesti päivistä viikkoon, mutta ensimmäinen julkaisu venyy lähes aina, eikä syy ole tarkistuksen kesto. Syy on se, että kauppasivun aineistot, tilit ja käyttöehdot ovat kesken silloin kun koodi on valmis. Hylkäys ei useimmiten koske sovelluksen toimintaa lainkaan vaan sitä, mitä sovelluksen ympärille piti toimittaa.

Olemme julkaisseet 21 sovellusta App Storeen, ja ne kaikki löytyvät kehittäjäsivultamme. Tämä juttu kertoo, mitä siinä matkassa opittiin: mistä hylkäykset oikeasti tulevat, missä järjestyksessä asiat kannattaa tehdä ja mikä on realistinen aikataulu. Emme väitä tarkkoja tarkistusaikoja, koska Apple ei julkaise takuita eikä niitä voi luvata. Palvelun sisältö on kuvattu sivulla iOS-sovellus ja hinnat hinnastossa.

Mitä julkaisu oikeasti sisältää?

App Store -julkaisu on kolme erillistä vaihetta, ja ne menevät keskenään sekaisin, koska niistä puhutaan yhtenä asiana. Ensimmäinen on tili ja oikeudet: kehittäjäohjelmaan liittyminen, henkilöllisyyden ja yrityksen todentaminen sekä sopimusten hyväksyminen. Toinen on kauppasivun aineisto eli nimi, kuvaus, avainsanat, kuvakaappaukset jokaiselle vaaditulle laitekoolle, kuvake, tietosuojaseloste, ikäraja ja tietojenkeruuvastaukset. Kolmas on tarkistus ja julkaisu. Ensimmäisessä julkaisussa aikaa kuluu ylivoimaisesti eniten toiseen vaiheeseen, ja juuri se on se osa joka unohtuu, koska koodi on siinä vaiheessa jo valmis. Toisessa ja kolmannessa julkaisussa sama vaihe on nopea, koska aineistot ovat olemassa.

1. Tili ja oikeudetKehittäjäohjelmaan liittyminen, henkilöllisyyden ja yrityksen todentaminen, sopimusten hyväksyminen. Yritystilillä tarvitaan yleensä myös organisaation tunniste. Tämä vaihe on hitain ja se tehdään kerran.
2. Kauppasivun aineistoNimi, kuvaus, avainsanat, kuvakaappaukset jokaiselle vaaditulle laitekoolle, kuvake, tietosuojaseloste, ikäraja, tietojenkeruuvastaukset. Tämä on se osa, joka unohtuu ja pysäyttää.
3. Tarkistus ja julkaisuPaketin lähetys, automaattiset tarkistukset, ihmisen tekemä arviointi, ja lopuksi julkaisu joko heti tai valittuna päivänä.

Ensimmäisessä julkaisussa aikaa kuluu ylivoimaisesti eniten vaiheeseen kaksi. Toisessa ja kolmannessa julkaisussa se on nopeaa, koska aineistot ovat olemassa. Tästä syystä yhden sovelluksen kokemus antaa väärän kuvan siitä, mitä julkaisu maksaa — ensimmäinen kerta ei kerro seuraavista.

Mitkä ovat yleisimmät hylkäyssyyt, jotka eivät liity koodiin?

Yleisimmät App Store -hylkäykset eivät koske sovelluksen toimintaa lainkaan vaan sitä, mitä sovelluksen ympärille piti toimittaa. Käytännön kokemuksesta toistuvia syitä on seitsemän: puuttuva käyttöehtolinkki tilaussovelluksessa, toimimattomat testitunnukset, tyhjä tai keskeneräinen ensimmäinen näkymä, kuvakaappaukset jotka eivät vastaa sovellusta, käyttäjien luoma sisältö ilman valvontakeinoja, sovellus joka on lähinnä verkkosivun kuori, sekä tietojenkeruuvastaukset jotka ovat ristiriidassa sovelluksen toiminnan kanssa. Yhteistä niille kaikille on se, että jokainen on korjattavissa ennen lähetystä ilman että kukaan kirjoittaa riviäkään koodia. Alla oleva taulukko kertoo jokaisen kohdalla, mistä sen tunnistaa etukäteen ja miten se korjataan.

Mikä on realistinen aikataulu ensimmäiselle julkaisulle?

Realistinen aikataulu ensimmäiselle App Store -julkaisulle koostuu viidestä vaiheesta, ja niistä vain yksi on varsinainen tarkistus. Vaiheet ovat kehittäjäohjelmaan liittyminen ja todentaminen, sopimusten ja verotietojen täyttö, kauppasivun aineiston tuottaminen, ensimmäinen lähetys ja tarkistus, sekä mahdollinen korjauskierros. Hitain vaihe on lähes aina todentaminen, ei tarkistus — ja se on samalla se vaihe, jota ei voi nopeuttaa millään. Alla oleva taulukko antaa jokaiselle vaiheelle tyypillisen keston ja sen, mikä sitä tavallisimmin venyttää. Aikataulu olettaa, että sovellus on jo valmis ja testattu, ja luvut ovat kokemukseen perustuvia arvioita eivätkä lupauksia.

Käytännön suositus: varaa ensimmäiselle julkaisulle kalenterista kuukausi, vaikka työtä olisi muutama päivä. Se ei ole tehottomuutta vaan sitä, ettei sinun tarvitse selittää asiakkaille myöhästymistä. Jos julkaisulla on kiinteä päivämäärä, esimerkiksi messut tai kampanja, ole valmiina kaksi viikkoa etuajassa ja käytä julkaisupäivän ajastusta.

Mitä tarkistetaan ennen lähetystä?

Ennen jokaista lähetystä käydään läpi sama seitsemän kohdan tarkistuslista, ja se vie noin puoli tuntia. Lista kattaa asennuksen puhtaalle laitteelle, testitunnusten kokeilemisen samana päivänä, kuvauksen linkkien avaamisen, kuvakaappaukset laitekoottain, tietojenkeruulomakkeen rivi riviltä, arvioijalle kirjoitettavan muistiinpanon ja julkaisun asettamisen manuaaliseksi. Puoli tuntia on halpa hinta siitä, ettei kokonainen tarkistuskierros mene uusiksi — ja hylätty lähetys aloittaa kierroksen aina alusta. Lista kannattaa käydä läpi myös päivityksissä, ei vain ensimmäisessä julkaisussa, koska vanhentunut testitili ja puuttuva kuvakaappaus osuvat kohdalle yhtä lailla toisella kerralla.

1. Asenna paketti puhtaalle laitteelleEi kehityskoneelle, vaan laitteelle jossa sovellusta ei ole ollut. Yllättävän moni vika näkyy vain ensiasennuksessa: puuttuva aloitusdata, kaatuva ensimmäinen näkymä, lupakysely joka ei tule.
2. Kokeile testitunnukset itse samana päivänäKirjaudu ulos ja sisään. Vanhentunut testitili on yleisimpiä hylkäyssyitä ja täysin vältettävissä.
3. Lue kuvaus läpi linkit klikatenKäyttöehdot, tietosuojaseloste ja tukisivu. Jokaisen pitää avautua julkisesti ilman kirjautumista.
4. Tarkista kuvakaappaukset laitekoottainJokaiselle ilmoitetulle laiteperheelle omat kuvat. Puuttuva koko pysäyttää lähetyksen.
5. Käy tietojenkeruulomake läpi rivi riviltäVertaa siihen, mitä sovellus oikeasti lähettää. Analytiikka ja kaatumisraportointi ovat tiedonkeruuta, vaikka et itse lue niitä.
6. Kirjoita arvioijalle muistiinpanoKolme lausetta: mitä sovellus tekee, miten sen testaa, ja mistä erikoisominaisuudet löytyvät. Tämä lyhentää arviointia ja vähentää väärinymmärryksiä.
7. Aseta julkaisu manuaaliseksiNäin hyväksytty sovellus ei ilmesty kauppaan kesken viikonlopun, vaan silloin kun sinä olet paikalla.

Miksi testijakelu ei ole vapaaehtoinen vaihe?

Testijakelu ennen julkista julkaisua ei ole vapaaehtoinen vaihe, koska se on ainoa tapa nähdä, miten sovellus käyttäytyy laitteella jota et itse omista ja käsissä joka ei tunne sovellusta. Jakelu on ilmaista, sen paketti käy läpi kevyemmän tarkistuksen kuin julkinen versio, ja kierros on siksi nopea. Mukaan kutsutaan vähintään kolme ihmistä, jotka eivät ole olleet tekemässä sovellusta — heidän ensimmäinen minuuttinsa kertoo enemmän kuin viikko omaa testaamista, koska sinä osaat käyttää sovellusta oikein etkä huomaa missä kohtaa aloittaja jää jumiin. Kaksi asiaa kannattaa katsoa nimenomaan tässä vaiheessa: ensimmäinen avaus tyhjällä tilillä ja verkkoyhteyden katkeaminen kesken toiminnon.

Testijakelun paketti käy läpi kevyemmän tarkistuksen kuin julkinen versio, joten kierros on nopea. Kutsu mukaan vähintään kolme ihmistä, jotka eivät ole olleet mukana tekemässä sovellusta. Heidän ensimmäinen minuuttinsa kertoo enemmän kuin viikko omaa testaamista, koska sinä osaat käyttää sovellusta oikein etkä huomaa, missä kohtaa aloittaja jää jumiin.

Kaksi asiaa kannattaa katsoa nimenomaan testijakelussa: mitä tapahtuu ensimmäisellä avauksella tyhjällä tilillä, ja mitä tapahtuu, kun verkkoyhteys katkeaa kesken toiminnon. Nämä kaksi tuottavat suurimman osan ensimmäisistä huonoista arvosteluista.

Miksi kauppasivu on hakukone eikä esite?

Sovelluskaupan sivu on hakukone eikä esite: nimi, alaotsikko ja avainsanakenttä ratkaisevat sen, löytyykö sovellus kaupan omasta hausta lainkaan. Tämä on julkaisun aliarvioiduin osa, koska se tehdään kiireessä viimeisenä silloin kun kaikki muu on jo valmista. Käytännön ohjeita on kolme. Nimeen kuuluu brändin lisäksi se sana, jolla sovellusta haetaan, jos se mahtuu luontevasti. Alaotsikko kertoo hyödyn yhdellä lauseella eikä toista nimeä. Avainsanakenttään ei kirjoiteta samoja sanoja, jotka ovat jo nimessä, koska ne on jo huomioitu ja tila on rajallinen. Kuvaustekstin ensimmäiset rivit ovat ainoa osa, jonka useimmat lukevat — kirjoita niihin mitä sovellus tekee, ei kuka sen teki.

Kolme käytännön ohjetta. Nimeen kuuluu brändin lisäksi se sana, jolla sovellusta haetaan, jos se mahtuu luontevasti. Alaotsikko kertoo hyödyn yhdellä lauseella eikä toista nimeä. Avainsanakenttään ei kirjoiteta samoja sanoja, jotka ovat jo nimessä, koska ne on jo huomioitu — tila on rajallinen ja kaksinkertainen merkintä on hukkaan heitettyä.

Kuvaustekstin ensimmäiset rivit ovat ainoa osa, jonka useimmat lukevat. Kirjoita niihin se, mitä sovellus tekee, ei sitä mikä yritys sen teki. Loppuosaan kuuluvat tilaustiedot ja linkit käyttöehtoihin ja tietosuojaselosteeseen, jos sovelluksessa on maksuja.

Mitä teet, jos hylkäys tulee?

Hylkäys ei ole harvinaisuus eikä epäonnistuminen. Se on viesti, jossa kerrotaan sääntökohta ja usein kuvakaappaus, ja siihen vastataan kolmella asialla. Ensimmäinen on lukea tarkasti, mihin sääntökohtaan viitataan: sama sanamuoto tarkoittaa eri asiaa eri kohdissa, ja viittaus kertoo onko kyse toiminnallisuudesta, sisällöstä, maksuista vai turvallisuudesta. Toinen on vastata samassa keskustelussa ennen kuin lähettää uutta pakettia — jos kyse on väärinymmärryksestä, selitys riittää, ja uusi paketti aloittaisi tarkistuksen alusta. Kolmas on korjata yksi asia kerrallaan ja kirjata mitä muutit. Yksi ero kannattaa tuntea: jos hylkäys koskee sovelluksen ideaa eikä toteutusta, uusi versio ei auta.

Lue mihin kohtaan sääntöä viitataan. Sama sanamuoto voi tarkoittaa eri asiaa eri kohdissa. Viittaus kertoo, onko kyse toiminnallisuudesta, sisällöstä, maksuista vai turvallisuudesta.

Vastaa samassa keskustelussa ennen kuin lähetät uutta pakettia. Jos kyse on väärinymmärryksestä, selitys riittää eikä uutta versiota tarvita. Uusi paketti aloittaa tarkistuksen alusta, vastaus ei.

Korjaa yksi asia kerrallaan ja kirjaa mitä muutit. Jos muutat viisi asiaa ja hylkäys toistuu, et tiedä mikä oli syy. Sama koskee vastauksia: kerro tarkasti mitä teit.

Yksi ero kannattaa tuntea: jos hylkäys koskee sovelluksen ideaa eikä toteutusta, uusi versio ei auta. Silloin kyse on siitä, ettei sovellus kuulu kauppaan siinä muodossa, ja ratkaisu on muuttaa sitä mitä sovellus tekee, ei sitä miltä se näyttää.

Milloin App Store -julkaisua ei kannata tehdä?

App Store -julkaisu on väärä työkalu kolmessa tilanteessa, ja ne on rehellisintä sanoa suoraan. Ensimmäinen on sovellus, joka on tarkoitettu vain omalle henkilökunnalle: julkinen kauppa on väärä jakelutie sisäiselle työkalulle, ja sisäiseen jakeluun on omat keinonsa ilman julkista arviointia. Toinen on sovellus, joka näyttää vain sisältöä joka on jo verkkosivulla — se törmää usein verkkosivukuoria koskevaan sääntöön, ja vaikka se pääsisi läpi, sen ylläpito maksaa joka vuosi. Kolmas on tilanne, jossa sovellusta ei ehditä ylläpitää: julkaisu on sitoumus eikä päätepiste, koska käyttöjärjestelmä päivittyy vuosittain ja kehittäjäohjelma laskutetaan vuosittain.

Kun sovellus on tarkoitettu vain omalle henkilökunnalle. Julkinen kauppa on väärä jakelutie sisäiselle työkalulle. Sisäiseen jakeluun on omat keinonsa, eikä silloin tarvitse käydä läpi julkista arviointia lainkaan.

Kun sovellus näyttää vain sisältöä, joka on jo verkkosivulla. Tällainen sovellus törmää usein siihen sääntöön, joka koskee kauppaan tuotuja verkkosivukuoria, ja vaikka se pääsisi läpi, sen ylläpito maksaa joka vuosi. Vertailu on jutussa mobiilisovellus vai mobiilisivusto.

Kun sovellusta ei ehditä ylläpitää. Julkaisu on sitoumus, ei päätepiste. Käyttöjärjestelmä päivittyy vuosittain ja kehittäjäohjelma laskutetaan vuosittain. Varaa julkaisun rinnalle vuosibudjetti ylläpidolle; itse toteutus ja ylläpito on kuvattu sivulla sovelluskehitys.

Mitä tehdään julkaisun jälkeisellä ensimmäisellä viikolla?

Julkaisupäivä on projektin näkyvin hetki ja sen vähiten tärkeä. Kaksi asiaa kannattaa tehdä heti ensimmäisellä viikolla. Katso kaatumisraportit päivittäin: ensimmäisten päivien viat tulevat laitteilta ja tilanteista, joita et testannut. Ja vastaa jokaiseen arvosteluun, myös yhden tähden arvosteluihin, koska ne ovat ensimmäinen asia jonka seuraava lataaja lukee.

Kolmas asia on korjauspäivitys valmiiksi kolmen viikon päähän. Ensimmäisen version jälkeen tulee aina lista pieniä asioita, ja yksi suunniteltu korjauskierros on halvempi kuin viisi kiireellistä.

Ja säilytä kaikki julkaisussa käytetyt aineistot yhdessä kansiossa: kuvakaappaukset, tekstit, tunnukset ja lomakevastaukset. Seuraava julkaisu on niiden ansiosta päivän työ eikä viikon.

Usein kysyttyä

Lue seuraavaksi

• Android-sovelluksen julkaisu Google Playhin: testivaatimukset ja aikataulu viikkoina
• Sovelluksen ylläpito ja hinta: mitä se maksaa vuodessa julkaisun jälkeen
• Yrityssovelluksen kehittämisen hinta
• WordPress-ylläpidon hinta ja mitä siihen oikeasti kuuluu
• WordPressin hakukoneoptimointi: neljä asetusta, jotka ratkaisevat teknisen puolen
• Microsoft Dynamics 365 vai kevyempi vaihtoehto pk-yritykselle?

Lue myös: hinnasto · kassajärjestelmä ravintolaan · kanta-asiakasohjelma pienyritykselle · digitaalinen leimakortti · ajanvarausjärjestelmien hinnat · verkkosivut yritykselle · sovelluskehitys iOS ja Android · ohjelmistokehitys