Guideline 4.2 Minimum Functionality: hylätty sovellus

Guideline 4.2, "Minimum Functionality", hylkää sovelluksen, joka ei tarjoa mitään enempää kuin verkkosivu, tai tarjoaa liian vähän, jotta sitä kannattaisi pitää puhelimessa. Ratkaisu ei ole kasata natiiveja toimintoja päällekkäin. Laita yksi niistä käytön ytimeen ja kerro reviewerille, mistä sen löytää. Korjaus vaatii lähes aina uuden buildin.

Julkaisen omia iOS-sovelluksiani: Solys, TradaZen ja Nolera ovat App Storessa. Tämä opas perustuu Applen viralliseen tekstiin, jonka luin 15. lokakuuta 2026, sekä 4.2-hylkäyksiin, joita kehittäjät ovat julkaisseet Applen foorumeilla. Alempana mainitut hylätyt sovellukset ovat esimerkkejä. Jos haluat yleiskuvan kaikista hylkäysperusteista, lue mieluummin miksi Apple hylkää sovelluksen.

Mitä guideline 4.2 sanoo?

4.2 löytyy App Review Guidelinesin osiosta 4, "Design". Sen ensimmäinen lause asettaa kriteerin: "Your app should include features, content, and UI that elevate it beyond a repackaged website." Toisin sanoen sovelluksesi pitää tarjota toimintoja, sisältöä ja käyttöliittymä, jotka nostavat sen uuteen pakkaukseen laitetun verkkosivun yläpuolelle.

Teksti lisää kaksi ajatusta. Sovellus, joka ei ole aidosti hyödyllinen, ainutlaatuinen tai "app-like", ei kuulu App Storeen. Ja sovellus, joka ei tarjoa kestävää viihdettä eikä riittävää hyötyä, voidaan hylätä. 4.2 arvioi siis kahta asiaa: eroa verkkoon ja arvon määrää.

Alasäännöt, joihin viesti voi viitata

Alasääntö	Mitä Apple vaatii	Tyypillinen hylkäys
4.2	Enemmän kuin verkkosivu	Sivu näytetään WebView'ssä
4.2.1	Aito lisätyn todellisuuden kokemus	3D-malli asetettu AR-näkymään
4.2.2	Ei pelkkää markkinointia tai linkkejä	Esittelysovellus, kokoaja, linkit
4.2.3	Itsenäinen sovellus, selkeät lataukset	Sovellus vaatii toisen sovelluksen
4.2.6	Ei kaupallisesta pohjasta tehtyä sovellusta	Palveluntarjoajan lähettämä template

Kolme tarkennusta. 4.2.2 tekee poikkeuksen katalogeille: "Other than catalogs, apps shouldn't primarily be marketing materials, advertisements, web clippings, content aggregators, or a collection of links." Tuotekatalogi voi siis mennä läpi. Mainosesite ei.

4.2.3:ssa on kaksi kohtaa. Kohta (i) vaatii, että sovellus toimii yksinään ilman toisen sovelluksen asentamista. Kohta (ii) vaatii, että jos sovellus lataa resursseja ensimmäisellä käynnistyskerralla, se kertoo latauksen koon ja pyytää luvan etukäteen.

4.2.6 kaupallisista pohjista ja sovellusgeneraattoripalveluista käydään läpi guideline 4.3:n oppaassa, koska se kulkee käsi kädessä roskapostisäännön kanssa.

Kaksi yleisintä 4.2-viestiä

Applen viesti alkaa otsikolla "Guideline 4.2 - Design - Minimum Functionality". Loppuosa kertoo, kumman kahdesta ongelmasta reviewer huomasi. Tässä kaksi muotoilua, jotka kehittäjät ovat julkaisseet Applen foorumeilla. Ne ovat muutaman vuoden takaa: tarkka teksti on voinut muuttua, mutta kaksi perhettä ei.

Sovellus näyttää verkkosivulta. "Your app provides a limited user experience as it is not sufficiently different from a mobile browsing experience." Tämä Applen foorumeilla julkaistu viesti sisältää ratkaisevan lauseen: "Including iOS features such as push notifications, Core Location, and sharing do not provide a robust enough experience to be appropriate for the App Store."

Sovellus on liian ohut. "We found that the usefulness of your app is limited by the minimal amount of content or features it includes." Tämä toinen viesti pyytää miettimään konseptin uudelleen ja myöntää, ettei mikään numeerinen sääntö määrittele, mikä on hyödyllistä tai viihdyttävää.

Ilmoitusten, sijainnin ja jakopainikkeen lisääminen paketoituun verkkosivuun ei riitä: Apple on kirjoittanut sen omiin hylkäyksiinsä.

Neljä tyypillistä 4.2-hylkäystä

Alla olevat neljä tapausta ovat esimerkkejä, jotka on rakennettu havainnollistamaan sääntöä. Ne eivät ole oikeita sovelluksia.

Paketoitu verkkosivu

Esimerkki: urheiluseura näyttää mobiilisivunsa WebView'ssä, ja sen päällä on natiivi välilehtipalkki. Aikataulu, varaukset ja tili ovat verkkosivuja. Reviewer näkee saman, minkä Safari näyttäisi. Apple sanoo sen App Review -sivullaan: iOS-sovelluksessa tarjoiltu verkkosivu, iOS:lle sovittamaton verkkosisältö tai rajalliset verkkovuorovaikutukset eivät tee laadukasta sovellusta.

Mitä tekisin: rakentaisin päätoiminnon näkymät natiivisti uudelleen, tässä aikataulun ja varaukset. Sitten lisäisin sen, mihin sivu ei pysty: muistutuksen ennen treeniä, aikataulun ilman verkkoyhteyttä ja seuraavan treenin widgetissä.

Liian yksinkertainen sovellus

Esimerkki: sovellus, joka näyttää yhden sitaatin päivässä, eikä mitään muuta. Sen näkee kokonaan kymmenessä sekunnissa. 4.2 puhuu "lasting entertainment value or adequate utility" -arvosta: kestävästä arvosta tai riittävästä hyödystä. Korjaa lisäämällä syvyyttä päätoimintoon, ei näkymiä sen ympärille. Tässä: historia, suosikit, muistutus valittuun aikaan ja widget kotinäytölle.

Tekoälyllä tehty sovellus ilman mitään natiivia

Esimerkki: tekstikenttä, painike ja tekoälyn vastaus pelkkänä tekstinä. Apple ei arvioi työkalua vaan sitä, mitä reviewerin näytölle tulee. Jos kokemus mahtuu verkkosivulle, 4.2 osuu hyvin todennäköisesti.

Kerron tarkemmin, missä tekoäly onnistuu ja missä se epäonnistuu, jutussa sovelluksen tekeminen tekoälyllä. Kunkin generaattorin tuottamaa muotoa, verkkosovellusta tai mobiiliprojektia, vertaillaan jutussa Lovable, Rork vai FlutterFlow.

Kuori, joka odottaa sisältöä

Esimerkki: kauppapaikka ilman ilmoituksia, tyhjä hakemisto tai syöte, jossa lukee "Tulossa pian". Reviewer avaa sovelluksen, jolla ei ole mitään näytettävää. Tämä koskee myös sääntöä 2.1, joka hylkää väliaikaisen sisällön: katso guideline 2.1:n opas. Lähetä sovellus, kun siinä on oikeaa sisältöä, tai anna valmiiksi täytetty demotili.

Testi, jonka teen: "Entä Safarissa?"

Ennen lähettämistä kysyn itseltäni, voisiko verkkosivu tarjota saman päätoiminnon. Jos voisi, sovellus on alttiina 4.2:lle. Tässä taulukkoni natiivin toiminnon arviointiin. Toiminto merkitsee, kun se palvelee päätoimintoa, ei silloin kun se on koriste.

Toiminto	Se merkitsee, kun...	Se ei riitä, kun...
Ilmoitukset	Ne tuovat odotettua tietoa	Ne välittävät artikkeleitasi
Offline	Pääsisältö pysyy käytettävänä	Näkyviin tulee vain virhenäkymä
Widget	Se näyttää käyttäjän omaa dataa	Se näyttää logosi
Jakaminen	Sisältöä lähetetään sovellukseesi	Se jakaa vain linkin
Kamera, sensorit	Ne ovat osa päätoimintoa	Ne avaavat sivustosi
Paikallinen data	Sovellus laskee, järjestää ja muistaa	Kaikki elää verkkosivulla

Applen suositukset osoittavat samaan suuntaan. Widget näyttää ajankohtaista sisältöä, joka on luettavissa yhdellä silmäyksellä. Ilmoitus tuo hyödyllistä tietoa lyhyesti, eikä sitä käytetä houkuttelemaan tehtävään sovelluksessa.

Mitä minun sovellukseni tekevät, mihin sivusto ei pysty

Suunnittelen jokaisen sovelluksen sellaisen päätoiminnon ympärille, jota ei ole selaimessa, tai sellaisen arvon ympärille, joka saa palaamaan.

• Solys on herätyskello. Hälytys kulkee AlarmKitin kautta, joka on iOS 26:n hälytyspalvelu: se ohittaa äänettömän tilan kuten Applen oma herätyskello. Sammuttaakseen sen pitää voittaa minipeli, ja valitut sovellukset pysyvät tauolla herätyksen jälkeen. Mikään verkkosivu ei saa äänetöntä iPhonea soimaan.
• TradaZen on kaupankäyntisimulaattori: oikea kaavio oikealta päivältä, päätös, paljastuvat kynttilät, rankatut kaksintaistelut ja nouseva taso. Tässä sovellusta ei kanna natiivi toiminto. Sitä kantaa se kestävä viihdearvo, josta 4.2 puhuu.
• Nolera on vaatekaappi: kuvaat vaatteesi, sovellus rajaa ne irti taustasta ja järjestää ne, ja ehdottaa sitten asun joka aamu. Kamera on osa päätoimintoa. Se ei ole bonus.

4.2 ei vaadi listaa natiiveista toiminnoista. Se vaatii syyn asentaa sovellus sen sijaan, että avaisi sivuston.

4.2-hylkäyksen korjaaminen vaihe vaiheelta

1. Tunnista perhe. Verkkoselaaminen: kyse on paketoidusta sivustosta. Vähäinen sisältö tai toiminnot: sovellus on liian ohut. 4.2.3: riippuvuus toisesta sovelluksesta tai ilmoittamaton lataus.
2. Muuta tuotetta, älä muotoilua. Vastaukselle, joka väittelee muuttamatta mitään, ei ole syytä vakuuttaa. Rakenna päätoiminnon näkymät natiivisti uudelleen tai lisää puuttuva syvyys.
3. Varaudu uuteen buildiin. Syy on sovelluksessa: etäpäivitys ei riitä. Jokainen lähetys menee jonoon uudelleen, katso App Storen tarkastusaika.
4. Kirjoita ohjaavat review-muistiinpanot. Apple pyytää täydellisen tarkastuksen tiedot -sivullaan kuvaamaan konseptin, toiminnot ja kohdeyleisön. Päivityksessä: mikä muuttui ja mistä sen löytää.
5. Valita vain, jos reviewer ohitti jotain. Jos natiivi toimintosi oli jo olemassa mutta jäi huomaamatta, vastaa App Store Connectissa lyhyen videon kera. Valitus App Review Boardille on perusteltu, kun sovelluksesi ymmärrettiin väärin, ei silloin kun se on ohut.

Muistiinpanopohja, jota käyttäisin, englanniksi, muokattavaksi:

Hello App Review team,

Thank you for your feedback regarding Guideline 4.2.

What changed in build [X]:
- [Main feature] is now fully native: [what the user does].
- [Native feature]: [what it brings]. Where: [screen > button].
- [Second native feature]: [what it brings]. Where: [screen].
- Web content is limited to [legal pages, help].

How to test in two minutes:
1. Launch the app and [main action].
2. Turn on Airplane mode: [content] stays available.
3. Add the widget from the Home Screen: it shows [data].

Best regards,
[Your name]

Kirjoita vain se, mikä on lähetetyssä buildissa. Luvattu toiminto, jota ei löydy, toisi uuden hylkäyksen, tällä kertaa säännön 2.1 perusteella.

4.2-tarkistuslista ennen lähettämistä

• Osaat sanoa yhdellä lauseella, mitä sovelluksesi tekee, mihin sivusto ei pysty.
• Päätoiminnon näkymät ovat natiiveja, eivät verkkosivuja.
• Jokainen natiivi toiminto palvelee päätoimintoa, ja reviewer kohtaa sen alle kahdessa minuutissa.
• Sovelluksessa on oikeaa sisältöä ensimmäisestä käynnistyksestä alkaen, tai täytetty demotili.
• Sovellus toimii yksinään ilman muita asennettavia sovelluksia.
• Suuri lataus ensimmäisellä käynnistyksellä kertoo kokonsa ja pyytää luvan.
• Review-muistiinpanot kuvaavat konseptin, kohdeyleisön ja jokaisen toiminnon sijainnin.
• Jos ideasi on rajoilla, testasit sen ennen koodaamista hyvin rajatulla iOS-sovelluksen MVP:llä.

Läpi 4.2:sta jo seuraavalla lähetyksellä

Jos sovelluksesi hylättiin juuri 4.2:n perusteella, Apple Review Kit auttaa löytämään mainitun säännön ja sen vaatimukset, ja sisältää muistiinpanopohjat testaajalle. Jos rakennat vielä, iOS Kitin polku lähtee liikkeelle päätoiminnosta ennen ensimmäistä koodiriviä. Jos haluat ihmisen näkemyksen, varaa tunti kanssani. Koko prosessi on sivulla Applen hylkäämä sovellus.

Jos valmistelet ensimmäistä julkaisuasi, tee ilmainen diagnostiikka: se laittaa vaiheet järjestykseen ja lähettää sinulle hylkäyksiä ehkäisevän tarkistuslistani. Etusivulla näytetään, miten luoda mobiilisovellus, joka on alusta asti suunniteltu reviewta varten.

Kukaan ei voi taata, että Apple hyväksyy sovelluksesi. Voin auttaa sinua antamaan sille syyn olla App Storessa.

Usein kysytyt kysymykset

Mitä "Guideline 4.2 - Design - Minimum Functionality" tarkoittaa?

Se on vähäisen toiminnallisuuden hylkäyksen otsikko. Apple katsoo, että sovelluksesi muistuttaa liikaa verkkosivua tai tarjoaa liian vähän sisältöä tai toimintoja. Sama otsikko voi viitata alasääntöön: "Guideline 4.2.2" esittelysovellukselle tai linkkilistalle, 4.2.3 sovellukselle, joka riippuu toisesta sovelluksesta.

Hylätäänkö WebView-sovellus aina?

Ei. Sääntö koskee sovellukseen paketoitua verkkosivua, ei teknologiaa. Reviewer arvioi pääkokemuksen: jos sen näkymät ovat verkkosivuja, jotka tekevät saman kuin Safari, riski on suuri. Selaimessa avautuva ohjesivu ei ole ongelma.

Riittääkö push-ilmoitusten lisääminen 4.2:n läpäisemiseen?

Ei. Foorumeillaan julkaistussa hylkäysviestissä Apple kirjoittaa, että ilmoitukset, sijainti ja jakaminen eivät riitä tekemään kokemuksesta tarpeeksi rikasta. Ilmoitus merkitsee, kun se palvelee päätoimintoa, kuten herätys tai käyttäjän itse valitsema muistutus.

Mikä ero on guidelinejen 4.2 ja 4.3 välillä?

4.2 arvioi sovelluksesi yksinään: tuoko se tarpeeksi verrattuna verkkosivuun? 4.3 vertaa sitä muihin: onko se kopio, variantti tai vielä yksi sovellus kyllästyneessä kategoriassa? Sama sovellus voi saada molemmat, mutta niitä ei korjata samalla tavalla.

Tarvitaanko uusi build 4.2-hylkäyksen jälkeen?

Lähes aina, koska syy on itse sovelluksessa. Ainoa poikkeus: reviewer ei löytänyt toimintoa, joka oli jo olemassa. Silloin vastaa App Store Connectissa tarkoilla muistiinpanoilla ja lyhyellä videolla buildia muuttamatta.