O czym jest ten film
- Najbardziej przydatna aplikacja na twoim telefonie może być taka, której żadna firma nigdy by nie zbudowała — bo ma tylko jednego użytkownika: ciebie.
- Autor odtwarza w formie natywnej apki swój papierowy rytuał: co wieczór zapisuje jedno główne zadanie na jutro i zadanie awaryjne na wypadek złego dnia.
- Cała apka („One Move”) powstaje w dwie godziny, w siedmiu promptach, bez napisania ani jednej linijki Swifta.
- Do budowy i testowania służy Codex; kod jest generowany, uruchamiany na symulatorze i weryfikowany krok po kroku.
- Autor świadomie pomija backend, hosting, TestFlight oraz proces zatwierdzania w App Store — aplikacja i dane zostają wyłącznie na telefonie.
- Kluczowa zasada logiki: zadania są „tylko do odczytu” w ciągu dnia — decyzję podejmujesz wieczorem i musisz z nią żyć następnego dnia.
- Instalacja na fizycznym iPhonie wymaga podpisanego builda deweloperskiego, konta Apple i włączonego Trybu Deweloperskiego.
- Po drodze pojawia się typowy błąd („Signing requires a development team”) — autor pokazuje, jak go naprawić.
- Ikonę wygenerowano osobno w ChatGPT; poprawa wyglądu apki nie jest tu celem, liczy się działający proof of concept.
- Główny przekaz: budowanie natywnego oprogramowania stało się na tyle szybkie i tanie, że opłaca się je robić dla „bazy użytkowników liczącej jedną osobę”.
Redakcyjne tłumaczenie
Aplikacja dla jednej osoby
Najbardziej przydatna aplikacja na twoim telefonie może być taka, której żadna firma nigdy by nie zbudowała. U mnie przybiera to formę rytuału. Każdego wieczoru zapisuję jeden priorytet na jutro oraz zadanie awaryjne na wypadek, gdyby dzień poszedł nie tak. To papierowy rytuał zbudowany wokół moich własnych zasad i przydatny tylko jednej osobie — mnie.
Jeszcze niedawno coś takiego było zbyt drobne, żeby uzasadniać zrobienie z tego aplikacji. Dziś AI sprawia, że budowanie natywnego oprogramowania jest na tyle łatwe, szybkie i tanie, że opłaca się je robić dla widowni złożonej z jednej osoby.
Dziś wieczorem zaczynam od pustego projektu w Xcode. Do budowy i testowania użyję Codeksa, a potem wgram apkę na telefon. Pomijam backend, hosting, TestFlight oraz cały proces zatwierdzania i publikacji w App Store. Aplikacja i jej dane zostaną na moim telefonie. Jutro wezmę ją ze sobą i sprawdzę, czy rzeczywiście z niej korzystam.
(Informacja dodatkowa: Codex to narzędzie do generowania i uruchamiania kodu przez AI; Xcode to oficjalne środowisko programistyczne Apple do tworzenia aplikacji na iPhone’a. TestFlight to usługa Apple do dystrybucji testowych wersji aplikacji.)
Papierowy system, który apka ma odwzorować
Zacząłem od pustego folderu i standardowego szablonu Xcode. Nie zrobiłem nic więcej i teraz przekazuję projekt Codeksowi. Zanim Codex cokolwiek zmieni, chcę, żeby najpierw przejrzał cały projekt.
Wróćmy do mojego systemu papierowych kartek. Każda kartka ma dwa pola. Na górze wpisuję główny ruch — najważniejszą rzecz do zrobienia jutro — a pod spodem zadanie awaryjne na wypadek, gdyby dzień poszedł źle. Jeśli wykonam tę główną rzecz, stawiam „X” w polu. Jeśli dzień jest ciężki, stawiam „X” w małym polu — i to cały system.
Kiedy tworzysz oprogramowanie dla wielu osób, musisz uwzględnić więcej przypadków użycia, więcej sytuacji i wspierać to przez dłuższy czas. Tutaj mam jednego użytkownika i jedno zadanie do przemyślenia, więc mogę utrzymać apkę małą i poświęcić na nią jeden wieczór.
Ludzie od zawsze robili sobie drobne narzędzia — w arkuszach kalkulacyjnych, w Skrótach, w Notion, jako aplikacje webowe. AI sprawia, że mogę zrobić to samo w prosty i praktyczny sposób jako natywną apkę i wgrać ją na telefon.
Przy okazji: papierowy system też sprawdza się świetnie. To zaskakująco spory stos — sto kartek. Trzy takie stosy to prawie rok. Aplikacja „One Move” ma pięć zasad i tyle. Wieczorem zapisuję główny ruch na jutro i mniejsze zadanie awaryjne, a następnego dnia oba pojawiają się na jednym ekranie. Mogę wykonać jedno z nich albo zostawić oba, ale nie mogę zmienić treści, gdy dzień już się zaczął. Jedno stuknięcie zamyka dzień i nie da się tego cofnąć. Nie ma serii ani historii. Wszystko przechowywane jest na telefonie.
Ta niezmienność jest dla mnie ważna. Decyzję podejmuję poprzedniego wieczoru i żyję z nią następnego dnia. Gdybym mógł ją edytować rano, cały rytuał by się rozpadł — wymigałbym się od najważniejszej rzeczy do zrobienia.
Budowa krok po kroku w Codeksie
To był cały brief. Codex już sprawdził projekt, więc wklejam mu ten opis. To pierwsza część aplikacji — zobaczmy, jak sobie poradzi.
Pierwsza część gotowa. To główny ekran. Na dziś nic nie zadeklarowano, bo wczoraj nie ustawiłem celu. Możemy ustawić cel na jutro — główny i awaryjny. „Zmontuj wideo”. „Zmontuj pierwsze pięć minut”. Ta część działa: dodawanie nowych celów na jutro i wyświetlanie celów na dziś. Teraz zajmijmy się częścią odpowiedzialną za oznaczanie zadań jako wykonanych.
Oznaczanie prawdopodobnie już działa. Aplikacja jest w stanie, w którym jedno z przykładowych zadań na dziś jest już zakończone — a jedną z zasad było to, że nie da się tego cofnąć. Poprośmy więc Codeksa, żeby uruchomił apkę w stanie, w którym dzisiejsze zadania nie są jeszcze wykonane, i sprawdźmy, czy oznaczanie działa.
Gotowe. Teraz są dwa zadania i mogę wykonać dowolne z nich. Wykonajmy to główne. Gotowe — działa. Sprawdźmy, czy stan się utrzymuje. Zamykamy apkę, otwieramy ponownie. Wszystko działa poprawnie.
Teraz dodaję kolejne zasady, żeby dopracować logikę systemu pod moje potrzeby. Skoro funkcjonalność i logika są na miejscu, czas trochę to upiększyć. Kilka drobnych zmian — wygląda już nieco lepiej. Nie podoba mi się to duże „X” tutaj i małe „x” tam, ale dopracowanie wyglądu nie jest tu celem, więc idę dalej i wykonuję ostatni krok: dodanie ikony. Ikonę też można wygenerować w Codeksie, ale użyłem webowej wersji ChatGPT do obrazów — wpisałem prosty prompt i już za pierwszym razem dostałem coś, co do tego celu w zupełności wystarcza.
Z symulatora na prawdziwy telefon
Ikona jest podpięta, aplikacja jest, funkcjonalność działa. Ale to, co pokazuję, to wciąż symulator. Czas wgrać apkę na mój prawdziwy telefon.
Zanim będę mógł to zrobić, iPhone potrzebuje podpisanego builda deweloperskiego. Wracam więc do Xcode — i tak naprawdę to pierwszy raz, gdy w ogóle widzę edytor Xcode od początku tej sesji, bo nie napisałem ani jednej linijki Swifta. Wybieram tu mój faktyczny telefon podłączony do komputera. Mam już konto Apple Developer, bo publikowałem wcześniej aplikację w App Store. Jeśli ty też je masz, to świetnie, ale wystarczy również darmowe konto Apple. Xcode mimo wszystko korzysta z systemu deweloperskiego Apple do instalacji apki, nawet jeśli jej nie publikujemy — dlatego te kroki są konieczne.
Żeby to zadziałało, telefon musi też być w Trybie Deweloperskim. Jeśli wejdziesz w Ustawienia i przewiniesz na sam dół, a zobaczysz pozycję „Developer”, to Tryb Deweloperski jest włączony. Jeśli go nie widzisz, wejdź w Prywatność i bezpieczeństwo, przewiń w dół i w sekcji bezpieczeństwa znajdziesz Tryb Deweloperski. Trzeba go włączyć, zrestartować telefon, potwierdzić kodem — i Tryb Deweloperski jest aktywny.
(Informacja dodatkowa: Tryb Deweloperski to specjalne ustawienie iPhone’a pozwalające instalować aplikacje spoza App Store; domyślnie jest wyłączone.)
Czas wgrać apkę. Przełączam się na Xcode, upewniam się, że wybrany jest mój fizyczny telefon, i naciskam Command-R. I mamy błąd: „build failed”. Sprawdźmy dlaczego. „Signing requires a development team” — podpisywanie wymaga zespołu deweloperskiego. To jeden z typowych błędów i chciałem go pokazać, żebyś wiedział, co zrobić, gdy go zobaczysz. Mam konto deweloperskie, więc wybieram je tutaj. Zespół jest wybrany, mogę ponownie zbudować projekt przez Command-R. Tym razem build się powiódł. Aplikacja podłącza się do „One Move” na moim telefonie — i już tam jest, tu i teraz.
To, co widzę na ekranie, to już nie jest wersja testowa ani sesja debugowania, więc nie ma zadań testowych na dziś, bo wczoraj ich nie ustawiłem. Ale mogę ustawić zadania na jutro: „Zmontuj wideo”, „Zmontuj pierwszą część”, zapisz na jutro — i tyle. Apka jest na telefonie. Jutro zobaczę te zadania, będę mógł je odhaczyć jako wykonane i ustawić zadania na kolejny dzień — dokładnie odwzorowując funkcję moich papierowych kartek.
Podsumowanie i przesłanie
Zacząłem od pustego folderu i pustego repozytorium. Teraz cały kod jest gotowy i — siedem promptów później — aplikacja jest na moim telefonie. To cała budowa.
Żeby spróbować tego samemu, potrzebujesz konta Apple. Xcode używa go do podpisania i zainstalowania apki. Nie potrzebujesz TestFlight ani publikacji w App Store. Ja korzystam z płatnego zespołu deweloperskiego z czasów, gdy wydawałem aplikacje, ale darmowy zespół osobisty (Personal Team) też wystarczy.
(Informacja dodatkowa — korekta autora: darmowy Personal Team obsługuje do 10 identyfikatorów aplikacji i trzy urządzenia testowe na platformę, a te rejestracje i profile wygasają po siedmiu dniach.)
Moja apka „One Move” przechowuje wszystko lokalnie. Nie ma serwera ani konta do zarządzania. Telefon nadal musi mieć włączony Tryb Deweloperski, a build musi pozostać podpisany. To jedyne wymagania.
Czy przestanę używać papierowych kartek? Raczej nie. Lubię je pisać. Lubię widzieć ten stos na biurku. Lubię, że są namacalne. Apka przyda się bardziej wtedy, gdy nie mam kartki przy sobie, ale przede wszystkim jest dowodem koncepcji — pokazuje, jak szybko i łatwo można napisać dowolną aplikację. To był tylko prosty przykład.
Apple od lat pozwala na instalacje deweloperskie, ale ja nie znam Swifta, a poprzednie aplikacje pisałem w Expo, żeby uruchamiać je jednocześnie na iOS i Androidzie. Nigdy nie pisałem w Swifcie, więc nie mogłem wgrać apki jako builda deweloperskiego na telefon. Teraz AI skróciło ten czas i nakład pracy na tyle, że opłaca mi się zrobić to wyłącznie dla siebie — po piętnastu minutach czy pół godzinie pracy nad apką. Działa natywnie na moim telefonie i to wszystko, czego od niej potrzebowałem.
(Informacja dodatkowa: Expo to framework do budowy aplikacji mobilnych działających na iOS i Androidzie ze wspólnego kodu; to inne podejście niż natywny kod w Swifcie.)
Kod i prompty są publiczne. Możesz je przejrzeć — zwłaszcza prompty, jeśli szukasz inspiracji, jak je formułować. Gdybym chciał udostępnić tę apkę innym, zmieniłaby się w duży projekt: potrzebowałbym kont, synchronizacji, serwera na dane, musiałbym dbać o bezpieczeństwo i wszystko to utrzymywać. Wolę trzymać całość na telefonie i nie martwić się serwerami, utrzymaniem ani bezpieczeństwem.
Mierzyłem czas. Nagrana sesja zajęła mi dwie godziny. Wcześniej poświęciłem godzinę na przygotowanie i nie robiłem nawet próby generalnej — chciałem zrobić to na żywo, za pierwszym razem, żeby przy okazji pokazać ewentualne błędy i sposób ich naprawy. Użyłem siedmiu promptów: dwa służyły tylko utwardzeniu logiki, jeden stworzeniu ikony. Chciałem pokazać krok po kroku, zamiast wrzucać jeden ogromny prompt — co też byłoby możliwe. Podczas budowy potrzebna była jedna ręczna interwencja: wybór konta deweloperskiego Apple. I to tyle — nie napisałem ani jednej linijki Swifta.
Jeśli chodzi o koszt, nie zapłaciłem nic ponad subskrypcje, które już mam: jedną za Codeksa i roczne konto Apple Developer. Miałem je wcześniej, więc nie dopłaciłem ani grosza.
To jest główny przekaz. Wgranie aplikacji na telefon jest teraz tak tanie i tak szybkie, że można to zrobić kilkoma promptami. Nie musisz martwić się o TestFlight, publikację, recenzje, App Store, oceny ani innych użytkowników. To tylko ty, twój Codex albo Claude Code, twój telefon i twoja aplikacja.
Więc co byś zrobił dla siebie? Może to jakaś powracająca zasada, obejście albo drobiazg, który teraz trzymasz w arkuszu kalkulacyjnym. Po prostu zbuduj to kilkoma promptami i Codeksem albo Claude Code, wgraj na telefon i zrób to dla najważniejszej bazy użytkowników — jednoosobowej: dla siebie.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Aplikacja dla „bazy użytkowników liczącej jedną osobę”
Na czym polega: AI obniżyło koszt i czas tworzenia natywnego oprogramowania na tyle, że opłaca się budować apki wyłącznie dla siebie — rozwiązujące jeden konkretny problem jednej osoby.
Jak stosować: Zidentyfikuj drobny rytuał lub obejście, które trzymasz w arkuszu, Notion czy na papierze, i potraktuj to jako brief dla jednej małej apki, którą zrobisz w jeden wieczór.
Na co uważać: Zaleta znika, gdy zaczniesz projektować „na wyrost” pod wielu użytkowników — wtedy dochodzą konta, synchronizacja, serwer i utrzymanie. Trzymaj się zakresu dla jednej osoby.
2.Pominięcie App Store, TestFlight i backendu
Na czym polega: Autor instaluje aplikację bezpośrednio na telefonie jako build deweloperski, całkowicie omijając publikację, recenzje Apple i infrastrukturę serwerową.
Jak stosować: Do prywatnych narzędzi wybieraj podpisany build deweloperski instalowany przez Xcode zamiast pełnej ścieżki wydawniczej — oszczędzasz dni pracy i formalności.
Na co uważać: To działa tylko dla użytku osobistego. W momencie, gdy chcesz udostępnić apkę innym, wracasz do pełnego procesu z kontami, bezpieczeństwem i utrzymaniem.
3.Budowa bez znajomości Swifta
Na czym polega: Cała aplikacja powstała przez prompty do Codeksa — autor nie napisał ani jednej linijki Swifta i edytor Xcode zobaczył dopiero na etapie podpisywania builda.
Jak stosować: Jeśli nie znasz języka danej platformy, i tak możesz zbudować działającą apkę, delegując kod do asystenta AI, a sam zajmując się briefem, testowaniem i decyzjami.
Na co uważać: Brak znajomości języka utrudnia diagnozę błędów podpisywania czy konfiguracji — miej pod ręką instrukcje na typowe awarie (jak brak development team) albo licz się z chwilą szukania.
4.Rozbicie pracy na kilka promptów zamiast jednego wielkiego
Na czym polega: Autor użył siedmiu promptów, budując funkcję po funkcji (ekran główny, oznaczanie zadań, utwardzenie logiki, ikona), zamiast jednego ogromnego polecenia.
Jak stosować: Dziel budowę na etapy, weryfikując każdy krok na symulatorze, zanim przejdziesz dalej — łatwiej wyłapać, gdzie coś poszło nie tak.
Na co uważać: Autor zaznacza, że jeden duży prompt też jest możliwy; wybór to kwestia kontroli i przejrzystości, a nie konieczności. Przy trudniejszych apkach etapowość zwykle się opłaca.
5.Weryfikacja stanu i trwałości danych na bieżąco
Na czym polega: Po każdej funkcji autor sprawdzał działanie — oznaczał zadanie, zamykał i ponownie otwierał apkę, żeby potwierdzić, że stan się utrzymuje.
Jak stosować: Przy apkach z lokalnym zapisem danych zawsze testuj cykl „zapisz → zamknij → otwórz ponownie”, bo to najczęstsze miejsce cichych błędów persystencji.
Na co uważać: Symulator nie zawsze zachowuje się jak fizyczny telefon — końcowy test rób na prawdziwym urządzeniu.
6.Zaprojektowana niezmienność jako cecha, nie ograniczenie
Na czym polega: Zasada „tylko do odczytu” (nie można edytować ani cofnąć zadania w ciągu dnia) jest celowa — chroni rytuał przed wymiganiem się od trudnego zadania.
Jak stosować: Gdy budujesz narzędzie wspierające nawyk, świadomie wpisz w logikę ograniczenia, które wymuszają pożądane zachowanie, zamiast dawać pełną elastyczność.
Na co uważać: Twarde ograniczenia frustrują, jeśli źle dobierzesz regułę. Sprawdź ją najpierw w wersji analogowej (jak papierowe kartki autora), zanim zakodujesz ją na stałe.
7.Wymagania techniczne instalacji na iPhonie
Na czym polega: Do wgrania apki potrzeba konta Apple (wystarczy darmowe), włączonego Trybu Deweloperskiego na telefonie i podpisanego builda z wybranym development team.
Jak stosować: Zanim zaczniesz, włącz Tryb Deweloperski (Ustawienia → Prywatność i bezpieczeństwo → Tryb Deweloperski, restart, potwierdzenie kodem) i upewnij się, że masz konto Apple podpięte w Xcode.
Na co uważać: Darmowy Personal Team ma limity — do 10 identyfikatorów aplikacji i trzy urządzenia, a profile wygasają po siedmiu dniach, więc apkę trzeba będzie okresowo instalować ponownie.
8.Typowe błędy podpisywania są do przewidzenia
Na czym polega: Pierwszy build padł z komunikatem „Signing requires a development team”; naprawa to po prostu wybór konta deweloperskiego i ponowna kompilacja (Command-R).
Jak stosować: Gdy zobaczysz ten błąd, wejdź w ustawienia podpisywania projektu, wybierz zespół (swoje konto Apple) i zbuduj ponownie — to standardowa, jednokrokowa naprawa.
Na co uważać: To tylko jeden z możliwych trybów awarii. Przy braku znajomości Swifta warto z góry przygotować się na kilka konfiguracyjnych potknięć wokół podpisywania i uprawnień.
9.Realny nakład czasu i kosztu
Na czym polega: Nagrana sesja to dwie godziny plus godzina przygotowania, siedem promptów, jedna ręczna interwencja i zero dodatkowych kosztów ponad już posiadane subskrypcje (Codex + Apple Developer).
Jak stosować: Traktuj to jako realistyczny benchmark: prostą osobistą apkę da się zrobić w jeden wieczór, bez nowych wydatków, jeśli masz już asystenta AI i konto Apple.
Na co uważać: Autor robił to na żywo, bez próby generalnej, i mimo to trafił na błąd — zaplanuj bufor czasu na nieprzewidziane potknięcia, zwłaszcza za pierwszym razem.
10.Lokalne przechowywanie danych upraszcza wszystko
Na czym polega: Aplikacja trzyma wszystko na telefonie — nie ma serwera, kont ani synchronizacji, dzięki czemu znika cała warstwa bezpieczeństwa i utrzymania.
Jak stosować: Dla narzędzi osobistych domyślnie wybieraj lokalny zapis danych — eliminuje to największe źródło złożoności i obowiązków utrzymaniowych.
Na co uważać: Dane lokalne nie mają backupu ani synchronizacji między urządzeniami. Jeśli stracisz telefon lub przeinstalujesz apkę, możesz stracić dane — dla ważniejszych rzeczy pomyśl o eksporcie lub kopii.