Specyfikacja aplikacji mobilnej: szablon na jedną stronę

Specyfikacja aplikacji mobilnej: krótka odpowiedź

Dobra specyfikacja aplikacji mobilnej, kiedy tworzysz własną aplikację, mieści się na jednej stronie. Odpowiada na dziesięć pytań: dla kogo, jaki problem, jaka główna funkcja, jak aplikacja zarabia, co dzieje się bez konta, jakie dane muszą przetrwać, na jakiej platformie, co jest poza pierwszą wersją, po czym poznasz, że to działa, i jakie masz ograniczenia. Szablon do skopiowania znajdziesz niżej. Możesz też pobrać szablon z listą kontrolną (.md), bez rejestracji.

Czterdziestostronicowe szablony, które znajdziesz w sieci, powstały do innego celu: dla klienta, który zamawia aplikację u wykonawcy i potrzebuje dokumentu do umowy. Ty jesteś jednocześnie tym, kto decyduje, i tym, kto buduje, często z pomocą AI. Twoja specyfikacja służy do dwóch rzeczy: podjęcia decyzji przed kodowaniem i dania Claude, ChatGPT czy Cursorowi jasnego kontekstu, żeby zbudowały właściwą aplikację.

Publikuję własne aplikacje iOS. Solys, budzik z minigrami, i TradaZen, symulator tradingu, są w App Store. Nolera i Clic zostały odrzucone przez Apple, a potem poprawione. To metoda, którą stosuję przy każdej z nich, i tę samą proponuję tobie.

Dlaczego jedna strona wystarczy, żeby uporządkować własną aplikację

Długi dokument daje wrażenie postępu. W praktyce piszesz go raz, rzadko do niego wracasz, a projekt odjeżdża od niego już w pierwszych tygodniach. Jedną stronę za to przeczytasz w dwie minuty przed każdą sesją pracy.

Ograniczone miejsce ma też przydatny efekt: zmusza cię do decyzji. Jeśli odpowiedź przekracza dwa zdania, często znaczy to, że decyzja nie zapadła. Lepiej odkryć to na kartce niż w kodzie trzy tygodnie później.

Wreszcie jedna strona to dobry rozmiar dla AI. Możesz wkleić ją w całości do rozmowy albo umieścić w pliku kontekstu projektu. Krótki dokument łatwiej przejrzeć i ma mniej sprzecznych instrukcji. Nie gwarantuje, że AI ich przestrzega: sprawdzaj jej propozycje względem tych ram.

Co powinna zawierać specyfikacja aplikacji mobilnej?

Odpowiedz na każde z tych pytań w jednym lub dwóch zdaniach.

1. Kto używa aplikacji i w jakiej sytuacji? Nie „osoby w wieku 18-35 lat”. Raczej konkretna osoba w konkretnym momencie dnia.
2. Jaki problem rozwiązuje aplikacja, w jednym zdaniu? Jeśli potrzebujesz „a do tego”, opisujesz dwie aplikacje.
3. Jaka jest TA główna funkcja pierwszej wersji? Tylko jedna. Reszta poczeka na liczby. Strona MVP aplikacji iOS wyjaśnia, jak wybrać.
4. Jak aplikacja zarabia? Subskrypcja, jednorazowy zakup albo za darmo. Ta odpowiedź zmienia aplikację od pierwszego ekranu. Jeśli się wahasz, przeczytaj subskrypcja czy jednorazowy zakup w aplikacji iOS.
5. Co można zrobić bez zakładania konta? Wczesna decyzja o tym, co jest dostępne bez rejestracji, oszczędza ci przebudowy całego onboardingu.
6. Jakie dane muszą przetrwać zmianę telefonu? To pytanie rozstrzyga, czy potrzebujesz backendu takiego jak Supabase, czy wszystko może zostać na urządzeniu.
7. Tylko iOS czy iOS i Android? Moja rada na start: najpierw iOS. Wyjaśniam dlaczego w aplikacja na iOS i Androida jednocześnie.
8. Co jest wprost POZA pierwszą wersją? Najbardziej przydatna sekcja dokumentu. Ucina dyskusje, zanim się zaczną, zarówno z samym sobą, jak i z AI.
9. Po czym poznasz, że to działa? Jeden sygnał, mierzalny w tygodniach po premierze: rozpoczęte darmowe okresy próbne, subskrybenci, powracający użytkownicy.
10. Jakie są twoje realne ograniczenia? Czas, jaki możesz poświęcić co tydzień, twój sprzęt i konto Apple Developer, które kosztuje 99 $ rocznie. Nie masz Maca? To nie przeszkoda, co wyjaśniam w publikacja aplikacji iOS bez Maca.

Szablon specyfikacji do skopiowania

Skopiuj ten szablon do notatki albo pliku tekstowego w katalogu głównym projektu, a potem zastąp każdą linię.

• Robocza nazwa aplikacji: …
• Dla kogo: osoba, która … w momencie, gdy …
• Rozwiązywany problem, w jednym zdaniu: …
• Główna funkcja wersji 1: …
• Co użytkownik widzi przy pierwszym otwarciu aplikacji: …
• Model biznesowy: subskrypcja / jednorazowy zakup / za darmo, i co jest płatne: …
• Bez konta można: …
• Dane do zachowania między telefonami: żadne / …
• Platforma: najpierw iOS (Android później, jeśli liczby na to pozwolą)
• Poza wersją 1: …, …, …
• Sygnał sukcesu: …
• Stack: React Native, Expo, Supabase, jeśli potrzebne są konta, RevenueCat do subskrypcji
• Ograniczenia: … godzin tygodniowo, konto Apple Developer założone czy nie, Mac czy nie
• Aplikacje, których doświadczenie lubię, i dlaczego: …

Dodaj trzy do pięciu zrzutów ekranu aplikacji, które lubisz, z krótkim słowem o tym, co ci się podoba. To mówi więcej niż księga znaku, zarówno tobie, jak i AI.

Specyfikacja to nie lista życzeń. To lista podjętych decyzji.

Przykład: wypełniona strona dla fikcyjnej aplikacji

Żeby pokazać oczekiwany poziom szczegółów, oto szablon wypełniony dla aplikacji wymyślonej na potrzeby przykładu: minutnika do nauki.

• Dla kogo: student, który uczy się sam wieczorami i odpływa po dziesięciu minutach.
• Problem: nie potrafi wytrwać sesji nauki bez sięgania po telefon.
• Główna funkcja: uruchomić sesję z odliczaniem i zobaczyć swoją serię dni.
• Pierwszy ekran: jeden przycisk do rozpoczęcia sesji.
• Model biznesowy: subskrypcja za szczegółowe statystyki, podstawowa sesja za darmo.
• Bez konta: wszystko, poza kopią zapasową między telefonami.
• Poza wersją 1: tryb grupowy, ranking ze znajomymi, widżety, wersja na Androida.
• Sygnał sukcesu: użytkownicy, którzy wracają kilka dni z rzędu.

Zwróć uwagę, czego celowo brakuje: żadnej listy dwudziestu ekranów, żadnych narzuconych kolorów, żadnej architektury. Te wybory przyjdą w trakcie budowy, a strona pozwala ci sprawdzić, czy nadal służą głównej funkcji.

Jak używać specyfikacji, żeby prowadzić AI

Tu twoja strona daje najwięcej. AI, która koduje bez kontekstu, zgaduje, i często zgaduje inną aplikację niż twoja.

Umieść stronę w stałym kontekście projektu. Claude Code czyta plik CLAUDE.md w katalogu głównym, Cursor ma własne pliki reguł. Wklej tam specyfikację razem ze stackiem. Każde polecenie startuje wtedy z tej samej bazy.

Cytuj sekcję „poza wersją 1”, gdy AI robi za dużo. Asystenci chętnie proponują dodatkowe funkcje: tryb ciemny, udostępnianie, powiadomienie. Twoja lista wykluczeń daje gotową odpowiedź: nie teraz.

Poproś o plan zgodny ze stroną. Przed większym zadaniem napisz: „oto moja specyfikacja, zaproponuj plan dla głównej funkcji, jeszcze nie koduj”. Od razu zauważysz, czy plan odbiega od tego, co postanowiłeś.

Niech przeczyta stronę, nie tylko kod. Zapytaj: „które pytania w tej specyfikacji są niejasne albo sprzeczne?”. To niedoceniane zastosowanie AI, które oszczędza ci tygodni pracy w złym kierunku.

Jeśli chcesz pójść dalej, opisałem pułapki i sposoby weryfikacji w tworzenie aplikacji iOS z AI.

Zamiana decyzji w kryteria akceptacji

Główna funkcja musi mieć obserwowalny rezultat. Dla fikcyjnego minutnika z tego przykładu „minutnik działa” to za mało. Napisz raczej: „Uruchamiam sesję, wyświetla się pozostały czas, mogę ją zatrzymać i po ponownym otwarciu aplikacji odnaleźć ostatnią ukończoną sesję”. Osobno zdecyduj, czy minutnik ma działać przy zablokowanym ekranie: ten wybór może zmienić pracę techniczną.

Dla każdej funkcji dodaj trzy linie: akcja, oczekiwany rezultat, dowód. Dowodem może być test automatyczny dla obliczeń albo sprawdzenie na urządzeniu dla ścieżki użytkownika. Zapisz też, czego nie przetestowano. Ta mała tabela chroni przed myleniem gotowego ekranu z funkcją gotową do użycia.

Oto tabela wypełniona dla naszego fikcyjnego minutnika. To kryteria do sprawdzenia, a nie testy, które już przeszły:

Decyzja ze specyfikacji	Do przetestowania	Oczekiwany rezultat
Podstawowa sesja jest dostępna bez konta	Zainstalować aplikację i uruchomić sesję bez rejestracji	Żaden formularz rejestracji nie blokuje startu
Przerwana sesja nie liczy się do serii	Zatrzymać sesję przed końcem, potem otworzyć historię	Nie dodano żadnej ukończonej sesji
Historia zostaje na urządzeniu	Ukończyć sesję, zamknąć i ponownie otworzyć aplikację	Sesja pojawia się tylko raz, z poprawnym czasem trwania
Podstawowy minutnik działa bez sieci	Włączyć tryb samolotowy i ukończyć sesję	Minutnik i lokalny zapis nadal działają
Szczegółowe statystyki są płatne	Otworzyć statystyki bez subskrypcji	Wyświetla się oferta; podstawowa sesja pozostaje dostępna

Tematy, które wciąż są niejasne, stają się decyzjami do podjęcia. Na przykład: co zrobić, jeśli użytkownik zablokuje ekran albo zmieni godzinę w telefonie w trakcie sesji? Nie pozwól agentowi wybrać po cichu. Zapisz oczekiwane zachowanie, a potem dodaj przypadek do tabeli. Żeby zorganizować te testy na prawdziwej instalacji, skorzystaj z poradnika testowanie aplikacji na iPhone'a z TestFlight.

Co wyciąć, gdy pierwsza wersja się rozrasta

Weź każdą funkcję i zadaj pytanie: „Czy bez niej użytkownik nadal osiągnie obiecany rezultat?”. W naszym minutniku ranking ze znajomymi może poczekać. Odnalezienie ukończonej sesji jest konieczne, jeśli obiecujesz serię dni. Ekran subskrypcji staje się konieczny tylko wtedy, gdy faktycznie sprzedajesz statystyki już w tej wersji.

Zapisz decyzję i jej powód w dzienniku szablonu do pobrania. Po testach możesz wrócić do tego wyboru, nie tracąc uzasadnienia pierwotnego zakresu. Tutorial tworzenie aplikacji z Claude Code pokazuje potem, jak zamienić te ramy w ograniczone i weryfikowalne polecenia.

Jeśli chcesz przykład z praktyki, TradaZen zmienił zakres po publikacji. Specyfikacja służy do wydania mierzalnej pierwszej wersji, a potem do decydowania o następnej na podstawie prawdziwych opinii.

Pułapka katalogu funkcji

Naturalny odruch to wypisać wszystko, co aplikacja „będzie musiała robić”: mapa, czat, powiadomienia, polecenia znajomych, tryb offline. Taki katalog to najpewniejszy znak projektu, który nie dojdzie do końca, z prostego powodu: każda funkcja dodana przed premierą opóźnia moment, w którym prawdziwi użytkownicy powiedzą ci, co się liczy.

Dobra pierwsza wersja robi jedną rzecz i robi ją dobrze. Uważaj jednak na przesadę w drugą stronę: Apple wymaga, żeby aplikacja była czymś więcej niż opakowaną stroną internetową, zgodnie z zasadą 4.2 App Review Guidelines. Jedna główna funkcja, tak; pusta skorupa, nie: to powód odrzucenia z guideline 4.2.

Czego nie powinna zawierać specyfikacja aplikacji mobilnej

• Pełnej księgi znaku. Na start wystarczy kilka zrzutów ekranu jako punkt odniesienia.
• Harmonogramu dzień po dniu. Nie masz jeszcze informacji, żeby go dotrzymać. Wystarczy cel na tydzień.
• Szczegółowej architektury technicznej. Wybierz sprawdzony stack, a szczegóły niech rozstrzygną się w trakcie budowy.
• Funkcji „na później” wymieszanych z resztą. Wszystkie trafiają do sekcji poza wersją 1.

Kiedy aktualizować specyfikację?

Czytaj ją na początku każdego tygodnia pracy. Aktualizuj tylko wtedy, gdy decyzja zmienia się z prawdziwego powodu: test na iPhonie pokazuje, że ekran nie działa, opinia testera, ograniczenie Apple odkryte po drodze. Jeśli zmieniasz ją codziennie, to znaczy, że niczego już nie porządkuje.

Po publikacji pierwszej wersji strona staje się bazą dla następnej: to, co było poza wersją 1, wraca, posortowane według tego, co mówią liczby. Ogólny obraz całej drogi, od pomysłu do publikacji, znajdziesz na stronie tworzenie aplikacji na iPhone'a.

Od strony do opublikowanej aplikacji

Jeśli odpowiedziałeś na dziesięć pytań, wykonałeś już pracę, którą wiele projektów pomija. Dalej trzeba zbudować główną funkcję, przetestować ją na iPhonie, podpiąć subskrypcje i przygotować materiały dla Apple.

To droga, którą prowadzi iOS Kit, w czterech etapach we własnym tempie: pierwszy służy do wyboru aplikacji, która może zarabiać, jej odbiorców i ceny, a twoja specyfikacja jest punktem wyjścia.

Nie wiesz, czy twój pomysł zmieści się na jednej stronie? Darmowa diagnoza powie ci, co dziś blokuje twój projekt i od którego etapu zacząć. Strona główna pokazuje potem, jak stworzyć aplikację mobilną na podstawie tych ram, z Claude Code.

Nie obiecuję ci ani przychodu, ani publikacji: to Apple zatwierdza, a o reszcie decyduje rynek. Bez kitu ten szablon wystarczy ci na start.

Najczęściej zadawane pytania

Jak napisać specyfikację aplikacji mobilnej?

Zmieść specyfikację na jednej stronie: dziesięć pytań, jedno lub dwa zdania na odpowiedź. Dotyczą odbiorców, problemu, głównej funkcji, modelu biznesowego, tego, co dzieje się bez konta, danych, które muszą przetrwać, platformy, tego, co jest poza pierwszą wersją, sygnału sukcesu i ograniczeń. Jeśli odpowiedź przekracza dwa zdania, często znaczy to, że decyzja nie zapadła.

Jakiego programu użyć do napisania specyfikacji aplikacji?

Zwykłej notatki albo pliku tekstowego w katalogu głównym projektu: kopiujesz tam szablon i zastępujesz każdą linię. Możesz też pobrać szablon z listą kontrolną (.md), bez rejestracji. Żeby prowadzić AI, umieść go potem w pliku kontekstu projektu.

Czy aplikacja potrzebuje 40-stronicowej specyfikacji?

Nie, kiedy tworzysz własną aplikację: wystarczy jedna strona. Czterdziestostronicowe szablony z sieci są pisane dla klienta, który zamawia aplikację u wykonawcy i potrzebuje dokumentu do umowy. Ty decydujesz i budujesz: twoja strona służy do podjęcia decyzji przed kodowaniem i do dania kontekstu AI.

Jak przekazać specyfikację AI, która koduje?

Umieść stronę w stałym kontekście projektu: Claude Code czyta plik CLAUDE.md w katalogu głównym, Cursor ma własne pliki reguł. Cytuj sekcję „poza wersją 1”, gdy AI robi za dużo. Przed większym zadaniem poproś o plan zgodny ze stroną, bez kodowania od razu.

Jak sprawdzić, czy funkcja jest zgodna ze specyfikacją?

Dla każdej funkcji dodaj trzy linie: akcję, oczekiwany rezultat i dowód. Dowodem może być test automatyczny dla obliczeń albo sprawdzenie na urządzeniu dla ścieżki użytkownika. Zapisz też, czego nie przetestowano, żeby nie mylić gotowego ekranu z funkcją gotową do użycia.

Czego nie umieszczać w specyfikacji aplikacji?

Cztery rzeczy, których unikać: pełnej księgi znaku, harmonogramu dzień po dniu, szczegółowej architektury technicznej i funkcji „na później” wymieszanych z resztą. Na start wystarczy kilka zrzutów ekranu jako punkt odniesienia, a w harmonogramie wystarczy cel na tydzień. Funkcje na później trafiają do sekcji poza wersją 1.