Guideline 4.2 Minimum Functionality: elutasított app

A 4.2-es guideline, a „Minimum Functionality”, elutasítja azt az appot, ami semmivel sem ad többet egy weboldalnál, vagy túl keveset ahhoz, hogy megtartsák. A megoldás nem az, hogy egymásra halmozod a natív funkciókat: tegyél egyet a használat középpontjába, aztán mondd meg a reviewernek, hol találja. A javításhoz szinte mindig új build kell.

Saját iOS appokat adok ki: a Solys, a TradaZen és a Nolera fent vannak az App Store-ban. Ez az útmutató az Apple hivatalos szövegére épül, amit 2026. október 15-én olvastam, és olyan 4.2-es elutasításokra, amiket fejlesztők tettek közzé az Apple fórumain. A lentebb említett elutasított appok példák. Az összes elutasítási ok áttekintéséhez inkább olvasd el, miért utasítja el az Apple az appot.

Mit mond a 4.2-es guideline?

A 4.2 az App Review Guidelines 4. szakaszában, a „Design” részben található. Az első mondata rögzíti a mércét: „Your app should include features, content, and UI that elevate it beyond a repackaged website.” Vagyis az appodnak olyan funkciókat, tartalmat és felületet kell kínálnia, amik egy dobozba csomagolt weboldal fölé emelik.

A szöveg két gondolatot tesz hozzá. Az az app, ami nem igazán hasznos, egyedi vagy „app-like”, nem való az App Store-ba. És az az app, ami se tartós szórakozást, se elég hasznosságot nem nyújt, elutasítható. A 4.2 tehát két dolgot vizsgál: a különbséget a webhez képest, és az érték mennyiségét.

Az alszabályok, amikre az üzenet hivatkozhat

Alszabály	Amit az Apple kér	A tipikus elutasítás
4.2	Túllépni egy weboldalon	WebView-ban megjelenített oldal
4.2.1	Valódi kiterjesztett valóság élmény	Egy 3D modell letéve az AR nézetbe
4.2.2	Ne csak marketing vagy linkek legyenek	Kirakat app, aggregátor, linkek
4.2.3	Önálló app, egyértelmű letöltések	Másik appot igénylő app
4.2.6	Ne kereskedelmi sablonból készült app legyen	Szolgáltató által beküldött sablon

Három pontosítás. A 4.2.2 kivételt tesz a katalógusokkal: „Other than catalogs, apps shouldn't primarily be marketing materials, advertisements, web clippings, content aggregators, or a collection of links.” Egy termékkatalógus tehát átmehet. Egy reklámprospektus nem.

A 4.2.3-nak két pontja van. Az (i) azt kéri, hogy az app önmagában működjön, másik app telepítése nélkül. A (ii) azt kéri, hogy ha az appnak az első indításkor erőforrásokat kell letöltenie, jelezze a letöltés méretét, és előtte kérjen engedélyt.

A kereskedelmi sablonokról és appgeneráló szolgáltatásokról szóló 4.2.6-ot a 4.3-as guideline útmutatója részletezi, mert kéz a kézben jár a spamellenes szabállyal.

A két leggyakoribb 4.2-es üzenet

Az Apple üzenete a „Guideline 4.2 - Design - Minimum Functionality” címmel kezdődik. A folytatásból derül ki, melyik problémát látta a reviewer a kettő közül. Íme két megfogalmazás, amit fejlesztők tettek közzé az Apple fórumain. Pár évesek: a pontos szöveg változhatott, a két típus nem.

Az app egy weboldalra hasonlít. „Your app provides a limited user experience as it is not sufficiently different from a mobile browsing experience.” Ez az Apple fórumain közzétett üzenet egy döntő mondatot tartalmaz: „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.”

Az app túl sovány. „We found that the usefulness of your app is limited by the minimal amount of content or features it includes.” Ez a második üzenet a koncepció átgondolását kéri, és elismeri, hogy nincs számszerű szabály arra, mi számít hasznosnak vagy szórakoztatónak.

Ha egy becsomagolt weboldalhoz értesítéseket, helymeghatározást és megosztás gombot adsz, az nem elég: az Apple ezt a saját elutasításaiban leírta.

Négy tipikus 4.2-es elutasítási eset

Az alábbi négy eset a szabály szemléltetésére kitalált példa, nem valódi app.

A becsomagolt weboldal

Példa: egy sportklub WebView-ban jeleníti meg a mobilos oldalát, fölötte egy natív tabsávval. Az órarend, a foglalás és a fiók mind weboldalak. A reviewer ugyanazt látja, amit a Safari mutatna neki. Az Apple ezt az App Review oldalán ki is mondja: egy iOS appban kiszolgált weboldal, iOS-re nem igazított webes tartalom vagy korlátozott webes interakciók nem tesznek jó minőségű appot.

Amit én csinálnék: natívan újraépíteném a fő művelet képernyőit, itt az órarendet és a foglalást. Aztán hozzáadnám, amit a weboldal nem tud: emlékeztetőt az edzés előtt, hálózat nélkül is elérhető órarendet, a következő edzést egy widgetben.

A túl egyszerű app

Példa: egy app, ami naponta egy idézetet mutat, és semmi mást. Tíz másodperc alatt végigjárod. A 4.2 „lasting entertainment value or adequate utility”-ről beszél: tartós értékről vagy elegendő hasznosságról. A javításhoz a fő műveletnek adj mélységet, ne köré tegyél képernyőket. Itt: előzmények, kedvencek, emlékeztető a választott időpontban, widget a kezdőképernyőn.

Az AI-jal generált app, semmi natívval

Példa: egy szövegmező, egy gomb, egy AI-válasz nyers szövegként. Az Apple nem az eszközt ítéli meg, hanem azt, ami a reviewer képernyőjén megjelenik. Ha az élmény elfér egy weboldalon, a 4.2 jó eséllyel lecsap.

Hogy mit csinál jól az AI és mit ront el, azt az app készítése AI-jal cikkben részletezem. Hogy melyik generátor milyen formátumot ad, webappot vagy mobilprojektet, azt a Lovable, Rork vagy FlutterFlow cikk hasonlítja össze.

A tartalomra váró üres héj

Példa: egy piactér hirdetések nélkül, egy üres címjegyzék, egy hírfolyam, ami azt írja: „Hamarosan elérhető”. A reviewer olyan appot nyit meg, aminek nincs mit mutatnia. Ez az eset a 2.1-et is érinti, ami elutasítja az ideiglenes tartalmat: lásd a 2.1-es guideline útmutatóját. Akkor küldd be az appot, amikor valódi tartalma van, vagy adj meg egy már feltöltött demó fiókot.

A teszt, amit csinálok: „És a Safariban?”

Beküldés előtt megkérdezem magamtól, hogy egy weboldal tudná-e ugyanazt a fő funkciót nyújtani. Ha igen, az app ki van téve a 4.2-nek. Íme a szempontrendszerem egy natív funkció megítéléséhez. Egy funkció akkor számít, ha a fő műveletet szolgálja, nem akkor, ha díszít.

Funkció	Akkor számít, ha...	Nem elég, ha...
Értesítések	Várt információt hoznak	Csak a cikkeidet továbbítják
Offline mód	A fő tartalom használható marad	Csak egy hibaképernyő jelenik meg
Widget	A felhasználó saját adatát mutatja	A logódat mutatja
Megosztás	Tartalmat lehet küldeni az appodba	Csak egy linket oszt meg
Kamera, szenzorok	A fő művelet részei	A weboldaladat nyitják meg
Helyi adatok	Az app számol, rendez és emlékszik	Minden egy weboldalon él

Az Apple ajánlásai is ebbe az irányba mutatnak. Egy widget aktuális tartalmat mutat, egy pillantással olvashatót. Egy értesítés hasznos információt ad, kevés szóval, és nem arra való, hogy egy appbeli feladat felé terelje a felhasználót.

Amit az appjaim tudnak, és egy weboldal nem

Minden appot egy olyan fő funkció köré tervezek, ami nem létezik böngészőben, vagy egy olyan érték köré, ami visszahozza a felhasználót.

• A Solys egy ébresztőóra. A csörgés az AlarmKiten, az iOS 26 ébresztő szolgáltatásán keresztül megy: átüt a néma módon, mint az Apple ébresztője. A kikapcsolásához meg kell nyerni egy minijátékot, és a kiválasztott appok ébredés után szüneteltetve maradnak. Egyetlen weboldal sem tud megszólaltatni egy néma iPhone-t.
• A TradaZen egy tőzsdei szimulátor: valódi grafikon egy valódi dátumon, egy döntés, felfedődő gyertyák, rangsorolt párbajok és egy fejlődő rang. Itt nem egy natív funkció viszi az appot. Hanem a tartós szórakoztató érték, amiről a 4.2 beszél.
• A Nolera egy gardróbapp: lefényképezed a ruháidat, az app kivágja és rendszerezi őket, aztán minden reggel ajánl egy szettet. A kamera a fő művelet része. Nem bónusz.

A 4.2 nem natív funkciók listáját követeli meg: azt követeli meg, hogy legyen ok az app telepítésére egy weboldal megnyitása helyett.

A 4.2-es elutasítás javítása lépésről lépésre

1. Azonosítsd a típust. Webes böngészés: ez a becsomagolt weboldal. Minimális tartalom vagy funkció: ez a túl sovány app. 4.2.3: függőség egy másik apptól, vagy be nem jelentett letöltés.
2. A terméket változtasd meg, ne a megfogalmazást. Egy válasz, ami érvel, de semmit sem változtat, semmi okot nem ad a meggyőzésre. Építsd újra natívan a fő művelet képernyőit, vagy add hozzá a hiányzó mélységet.
3. Számolj új builddel. Az ok az appban van: egy távoli frissítés nem elég. Minden beküldés újra sorba kerül, lásd az App Store jóváhagyási idő cikket.
4. Írj olyan review notes-t, ami eligazít. Az Apple a teljes review-hoz szükséges információkról szóló oldalán azt kéri, hogy írd le a koncepciót, a funkciókat és a célközönséget. Frissítésnél: mi változott, és hol található.
5. Csak akkor fellebbezz, ha a reviewer elnézett valamit. Ha a natív funkciód már létezett, de nem vették észre, válaszolj az App Store Connectben egy rövid videóval. Az App Review Boardhoz akkor indokolt fellebbezni, ha félreértették az appodat, nem akkor, ha sovány.

A notes sablon, amit én használnék, angolul, testre szabandó:

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]

Csak azt írd le, ami a beküldött buildben létezik. Egy beharangozott, de megtalálhatatlan funkció újabb elutasítást hozna, ezúttal a 2.1 alapján.

A 4.2-es checklist beküldés előtt

• Egy mondatban el tudod mondani, mit tud az appod, amit egy weboldal nem.
• A fő művelet képernyői natívak, nem weboldalak.
• Minden natív funkció a fő műveletet szolgálja, és a reviewer két percen belül találkozik vele.
• Az appnak az első indítástól valódi tartalma van, vagy van feltöltött demó fiók.
• Az app önmagában működik, nem kell hozzá másik app.
• Egy nagy letöltés az első indításkor jelzi a méretét és engedélyt kér.
• A review notes leírja a koncepciót, a célközönséget és minden funkció helyét.
• Ha az ötleted súrolja a határt, kódolás előtt tesztelted egy jól behatárolt iOS app MVP-vel.

Átmenni a 4.2-n már a következő beküldésnél

Ha az appodat most utasították el 4.2 alapján, az Apple Review Kit segít megtalálni a hivatkozott szabályt és azt, amit kér, a tesztelőnek szóló notes sablonokkal együtt. Ha még építesz, az iOS Kit útvonala a fő funkcióból indul ki, még az első kódsor előtt. Ha emberi szemre van szükséged, foglalj velem egy órát. A teljes folyamat az Apple által elutasított app oldalon van.

Ha az első megjelenésedre készülsz, csináld meg az ingyenes diagnosztikát: sorba rakja a lépéseket, és elküldi neked az Apple-elutasítás elleni checklistemet. A kezdőlap megmutatja, hogyan készíts mobilappot úgy, hogy már az elejétől a review-ra legyen tervezve.

Senki sem garantálhatja, hogy az Apple elfogadja az appodat. Abban tudok segíteni, hogy okot adj neki a létezésre az App Store-ban.

Gyakori kérdések

Mit jelent a „Guideline 4.2 - Design - Minimum Functionality”?

Ez a minimális funkcionalitás miatti elutasítás címe. Az Apple úgy ítéli meg, hogy az appod túlságosan hasonlít egy weboldalra, vagy túl kevés tartalmat vagy funkciót kínál. Ugyanez a cím egy alszabályra is utalhat: „Guideline 4.2.2” egy kirakat app vagy linkgyűjtemény esetén, 4.2.3 egy másik apptól függő app esetén.

Egy WebView-s appot mindig elutasítanak?

Nem. A szabály az appba csomagolt weboldalt célozza, nem a technológiát. A reviewer a fő élményt ítéli meg: ha a képernyői olyan weboldalak, amik ugyanazt csinálják, mint a Safari, nagy a kockázat. Egy böngészőben megnyíló súgóoldal nem erről szól.

Elég push értesítéseket hozzáadni, hogy átmenj a 4.2-n?

Nem. Egy, a fórumain közzétett elutasító üzenetben az Apple azt írja, hogy az értesítések, a helymeghatározás és a megosztás nem elegendők ahhoz, hogy az élmény elég gazdag legyen. Egy értesítés akkor számít, ha a fő funkciót szolgálja, mint egy ébresztő vagy egy a felhasználó által választott emlékeztető.

Mi a különbség a 4.2-es és a 4.3-as guideline között?

A 4.2 az appodat önmagában ítéli meg: ad-e eleget egy weboldalhoz képest? A 4.3 másokhoz hasonlítja: másolat, variáns, vagy csak még egy app egy telített kategóriában? Ugyanaz az app mindkettőt megkaphatja, de nem ugyanúgy kell javítani őket.

Kell új build egy 4.2-es elutasítás után?

Szinte mindig, hiszen az ok magában az appban van. Egyetlen kivétel: a reviewer nem talált meg egy funkciót, ami már létezett. Ilyenkor válaszolj az App Store Connectben pontos notes-szal és egy rövid videóval, a build módosítása nélkül.