Guideline 2.3.1: piilotetut toiminnot ja OTA-päivitykset

Guideline 2.3.1 kieltää piilotetut, uinuvat ja dokumentoimattomat toiminnot. Kaiken, mitä sovelluksesi tekee, pitää näkyä sekä käyttäjälle että reviewerille. Jokainen uutuus kuvataan tarkasti arviointimuistiinpanoissa. Etäpäivitys voi korjata sen, minkä Apple on nähnyt, mutta ei koskaan lisätä sitä, mitä Apple ei ole nähnyt.

Julkaisen iOS-sovellukseni Expolla, ja jokaisessa on EAS Update ensimmäisestä buildista asti korjausten toimittamista varten. Sääntöni: ei yhtään etäpäivitystä, kun versio on arvioitavana. Tämä opas perustuu Applen tekstiin, sen lisenssiin, Expon dokumentaatioon ja julkaistuihin hylkäyksiin.

Mitä guideline 2.3.1 sanoo?

2.3.1 aloittaa App Review Guidelinesin kohdan 2.3 "Accurate Metadata" osiossa 2 "Performance". Teksti alkaa näin: "Don't include any hidden, dormant, or undocumented features in your app; your app's functionality should be clear to end users and App Review." Selkokielellä: ei mitään piilotettua, uinuvaa tai dokumentoimatonta.

Jatko koskee jokaista lähetystä: "All new features, functionality, and product changes must be described with specificity in the Notes for Review section of App Store Connect (generic descriptions will be rejected) and accessible for review." Jokainen uutuus pitää kuvata tarkasti arviointimuistiinpanoissa, ja sen pitää olla reviewerin saatavilla. Pelkkä "Virheenkorjauksia ja parannuksia" ei siis riitä.

Sama kappale koskee harhaanjohtavaa markkinointia: puuttuvan sisällön tai palvelun lupaamista tai väärän hinnan näyttämistä, App Storessa tai muualla.

Tästä osasta oli minulle hyötyä Noleran kanssa. Kun luin sen sivun läpi ennen julkaisua, löysin kaksi lausetta, joita ei voinut todentaa: "käyttöliittymä vain ranskaksi", joka oli muuttunut vääräksi, ja "suosituin paketti" sovellukselle, jota ei ollut koskaan julkaistu. Reviewerille tarkoitetut muistiinpanot kuvasivat myös tuotteen vanhentunutta tilaa. Juuri tähän tämä osa tähtää. 2.3.10 taas koskee lähinnä sovellussivua.

Mitä 2.3.1-hylkäysviesti tarkoittaa?

Hylkäyksen otsikko on "Guideline 2.3.1 - Performance", joskus perässä "Hidden Features". Kaksi React Native -kehittäjien julkaisemaa viestiä:

• Maaliskuu 2024, CodePushin GitHub-tiketissä: "The app contains hidden features.", ilman muita tarkennuksia. Kehittäjä pyytää tarkennusta ja saa lisäselvityksen kohdan 2.5.2 perusteella: "Your app, extension, or linked framework appears to contain code designed explicitly with the capability to change the app's behavior or functionality after App Review approval." Tiketistä ei selviä, menikö sovellus myöhemmin läpi.
• Helmikuu 2023, toisessa tiketissä Apple viittaa binäärin "CodePush-related remote code downloading/updating support" -ominaisuuteen.

Oma tulkintani: reviewer ei näe päivityksiäsi, se näkee koodin, joka pystyy vastaanottamaan niitä. Molemmat tapaukset koskevat CodePushia. En löytänyt tuoreita julkisia hylkäyksiä, jotka koskisivat EAS Updatea, mutta se ei todista mitään.

Etäpäivitykset: mitä 2.5.2 ja lisenssi sallivat

Sääntö 2.5.2, jota käsittelen myös taustatiloja koskevassa oppaassa, kieltää sovellusta toimimasta näin: "download, install, or execute code which introduces or changes features or functionality of the app".

Apple Developer Program License Agreementin kohta 3.3.1(B) kieltää ladattavan suoritettavan koodin, mutta tarkentaa: "Interpreted code may be downloaded to an Application". Kolmella ehdolla: koodi ei muuta sovelluksen pääasiallista tarkoitusta, se ei kierrä allekirjoitusta, hiekkalaatikkoa eikä järjestelmän tietoturvaa, eikä se luo kauppaa muille sovelluksille.

Expo-sovelluksen JavaScript on tulkattavaa koodia, joten mielestäni EAS Update mahtuu tähän kehykseen. Sen dokumentaatio muistuttaa, että päivitysten pitää noudattaa App Storen sääntöjä ja että "changes to your app's behavior need to be reviewed". Kriittiseen bugiin Expo ehdottaa etäkorjausta ja sen jälkeen uutta lähetystä, joka sisältää korjauksen.

Oma linjani: olemassa olevan korjaaminen ja hienosäätö, kyllä. Sen muuttaminen, mikä sovellus on tai mitä se myy, ei.

Mitä voit muuttaa etänä ja mikä vaatii uuden buildin

Käyttämäni taulukko, koottu tässä mainituista Applen ja Expon sivuista. Rivi "ilmainen muuttuu maksulliseksi" ja kaksi viimeistä ovat omaa tulkintaani.

Muutos	Reitti	Miksi
JavaScript-bugi	Etäpäivitys	Expon tarkoittama käyttö
Teksti, käännös, tyyli	Etäpäivitys	Expon tarkoittama käyttö
Tilauksen hinta	App Store Connect	Koodia ei muuteta
Mainosteksti	App Store Connect	Ei uutta lähetystä
Jo hyväksyttyä tyyppiä oleva osto	Vain oston arviointi	App Store Connectin sääntö
Tyyppinsä ensimmäinen osto	Uusi versio	App Store Connectin sääntö
Uusi toiminto	Uusi versio	2.3.1 ja 2.5.2
Ilmainen muuttuu maksulliseksi	Uusi versio	Sivu ja muistiinpanot uusiksi
Lupa, Info.plist	Uusi build	Binäärin tiedosto
Natiivimoduuli, Expo SDK	Uusi build	Natiivikoodi muuttuu
Kytkin, joka sammuttaa	Etäkonfiguraatio	Sallittu, jos väliaikainen
Kytkin, joka paljastaa	Kielletty	Toimintoa ei koskaan arvioitu

Mainostekstin voi muuttaa "without requiring an updated submission" Applen versiotietoja käsittelevän sivun mukaan. Kunkin tyypin ensimmäinen osto lähetetään uuden version mukana, seuraavat erikseen, kertoo ostojen lähettämistä koskeva ohje. Expo luokittelee natiivikoodin, luvat ja SDK-version asioiksi, jotka vaativat uuden binäärin, kuten ITMS-90683:n kohdalla. Kytkin, joka sammuttaa rikkinäisen toiminnon, ei lisää mitään uutta, kunhan se ei vie pois sitä, mistä tilaajat ovat maksaneet.

Etäkytkimet ilman hylkäystä

Etäkytkin eli feature flag ei ole sinänsä kielletty: kaikki riippuu siitä, mitä se piilottaa. Sääntöni:

• Kaikki, mitä kytkin voi näyttää, on mukana ja päällä reviewerille, ja nimetty arviointimuistiinpanoissa.
• A/B-testi vertaa kahta versiota, jotka reviewer voi nähdä, ei koskaan arvioitua ja ennennäkemätöntä versiota.
• Mikään koodi ei tunnista arviointia toimiakseen eri tavalla. Se on piilotetun toiminnon määritelmä.
• Etänä ohjattu paywall näyttää vain hyväksyttyjä tuotteita, ja jokainen versio noudattaa sääntöä 3.1.2.

Demotila ja testitilit

Guideline 2.1 vaatii demotilin, jos sovelluksessasi on kirjautuminen, ja palvelimen pitää olla päällä. Jos lakisääteiset tai tietoturvavelvoitteet estävät tilin antamisen, sisäänrakennettu demotila voi korvata sen, mutta vain "with prior approval by Apple", ja sen pitää näyttää kaikki toiminnot. Applen versiotietosivu lisää: tili ei vanhene, ja lisätilit merkitään muistiinpanoihin, joiden raja on 4 000 tavua.

Yhteys 2.3.1:een: demotila tai testitili, joka avaa muuten näkymättömiä näkymiä, pitää kuvata. Salainen ele, koodi tai erikoistili, josta ei kerrota, on piilotettu toiminto. Nimeä jokainen erikoispääsy muistiinpanoissa ja kerro, mitä se avaa.

Sääntöni: ei etäpäivityksiä arvioinnin aikana

Miksi EAS Update on minulla kaikkialla: herätyssovellukseni Solysissa JavaScript-bugi mykisti sovelluksen heti, kun ääniefekti epäonnistui kerran. Korjaus oli kolme riviä, mutta sen toimittamiseen tarvittiin kokonainen build ja arviointi. Siitä lähtien kaikissa sovelluksissani on ollut expo-updates ensimmäisestä buildista asti: se on natiivimoduuli, eikä ilman sitä käännetty binääri vastaanota koskaan mitään. Konfiguraationi app.json-tiedostossa:

{
  "expo": {
    "runtimeVersion": { "policy": "fingerprint" },
    "updates": { "fallbackToCacheTimeout": 0, "checkAutomatically": "ON_LOAD" }
  }
}

fingerprint-asetuksella päivitys menee vain binääreille, joiden natiivikoodi täsmää (runtime-versiot). Mutta kun versio odottaa arviointia tai on arvioitavana, en julkaise mitään. Kaksi syytä.

1. Reviewer ei näkisi korjausta. Kun fallbackToCacheTimeout on 0, uusi asennus käynnistyy sisäänrakennetulla koodilla ja ottaa päivityksen käyttöön seuraavalla käynnistyksellä (expo-updatesin dokumentaatio). Reviewer asentaa, käynnistää kerran ja testaa binäärin. Nolera hylättiin, vaikka korjaus oli jo toimitettu etänä: kerron siitä 2.1-oppaassa.
2. Sen, mitä reviewer testaa, pitää pysyä samana kuin se, mitä käyttäjät saavat. Toiminnan muuttaminen arvioinnin aikana luo eron nähdyn ja toimitetun version välille.

Tarkat arviointimuistiinpanot

2.3.1 hylkää yleisluontoiset kuvaukset. Malli, jota käyttäisin, englanniksi:

What's new in this version:
- [Feature]: [where to find it, how to test it].

Remote configuration:
- "[flag]" controls [feature]. It is ON for review.

Over-the-air updates:
- The app uses expo-updates for bug fixes only.
  No update will be published during this review.

Demo account: see Sign-in information. It never expires.

Miten vastata 2.3.1-hylkäykseen?

Vastaa App Store Connectissa, jossa vastaat App Review'n viestiin.

• Viesti on epämääräinen: kysy, mitä toimintoa tarkoitetaan, kuten vuoden 2024 tiketin kehittäjä teki.
• Oikea toiminto on kuvattu huonosti: anna tarkka polku ja lyhyt video, ja täydennä sitten muistiinpanot.
• Kytkin paljastaa jotain uutta: poista se tai laita se päälle ja kuvaa se, ja tee sitten uusi build.
• Syynä on päivityskoodi: selitä, että se on korjauksia varten kohdan 3.3.1(B) puitteissa. Vuoden 2023 tiketissä Apple vaati sen poistamista.

2.3.1-tarkistuslista ennen lähetystä

• Version jokainen uutuus on kuvattu muistiinpanoissa polkuineen.
• Jokainen etäkytkin on päällä arviointia varten ja nimetty muistiinpanoissa.
• Mikään koodi ei muuta toimintaansa reviewerin kohdalla.
• Erikoispääsyt on kuvattu: demotila, testitili, ele.
• Sovellussivu ja paywall eivät lupaa mitään, mitä build ei tee.
• Yhtään etäpäivitystä ei julkaista arvioinnin aikana.

Tarkista aineistosi ennen lähetystä

Review Kit sisältää tarkistuslistani ennen lähetystä, malleja testaajalle tarkoitettuihin muistiinpanoihin ja Claude Code -skillejä, jotka käyvät projektisi läpi. Jos haluat ihmissilmät, varaa tunti kanssani: käymme arviointimuistiinpanosi ja päivityskonfiguraatiosi läpi yhdessä videopuhelussa. Koko prosessi löytyy sivulta Applen hylkäämä sovellus.

Valmisteletko ensimmäistä julkaisuasi? Tee ilmainen diagnoosi: se laittaa vaiheet oikeaan järjestykseen ja lähettää sinulle tarkistuslistani Applen hylkäysten välttämiseen.

Usein kysytyt kysymykset

Mitä "Guideline 2.3.1 - Performance - Hidden Features" tarkoittaa?

Apple katsoo, että sovelluksessasi on piilotettu tai uinuva toiminto tai toiminto, joka puuttuu arviointimuistiinpanoista. Viesti voi koskea myös koodia, joka pystyy muuttamaan sovellusta arvioinnin jälkeen, joskus yhdessä 2.5.2-hylkäyksen kanssa.

Salliiko Apple EAS Updaten?

Lisenssi sallii ladattavan tulkattavan koodin, kunhan se ei muuta sovelluksen pääasiallista tarkoitusta. Korjaaminen kyllä. Arvioimattoman toiminnon lisääminen ei.

Voiko iOS-sovelluksessa käyttää feature flageja?

Kyllä, jos kaikki, mitä ne voivat näyttää, on arvioitu. Laita jokainen kytkin päälle arviointia varten ja kuvaa se muistiinpanoissa.

Pitääkö demotilasta kertoa reviewerille?

Kyllä. Sisäänrakennettu demotila vaatii Applen ennakkohyväksynnän, ja sen pitää näyttää kaikki toiminnot.

Voiko etäpäivityksen julkaista arvioinnin aikana?

Mikään ei kiellä sitä mustaa valkoisella. Reviewer ei kuitenkaan näkisi sitä ensimmäisellä käynnistyksellä, ja se luo eron arvioituun versioon. Minä jätän sen aina tekemättä.