# Mobilalkalmazás specifikáció: egyoldalas sablon > Egyoldalas specifikáció, ami keretet ad a saját iOS appodnak és irányítja az AI-t: 10 kérdés, másolható sablon, és amit semmiképp ne írj bele. Eredeti oldal: [Mobilalkalmazás specifikáció: egyoldalas sablon](https://devoria.fr/hu/blog/mobilalkalmazas-specifikacio-egyoldalas-sablon) Szerző: [Mehdi Azizi](https://devoria.fr/hu/mehdi-azizi) Megjelenés: 2026-08-31 A tartalom utolsó frissítése: 2026-10-09 ## Mobilalkalmazás specifikációja: a rövid válasz Ha a saját appodat készíted, egy jó mobilalkalmazás-specifikáció elfér egy oldalon. Tíz kérdésre válaszol: kinek szól, milyen problémát old meg, mi a fő funkció, hogyan termel pénzt az app, mi történik fiók nélkül, milyen adatoknak kell megmaradniuk, melyik platformra készül, mi marad ki az első verzióból, honnan tudod, hogy működik, és milyen korlátaid vannak. A másolható sablon lejjebb található. A [vázlatot és az ellenőrző táblázatát (.md) le is töltheted](https://devoria.fr/ressources/cahier-des-charges-app-ios.md), regisztráció nélkül. A neten talált 40 oldalas sablonok más célra készültek: annak az ügyfélnek, aki egy fejlesztőtől rendel appot, és szerződéses dokumentumra van szüksége. Te egyszerre döntesz és építesz, gyakran AI segítségével. A te specifikációd két dologra való: hogy kódolás előtt meghozd a döntéseket, és hogy a Claude, a ChatGPT vagy a Cursor tiszta kontextust kapjon, és a megfelelő appot építse meg. Saját iOS appokat adok ki. A Solys, egy minijátékos ébresztőóra, és a TradaZen, egy tőzsdei szimulátor, fent vannak az App Store-ban. A Nolerát és a Clicet az Apple elutasította, aztán kijavítottam őket. Mindegyiknél ezt a módszert alkalmazom, és most neked is ezt ajánlom. ## Miért elég egy oldal a saját appod megtervezéséhez? Egy hosszú dokumentum azt az érzést kelti, hogy haladtál. A gyakorlatban egyszer megírod, ritkán olvasod újra, és a projekt már az első hetekben eltávolodik tőle. Egy oldalt viszont két perc alatt átfutsz minden munkamenet előtt. A helyszűkének hasznos hatása is van: döntésre kényszerít. Ha egy válasz két mondatnál hosszabb, az gyakran azt jelenti, hogy a döntés még nem született meg. Jobb ezt egy papíron felfedezni, mint a kódodban, három héttel később. Végül egy oldal pont jó méret az AI-nak. Bemásolhatod egészben egy beszélgetésbe, vagy beteheted a projekted kontextusfájljába. Egy rövid dokumentumot könnyebb átnézni, és kevesebb benne az ellentmondásos utasítás. Azt viszont nem garantálja, hogy az AI követni is fogja: ellenőrizd a javaslatait ehhez a kerethez képest. ## Mit tartalmazzon egy mobilalkalmazás specifikációja? Mindegyik kérdésre egy-két mondatban válaszolj. 1. **Ki használja az appot, és milyen helyzetben?** Nem „a 18-35 évesek”. Inkább egy konkrét ember, a napja egy konkrét pillanatában. 2. **Milyen problémát old meg az app, egy mondatban?** Ha kell az „és még”, akkor két appot írsz le. 3. **Mi AZ első verzió fő funkciója?** Csak egy. A többi megvárja a számokat. Az [iOS app MVP](https://devoria.fr/hu/expertise/ios-mvp-alkalmazas) oldal elmagyarázza, hogyan válassz. 4. **Hogyan termel pénzt az app?** Előfizetés, egyszeri vásárlás vagy ingyenes. Ez a válasz már az első képernyőtől megváltoztatja az appot. Ha bizonytalan vagy, olvasd el: [előfizetés vagy egyszeri vásárlás egy iOS appnál](https://devoria.fr/hu/blog/elofizetes-vagy-egyszeri-vasarlas-ios-app). 5. **Mit lehet csinálni fiók létrehozása nélkül?** Ha korán eldöntöd, mi érhető el regisztráció nélkül, nem kell újraépítened az egész belépési folyamatot. 6. **Milyen adatoknak kell túlélniük egy telefoncserét?** Ez a kérdés dönti el, kell-e backend, például Supabase, vagy maradhat minden a készüléken. 7. **Csak iOS, vagy iOS és Android?** A tanácsom kezdőként: először iOS. Hogy miért, azt az [iOS és Android app egyszerre](https://devoria.fr/hu/blog/ios-vagy-android-app-melyikkel-kezdj) cikkben részletezem. 8. **Mi marad kifejezetten KI az első verzióból?** Ez a dokumentum leghasznosabb része. Elvágja a vitákat, mielőtt kialakulnának, saját magaddal és az AI-jal is. 9. **Honnan fogod tudni, hogy működik?** Egyetlen jel, ami a megjelenést követő hetekben mérhető: elindított ingyenes próbaidőszakok, előfizetők, visszatérő felhasználók. 10. **Mik a valódi korlátaid?** Mennyi időt tudsz rá szánni hetente, milyen eszközeid vannak, és az [Apple Developer fiókod](https://devoria.fr/hu/blog/apple-fejlesztoi-fiok-ar), ami [évi 99 dollárba](https://developer.apple.com/programs/enroll/) kerül. Nincs Maced? Ez nem akadály, ahogy a [iOS app kiadása Mac nélkül](https://devoria.fr/hu/blog/ios-app-kozzetetele-mac-nelkul-expo-eas) cikkben elmagyarázom. ## A másolható specifikációsablon Másold be ezt a sablont egy jegyzetbe vagy egy szövegfájlba a projekted gyökerében, aztán töltsd ki minden sorát. - **Az app ideiglenes neve:** … - **Kinek:** egy embernek, aki … amikor … - **A megoldott probléma, egy mondatban:** … - **Az 1. verzió fő funkciója:** … - **Amit a felhasználó lát, amikor először megnyitja az appot:** … - **Üzleti modell:** előfizetés / egyszeri vásárlás / ingyenes, és mi a fizetős: … - **Fiók nélkül lehet:** … - **Két telefon között megőrzendő adatok:** nincs / … - **Platform:** először iOS (Android később, ha a számok igazolják) - **Kimarad az 1. verzióból:** …, …, … - **A siker jele:** … - **Stack:** React Native, Expo, Supabase, ha fiókok kellenek, RevenueCat az előfizetésekhez - **Korlátok:** … óra hetente, van-e már Apple Developer fiók, van-e Mac - **Appok, amelyeknek szeretem az élményét, és miért:** … Tegyél mellé három-öt képernyőképet olyan appokról, amelyeket szeretsz, egy-egy szóval arról, mi tetszik bennük. Ez többet mond egy arculati kézikönyvnél, neked és az AI-nak is. > A specifikáció nem kívánságlista. Hanem a meghozott döntések listája. ## Példa: kitöltött oldal egy kitalált apphoz Hogy lásd, milyen részletességre van szükség, íme a sablon kitöltve egy példának kitalált appra, egy tanulási időzítőre. - **Kinek:** egy egyetemistának, aki este egyedül tanul, és tíz perc után elkalandozik. - **Probléma:** nem bír ki egy tanulási blokkot anélkül, hogy a telefonjához nyúlna. - **Fő funkció:** időzített tanulási blokk indítása, és a megtartott napok sorozatának megjelenítése. - **Első képernyő:** egyetlen gomb egy blokk indításához. - **Üzleti modell:** előfizetés a részletes statisztikákért, az alap blokk ingyenes. - **Fiók nélkül:** minden, kivéve a két telefon közötti mentést. - **Kimarad az 1. verzióból:** csoportos mód, rangsor a barátok között, widgetek, Android-verzió. - **A siker jele:** felhasználók, akik több egymást követő napon visszatérnek. Figyeld meg, mi hiányzik szándékosan: nincs húszképernyős lista, nincsenek kötelező színek, nincs architektúra. Ezek a döntések építés közben jönnek, az oldal pedig arra jó, hogy ellenőrizd: továbbra is a fő funkciót szolgálják. ## Hogyan irányítsd az AI-t a specifikációddal? Itt hozza a legtöbbet az oldalad. Egy kontextus nélkül kódoló AI találgat, és gyakran egy egészen másik appot talál ki, mint a tiéd. **Tedd az oldalt a projekt állandó kontextusába.** A Claude Code beolvas egy `CLAUDE.md` fájlt a gyökérből, a Cursornak saját szabályfájljai vannak. Másold be oda a specifikációdat a stackeddel együtt. Így minden kérés ugyanabból az alapból indul. **Hivatkozz a „kimarad az 1. verzióból” részre, amikor az AI túlzásba esik.** Az asszisztensek szívesen javasolnak plusz funkciókat: sötét módot, megosztást, értesítést. A kizárási listád kész választ ad: most nem. **Kérj olyan tervet, ami tiszteletben tartja az oldalt.** Egy nagyobb munka előtt írd be: „itt a specifikációm, javasolj tervet a fő funkcióhoz, még ne kódolj”. Azonnal látod, ha a terv eltávolodik attól, amit eldöntöttél. **Ne csak a kódot nézesd át vele, hanem az oldalt is.** Kérdezd meg: „ebben a specifikációban mely kérdések homályosak vagy ellentmondásosak?”. Ez az AI egyik alábecsült felhasználási módja, és heteknyi rossz irányba végzett munkától kímél meg. Ha tovább mennél ebben a témában, a buktatókat és az ellenőrzéseket a [iOS app készítése AI-jal](https://devoria.fr/hu/blog/ios-app-keszitese-ai-buktatok-ellenorzes) cikkben részleteztem. ## A döntések átalakítása elfogadási kritériumokká Egy fő funkciónak megfigyelhető eredménnyel kell járnia. A példa kitalált időzítőjénél „az időzítő működik” túl homályos. Írd inkább ezt: „Elindítok egy blokkot, megjelenik a hátralévő idő, le tudom állítani, és az app újranyitása után megtalálom az utolsó befejezett blokkot.” Külön döntsd el, hogy az időzítőnek zárolt képernyőnél is futnia kell-e: ez a döntés megváltoztathatja a technikai munkát. Minden funkcióhoz írj három sort: **művelet**, **elvárt eredmény**, **bizonyíték**. A bizonyíték lehet automatizált teszt egy számításnál, vagy ellenőrzés a készüléken egy folyamatnál. Azt is jegyezd fel, mit nem teszteltél. Ez a kis táblázat megakadályozza, hogy összekeverd a kész képernyőt a használatra kész funkcióval. Íme egy kitöltött táblázat a kitalált időzítőnkhöz. Ezek ellenőrizendő kritériumok, nem már sikeres tesztek: | Tervezési döntés | Mit tesztelj | Elvárt eredmény | | ------------------------------------------------ | ------------------------------------------------------------------ | --------------------------------------------------------- | | Az alap blokk fiók nélkül elérhető | Telepítsd az appot, és indíts egy blokkot regisztráció nélkül | Semmilyen regisztrációs űrlap nem akadályozza az indítást | | A félbehagyott blokk nem számít bele a sorozatba | Állíts le egy blokkot a vége előtt, majd nyisd meg az előzményeket | Nem kerül be új befejezett blokk | | Az előzmények a készüléken maradnak | Fejezz be egy blokkot, zárd be, majd nyisd meg újra az appot | A blokk egyszer jelenik meg, a helyes időtartammal | | Az alap időzítő hálózat nélkül is működik | Kapcsold be a repülőgép módot, és fejezz be egy blokkot | Az időzítő és a helyi mentés használható marad | | A részletes statisztikák fizetősek | Nyisd meg a statisztikákat előfizetés nélkül | Megjelenik az ajánlat; az alap blokk továbbra is elérhető | A még homályos témákból meghozandó döntések lesznek. Például: mi történjen, ha a felhasználó blokk közben lezárja a képernyőt vagy átállítja a telefon óráját? Ne hagyd, hogy az ágens csendben döntsön. Írd le a kívánt viselkedést, aztán vedd fel az esetet a táblázatba. Ahhoz, hogy ezt az átvételi tesztet egy valódi telepítésen szervezd meg, használd az [iPhone app tesztelése TestFlighttal](https://devoria.fr/hu/blog/testflight-iphone-app-tesztelese) útmutatót. ### Mit vegyél ki, ha az első verzió túlnő? Vedd sorra a funkciókat, és tedd fel a kérdést: „Nélküle is megkapja a felhasználó a megígért eredményt?” Az időzítőnknél a barátok közötti rangsor várhat. Egy befejezett blokk visszakeresése viszont szükséges, ha napi sorozatot ígérsz. Egy előfizetési képernyő csak akkor válik szükségessé, ha már ebben a verzióban ténylegesen árulod a statisztikákat. Jegyezd fel a döntést és az okát a [letölthető sablon naplójában](https://devoria.fr/ressources/cahier-des-charges-app-ios.md). Tesztek után visszatérhetsz erre a döntésre anélkül, hogy elveszítenéd, miért ilyen lett az eredeti terjedelem. Az [alkalmazás készítése Claude Code-dal](https://devoria.fr/hu/blog/alkalmazas-keszitese-claude-code-iphone-utmutato) útmutató ezután megmutatja, hogyan alakítsd ezt a tervet szűk, ellenőrizhető kérésekké. Egy gyakorlati tapasztalatért: [a TradaZen a megjelenése után módosította a terjedelmét](https://devoria.fr/hu/blog/tradazen-esettanulmany-iphone-app-inditasa). A tervezés arra való, hogy kiadj egy mérhető első verziót, aztán valódi visszajelzések alapján dönts a következőről. ## A funkciókatalógus csapdája A természetes reflex az, hogy felsorolod mindazt, amit az appnak „tudnia kell”: térkép, chat, értesítések, ajánlói program, offline mód. Ez a katalógus a legmegbízhatóbb jele egy olyan projektnek, ami sosem készül el, egy egyszerű okból: minden, a megjelenés előtt hozzáadott funkció késlelteti azt a pillanatot, amikor valódi felhasználók megmondják neked, mi számít. Egy jó első verzió egy dolgot csinál, és azt jól. Vigyázz azért a másik végletre is: az Apple elvárja, hogy egy app többet nyújtson egy becsomagolt weboldalnál, [az App Review Guidelines 4.2-es szabálya](https://developer.apple.com/app-store/review/guidelines/) szerint. Egyetlen fő funkció: igen; üres héj: nem. Ez a [4.2-es guideline](https://devoria.fr/hu/blog/guideline-4-2-minimum-functionality-elutasitott-app) szerinti elutasítási ok. ## Mi ne kerüljön egy mobilapp specifikációjába? - **Teljes arculati kézikönyv.** Kezdetben elég néhány referencia-képernyőkép. - **Napra lebontott ütemterv.** Még nincs meg hozzá az információd, hogy tartsd. Elég egy heti cél. - **Részletes technikai architektúra.** Válassz egy bevált stacket, a részletek pedig dőljenek el építés közben. - **„Későbbre” szánt funkciók a többi közé keverve.** Ezek mind a „kimarad az 1. verzióból” részbe kerülnek. ## Mikor frissítsd a specifikációdat? Olvasd át minden munkahét elején. Csak akkor frissítsd, ha egy döntés valódi okból változik: egy teszt az iPhone-odon, ami megmutatja, hogy egy képernyő nem működik, egy tesztelői visszajelzés, egy útközben felfedezett Apple-korlát. Ha minden nap módosítod, akkor már semmit sem keretez. Az első verzió megjelenése után az oldal a következő verzió alapja lesz: ami kimaradt az 1. verzióból, előrébb kerül, aszerint rendezve, amit a számok mondanak. Az ötlettől a megjelenésig tartó út áttekintése a [iPhone app készítése](https://devoria.fr/hu/expertise/iphone-alkalmazas-keszitese) oldalon található. ## Az oldaltól a megjelent appig Ha megválaszoltad a tíz kérdést, már elvégezted azt a munkát, amit sok projekt kihagy. A folytatás: megépíteni a fő funkciót, tesztelni az iPhone-odon, bekötni az előfizetéseket és előkészíteni az anyagot az Apple-nek. Ez az [iOS Kit](https://devoria.fr/hu/kits/ios) útja, négy lépésben, a saját tempódban: az első arra való, hogy kiválaszd a pénzt hozó appot, a közönségét és az árát, és ennek a kiindulópontja a te specifikációd. Nem tudod, hogy az ötleted elfér-e már egy oldalon? Az [ingyenes diagnózis](https://devoria.fr/hu/diagnostic) megmondja, mi akasztja meg ma a projektedet, és melyik lépéssel kezdj. A kezdőlap aztán megmutatja, hogyan [készíts mobilappot](https://devoria.fr/hu) ebből a tervből, Claude Code-dal. Nem ígérek se bevételt, se megjelenést: az Apple dönt a jóváhagyásról, a többiről pedig a piac. A kit nélkül is elég ez a sablon az induláshoz. ## Gyakori kérdések ### Hogyan írj specifikációt egy mobilalkalmazáshoz? Tartsd egy oldalon a specifikációdat: tíz kérdés, válaszonként egy-két mondat. A kérdések a közönségről, a problémáról, a fő funkcióról, az üzleti modellről, a fiók nélküli használatról, a megőrzendő adatokról, a platformról, az első verzióból kimaradó dolgokról, a siker jeléről és a korlátokról szólnak. Ha egy válasz két mondatnál hosszabb, az gyakran azt jelenti, hogy a döntés még nem született meg. ### Milyen programban írd meg az app specifikációját? Egy egyszerű jegyzetben vagy egy szövegfájlban a projekted gyökerében: bemásolod a sablont, aztán kitöltöd minden sorát. A [vázlatot és az ellenőrző táblázatát (.md) le is töltheted](https://devoria.fr/ressources/cahier-des-charges-app-ios.md), regisztráció nélkül. Ha AI-t irányítasz vele, utána tedd be a projekted kontextusfájljába. ### Kell egy 40 oldalas specifikáció egy apphoz? Nem, ha a saját appodat készíted: elég egy oldal. A neten található 40 oldalas sablonok annak az ügyfélnek szólnak, aki egy fejlesztőtől rendel appot, és szerződéses dokumentumra van szüksége. Te döntesz és építesz: az oldalad arra való, hogy kódolás előtt meghozd a döntéseket, és kontextust adj az AI-nak. ### Hogyan add át a specifikációt egy kódoló AI-nak? Tedd az oldalt a projekt állandó kontextusába: a Claude Code beolvas egy `CLAUDE.md` fájlt a gyökérből, a Cursornak saját szabályfájljai vannak. Hivatkozz a „kimarad az 1. verzióból” részre, amikor az AI túlzásba esik. Egy nagyobb munka előtt kérj olyan tervet, ami tiszteletben tartja az oldalt, egyelőre kódolás nélkül. ### Hogyan ellenőrizd, hogy egy funkció megfelel-e a specifikációnak? Minden funkcióhoz írj három sort: a műveletet, az elvárt eredményt és a bizonyítékot. A bizonyíték lehet automatizált teszt egy számításnál, vagy ellenőrzés a készüléken egy folyamatnál. Azt is jegyezd fel, mit nem teszteltél, hogy ne keverd össze a kész képernyőt a használatra kész funkcióval. ### Mit ne írj bele egy app specifikációjába? Négy dolgot kerülj: teljes arculati kézikönyvet, napra lebontott ütemtervet, részletes technikai architektúrát, és a többi közé kevert „későbbre” szánt funkciókat. Kezdetben elég néhány referencia-képernyőkép, az ütemezéshez pedig egy heti cél. A későbbre szánt funkciók mind a „kimarad az 1. verzióból” részbe kerülnek. ## A projekted [iOS Kit](https://devoria.fr/hu/kits/ios): Készítsd el az iPhone-appodat Claude Code-dal: az appjaim kiinduló kódja, a munkáját ellenőrző skillek, valamint az Apple Review Kit, az App Store Screenshots Kit és az ASO Kit. 129,99 €.