Jak radzi sobie moja aplikacja (trochę w martwym punkcie)

O czym jest ten film

Rozliczenie stanu aplikacji Amie: około 3,4–3,5 tys. dol. MRR, marża rzędu 85%, 336 płacących użytkowników — ale wyniki falują i churn nie odpuszcza.
Strategia autora na odpływ klientów: nie kampanie, tylko maksymalne upraszczanie codziennego logowania posiłków.
Budowa aplikacji na Apple Watch z agentem Codex: szczegółowy prompt, dwa symulatory (zegarek i telefon), Xcode Build MCP — pierwsza działająca wersja w około dwie godziny.
Testy na żywo ujawniły prawdziwą potrzebę: nie „ile zjadłem”, lecz „ile kalorii zostało do końca dnia” — i stąd konieczność komplikacji na tarczy zegarka.
Dyktowanie posiłków głosem na zegarku to przewaga, której konkurencja nie ma: MyFitnessPal nie obsługuje głosu, a aplikacje oparte na zdjęciach nie zadziałają z nadgarstka.
Pułapka techniczna WatchConnectivity: o połączeniu zegarka z telefonem decyduje Apple (np. tryb oszczędzania energii je zrywa), więc kluczowe akcje trzeba przenieść na urządzenie.
Efekt zmian: 30–40% korzystania z Amie przeniosło się na zegarek, a autor loguje tam głosem już około 40% posiłków.
Trzy argumenty za wersją na zegarek: wartościowa „działka” na tarczy, zaniedbana przez konkurencję, i niski koszt budowy dzięki agentom kodującym.
Greptile — automatyczny przegląd kodu w kontekście całej bazy, z oceną 1–5 i pętlą agentów aż do piątki — jako substytut zespołu dla solowego dewelopera.
Dwa drobniejsze usprawnienia: rozszerzenie share sheet przyjmujące zdjęcia z inteligentnym rozpoznawaniem (menu, danie, lista składników) oraz automatyczne skracanie długich wpisów.

Redakcyjne tłumaczenie

Powrót po przerwie: o jakiej aplikacji mowa

Na tym kanale dawno nie było aktualizacji z Amie, więc dzisiaj podzielę się liczbami i stanem aplikacji. Najbardziej chce mi się jednak opowiedzieć o tym, co dodałem, żeby wygodniej się z niej korzystało. Na niektóre rozwiązania jestem naprawdę dumny — zwłaszcza na nowe doświadczenie na Apple Watch, o którym mam sporo do powiedzenia. Jeśli trafiliście tu pierwszy raz, witajcie: nazywam się Chris i buduję aplikacje produktywnościowe. Zwykle w każdym filmie zajmuję się jedną z nich, a dzisiaj rozmawiamy o Amie.

W skrócie: Amie to tracker kalorii w stylistyce Apple Notes. Wystarczy wpisać, co się zjadło, a kalorie pojawiają się po prawej stronie, jakby za sprawą magii. To dziś najprostszy na rynku sposób na liczenie kalorii.

Liczby: 3,4–3,5 tys. dol. MRR, 85% marży i uparty churn

Zacznijmy od liczb, bo wiem, że wielu na nie czeka. Amie generuje obecnie od 3,4 do 3,5 tys. dol. MRR (miesięcznego przychodu powtarzalnego) — tuż pod progiem 3,5 tys. — a marża sięga około 85%, co cieszy mnie najbardziej. Całość przy zaledwie 336 płacących użytkownikach.

Szczerze mówiąc, te wyniki sporo falują: zwykle krążę między 3,2 a 3,5 tys. Oznacza to, że churn, czyli odsetek osób rezygnujących z subskrypcji, jest spory i trudny do ogarnięcia. Dlatego cała moja obecna praca sprowadza się do jednego pytania: jak jeszcze uprościć i wygładzić samo korzystanie z aplikacji oraz zapisywanie posiłków? Bo gdy logowanie kalorii nie wymaga wysiłku, użytkownikom znacznie łatwiej wyrobić w sobie nawyk.

Co już mamy, a czego brakowało

Przejrzałem więc nasze atuty. Mamy jedną z najlepszych integracji z Siri na rynku: mówicie asystentowi zwyczajnym angielskim, co jedliście, a on zapisuje to w aplikacji. Żaden inny tracker kalorii tego nie potrafi. Mamy też bardzo dobre widżety, które przypominają o aplikacji w ciągu dnia.

Jedno duże pole zostało jednak nietknięte: Apple Watch. Myślę, że głównym powodem, dla którego wersji na zegarek nie było, jest to, że nikt o tym temacie nie mówi. To nisza — i właśnie dlatego nagrałem ten film: żeby pokazać wam, jak to dziś proste i dlaczego warto.

Zlecenie dla Codexa: dwa symulatory, jeden MCP, dwie godziny

Zdecydowałem się zbudować aplikację na zegarek i byłem ciekaw, jak trudne to okaże się w praktyce. Miałem przeczucie, że z agentami AI pójdzie szybko — i tak wyszło. Odpaliłem Codexa i przy jego pomocy powstawała całość.

Najpierw napisałem bardzo szczegółowy prompt opisujący, czego oczekuję od integracji. Dodałem do niego coś, co lubię pokazywać, bo zawsze robi na ludziach wrażenie: dwa symulatory — Apple Watcha i iPhone’a. Po co oba? Żeby agent mógł porządnie testować: wersja na zegarku musi komunikować się z tą na telefonie, żeby w ogóle działać.

Kazałem mu też używać Xcode Build MCP — zalecam to każdemu, kto buduje aplikacje na iOS i watchOS. (Informacja dodatkowa: MCP to standard łączenia agentów AI z narzędziami zewnętrznymi; „Xcode Build MCP” pozwala agentowi samodzielnie kompilować projekt i na bieżąco czytać logi.) Daje to Codexowi możliwość budowania aplikacji i śledzenia strumienia logów, co przy debugowaniu jest bezcenne. Do tego poleciłem mu sterować oboma symulatorami jednocześnie podczas testów.

Agent pracował jakieś dwie godziny i na końcu miałem w pełni sprawną aplikację na Apple Watcha ze wszystkim, co podstawowe: pokazywała, ile kalorii zjadłem w ciągu dnia — a to była główna informacja, którą chciałem widzieć.

Pierwsze dni na nadgarstku: prawdziwa specyfikacja pisze się sama

Potem zrobiłem to, co zawsze robię i czego zawsze doradzam: wziąłem aplikację na żywo, do codziennego użytku. Tylko wtedy widać ograniczenia. Ponieważ korzystam z niej każdego dnia, w kilka minut było jasne, co nie gra.

Po pierwsze, zrozumiałem, co jest dla mnie naprawdę ważne. Wcale nie interesuje mnie, ile kalorii już zjadłem — chcę wiedzieć, ile mam jeszcze do dyspozycji do końca dnia. A jedyna droga, żeby to sprawdzić, prowadziła przez odnalezienie aplikacji, jej otwarcie i dopiero wtedy obejrzenie wyniku. Szybko doszedłem do wniosku: potrzebujemy komplikacji.

Komplikacje — tak Apple nazywa te maleńkie elementy na tarczy zegarka. Jeśli chcecie pokazywać tam mini-widżet, trzeba go zbudować osobno, niezależnie od samej aplikacji. Formalnie są to dwa oddzielne byty. Najpiękniejsze w komplikacji jest jednak to, że nie trzeba niczego dotykać — wystarczy jedno spojrzenie. Do śledzenia kalorii pasuje to idealnie.

Czego wcześniej nie wiedziałem: typów komplikacji jest mnóstwo. Teoretycznie można zostawić, „jak wyszło”, ale radzę przetestować kilka i wybrać najlepsze. Bo jeśli poprosicie Claude Code albo Codexa, żeby na wyczucie nagenerował ich całą masę, dostaniecie śmieci — dokładnie jak ja. Większość była bezużyteczna, często ucięta w połowie i zwyczajnie nie działała. Budujecie wersję na zegarek? Przejrzyjcie każdą komplikację osobno i upewnijcie się, że realnie jest komuś potrzebna.

Po wielu próbach stworzyliśmy całkiem przyzwoite komplikacje i mieliśmy świetną aplikację pokazującą dokładnie to, czego potrzebowałem: ile kalorii zostało do końca dnia i co już zjadłem. Była tam nawet lista posiłków oraz świetne wykresy białka, węglowodanów i tłuszczów. Wszystko do wglądu jednym spojrzeniem.

Dyktowanie na zegarku, czyli okazja, która sama się prosiła

Gdy zacząłem z tego korzystać na co dzień, kolejny krok sam się nasunął. Raz przypomniałem sobie, że zapomniałem czegoś zalogować — a telefon leżał w drugim pokoju. Pomyślałem: „szkoda, że nie mogę po prostu powiedzieć Amie, co zjadłem”. I po chwili dotarło do mnie: przecież mogę to sobie zbudować. Mamy już świetną integrację z Siri na telefonie; czemu nie przenieść jej na zegarek?

Nie byłem pewien, czy technicznie się da. Sprawdziłem — i się da. Apple pozwala aplikacjom korzystać z mikrofonu, więc dyktowanie na zegarku jest jak najbardziej możliwe. Poszedłem dalej i upewniłem się, że na rynku nikt tego nie oferuje: MyFitnessPal nie obsługuje wpisywania posiłków głosem, a aplikacje pokroju Cal AI, oparte na zdjęciach, nie mają tu czego szukać, bo z zegarka nie zrobi się fotografii. Tu Amie znajduje się w wygodnej pozycji: nasza integracja z Siri już potrafi przyjąć opis posiłku i w tle przeliczyć go na kalorie. Wystarczyło przenieść ten sam mechanizm na nadgarstek.

Trzeba było tylko rozgryźć, jak uruchomić dyktowanie na zegarku i przesłać je tak, żeby przeszło przez tę samą ścieżkę co Siri. Zajęło to chwilę, a prawdziwym wyzwaniem okazał się sam interfejs. Rozważałem widok pełnoekranowy albo osadzony; ostatecznie zdecydowałem się na taki układ: w aplikacji jest przycisk, po jego naciśnięciu wchodzi się w tryb dyktowania, mówi coś w rodzaju „burger z frytkami i colą light”, klika jeszcze raz — i tekst wędruje do aplikacji na telefonie, jest przetwarzany jak w integracji z Siri, kalorie zostają wyliczone, a wynik wraca na zegarek, żeby można go było obejrzeć. Klik „gotowe” — wpis zapisany. Prawdopodobnie najlepsze doświadczenie śledzenia kalorii na zegarku, jakie dziś istnieje. Nie mówię tego z sentymentu do własnego dzieła — przed zbudowaniem tej funkcji sam nie wiedziałem, że coś takiego jest w ogóle możliwe. Przy okazji narodziły się pomysły na podobne integracje w moich innych projektach, na przykład w Ellie, aplikacji do planowania dnia. Zapewniam, że tam też się tego podejmę.

Rozłączenie bez ostrzeżenia: lekcja architektury

Kilka dni później trafiliśmy na problem. Zauważyłem, że dyktowanie co jakiś czas zawodzi bez wyraźnego powodu: dane nie docierały do telefonu, a aplikacja zgłaszała rozłączenie. Zacząłem drążyć, bo nie wiedziałem, czy nie zbudowałem czegoś źle.

Dla kontekstu: Apple udostępnia framework WatchConnectivity — i właśnie nim wymienia się dane między zegarkiem a telefonem. Pierwsza wersja mojej aplikacji, skonfigurowana przez Codexa (a wyglądała dla mnie sensownie), działała tak: zegarek przesyłał strumień audio do aplikacji na telefonie, a ta przekazywała go backendowi do przetworzenia. Całością sterowałem z nadgarstka, ale ciężką robotę robił iPhone.

I wyszło na jaw, że połączenie między zegarkiem a telefonem to nie coś, co da się w pełni kontrolować — rządzi nim Apple. Są sytuacje, w których system po prostu je zrywa: na przykład gdy telefon przejdzie w tryb oszczędzania energii, Apple może odciąć aplikację na zegarku, żeby ratować baterię.

Wniosek: to świadoma decyzja architektoniczna, którą musicie podjąć sami. Czy zegarek ma zależeć od telefonu — co w wielu aplikacjach jest w pełni sensowne i nie ma w tym nic złego — czy ma być bardziej samodzielny?

Wymyśliłem więc rozwiązanie, w którym aplikacja na zegarku łączy się bezpośrednio z moim backendem, a całą resztę — dyktowanie i wyliczanie kalorii — wykonuje sama, bez pośrednictwa telefonu. Część funkcji zostawiłem jednak przy starym „moście”: regularne odpytywanie o dane kaloryczne nadal idzie przez WatchConnectivity, bo te informacje nie muszą być aktualne co do sekundy. Ale coś takiego jak dyktowanie musi po prostu zadziałać w tej konkretnej chwili, gdy użytkownik unosi nadgarstek i chce mówić. Nie możemy czekać, aż zegarek i telefon połączą się ponownie — to odpada.

Po tej zmianie stabilność poprawiła się w stu procentach: dyktowanie działa za każdym razem. Testuję to od kilku tygodni i ani razu się nie zawiodłem.

Czy zegarek zatrzyma churn? Sam nie wiem — ale przenosi korzystanie

Czy sama aplikacja na Apple Watcha zdoła poważnie obniżyć churn? Prawdopodobnie nie. Kto wie, może w następnej aktualizacji powiem wam, że zrobiła różnicę. Wiem natomiast tyle: już 30–40% mojego korzystania z Amie odbywa się na zegarku. Po to, żeby sprawdzić, ile kalorii mi zostało, nie odblokowuję już telefonu i nie zaglądam do widżetu — patrzę na nadgarstek. Jeśli chodzi o samo logowanie, szacuję, że około 40% wpisów robię teraz głosem na zegarku, bo to po prostu najwygodniejsza droga.

Dokładnie to samo mówiłem o integracji z Siri w poprzednim filmie: pojedyncza funkcja raczej sama nie zmieni retencji. Ale gdy złożycie Siri, widżety, zegarek i to, o czym zaraz opowiem, wychodzi z tego doświadczenie naprawdę bezwysiłkowe. Użytkownik to zobaczy i pomyśli: „nie mogę uwierzyć, że coś takiego w ogóle jest możliwe”. A to cudownie.

Trzy powody, by zbudować wersję na zegarek

Mam powody sądzić, że większość twórców aplikacji powinna zrobić wersję na Apple Watch.

Po pierwsze, to świetnie zainwestowana „działka”. Aplikacji na Apple Watch jest w sklepach bardzo mało. Jeśli uda wam się zainstalować na zegarku — zwłaszcza jako komplikacja na głównym ekranie — użytkownik będzie was widywał kilka razy dziennie. Działa to trochę jak widżety na ekranie blokady iPhone’a.

Po drugie, konkurencja w waszej kategorii prawie na pewno nie zrobi tego dobrze. Nawet u mnie, w śledzeniu kalorii — chyba najbardziej zapchanej i agresywnej niszy, w której wersja na zegarek powinna być oczywistością — niewiele aplikacji oferuje porządną integrację. Zrobicie to, i już od razu odstajecie jakością od reszty.

Po trzecie — i to chyba najważniejsze — z Claude Code i Codex zbudowanie takiej integracji jest niewiarygodnie tanie. Pierwsza wersja powstała w dwie godziny, dopracowanie kolejnych zajęło kilka dni. Dwa lata temu zegarek był osobnym projektem, niemal osobną aplikacją. Dziś, dzięki kodowaniu z AI, to po prostu funkcja.

Jeśli zastanawiacie się, czy w waszym przypadku ma to sens — często tak, choć nie zawsze; zdarzają się aplikacje, dla których zegarek nic nie wnosi. Pamiętajcie przy tym, że nie przenosicie całego produktu. Wystarczy jedna kluczowa funkcja, którą użytkownik chce sprawdzać wielokrotnie w ciągu dnia — i z tego rodzi się znakomite doświadczenie na zegarku.

Greptile: jak wysyłam kod na produkcję bez zespołu

(Fragment sponsorski.)

Zauważyliście pewnie, że wypuszczam te rzeczy bardzo szybko i robię to sam. Nie mam zespołu i nikt nie ogląda mojego kodu, zanim trafi na produkcję. Najczęstsze pytanie brzmi więc: jak w ogóle sprawdzasz kod? Czy robisz przegląd? Odpowiedź: Greptile. Dziękuję im za sponsoring tego filmu, ale ręczę, że polecałbym ich dokładnie tak samo bez umowy — do przeglądu kodu używam właśnie tego narzędzia.

W skrócie: Greptile to usługa przeglądu kodu wspomaganego przez AI. Podłączacie repozytorium i od tej chwili każdy pull request jest automatycznie recenzowany. Nie patrzy przy tym wyłącznie na same zmiany, lecz ocenia PR w kontekście całej bazy kodu. Działa bardzo skrupulatnie i naprawdę wyłapuje konkretne problemy, błędy, przypadki brzegowe oraz regresje. Powtarzam: nie mówię tego dlatego, że to sponsor. Są w tym borcy — i bez ich recenzji nie wysyłam niczego na produkcję. Po zakończeniu pracy usługa zostawia komentarz bezpośrednio w PR, żebyście mogli wszystko zweryfikować.

U mnie cały mechanizm z tego filmu — od aplikacji na zegarku po rozszerzenie share sheet, o którym zaraz opowiem — przeszedł przez Greptile kilka razy, zanim dotarł do sklepu. Korzystam z tego tak: każę agentowi — Claude Code albo Codexowi — kręcić małą pętlą. „Czekaj, aż skończy się przegląd w Greptile, popraw wszystko, co znalazł, i powtarzaj, aż Greptile da piątkę”. Greptile ocenia każdy PR w skali od jedynki do piątki, a ja wypuszczam dopiero przy piątce. Dla solowego dewelopera to ogromna sprawa: nie mam inżyniera, który by sprawdził moją pracę, a każdego dnia z aplikacji korzystają tysiące osób — więc ostrożność jest na miejscu. Dzięki Greptile śpię spokojnie, bo moje wydania mają dużą szansę być wolne od błędów. Link wrzucę do opisu; jest darmowy plan, więc nie ma powodu nie spróbować. I uprzedzam: jak się raz zacznie, trudno wrócić. Ja bez Greptile już nie wysyłam kodu.

Wracam do tematu, bo dodałem jeszcze dwie rzeczy — obie, podobnie jak zegarek, służą temu samemu: jak najmniej zachodu po stronie użytkownika.

Pierwsza to rozszerzenie share sheet. (Informacja dodatkowa: w iOS share sheet to systemowy panel udostępniania; aplikacja może dodać do niego własną akcję, która odbiera udostępnianą treść, na przykład zdjęcie.) Odkryłem je niedawno i zdziwiło mnie, jak potężne i konfigurowalne to narzędzie. Podobnie jak przy zegarku: nikt o tym nie opowiada, więc pokazuję wam.

Skąd pomysł? Jest kilka restauracji, w których zamawiam online z wyprzedzeniem — między innymi Cava. (Informacja dodatkowa: Cava to amerykańska sieć restauracji typu fast casual, gdzie zamówienia często składa się przez aplikację.) Kiedy chciałem zalogować takie zamówienie w Amie, zwykle dyktowałem je z pamięci, zaglądając w szczegóły zamówienia. Działało, ale bywało irytujące. Aż w końcu pomyślałem: fajnie byłoby zrobić zrzut ekranu zamówienia i wysłać go prosto do Amie. Chwila — chyba da się to jakoś zrobić? Poszukałem i trafiłem właśnie na rozszerzenie share sheet, pozwalające dodać własną akcję — ikonkę wśród innych w panelu udostępniania — przez którą można przekazać zdjęcie do aplikacji. Ja używam tego, by przesłać obraz do Amie i pozwolić jej go rozpoznać, wyciągnąć dane i zapisać.

Zbudowanie rozszerzenia jest bardzo proste; zaskoczyło mnie natomiast, ile się z tym da zrobić. U mnie udostępnienie dowolnego zdjęcia Amie uruchamia inteligentne rozpoznanie: czy to menu? Zdjęcie dania? A może lista składników? Cała ta klasyfikacja dzieje się w tle po kliknięciu „udostępnij”, a na końcu renderuję różne ekrany zależnie od tego, co wykryto. Udostępnicie menu — pokaże się nasz pełny interfejs wyboru pozycji, żebyście zaznaczyli, co dokładnie trafia do Amie. Przyciągniecie zdjęcie gotowego dania — aplikacja pominie ten krok i od razu otworzy ekran z makroskładnikami i resztą danych. Poślecie listę składników, jak w moim zamówieniu z Cavy — system sprytnie ją odczyta, spróbuje rozpoznać restaurację i zadziała tak samo: przepuszcza informacje przez nasz dotychczasowy proces i pokazuje szczegóły żywieniowe.

Podobnie jak przy zegarku, gdy pojąłem, co to umożliwia, byłem bardzo podekscytowany — planuję tu mnóstwo rzeczy, ale pokazuję wam to teraz, bo może zrobicie z tym coś świetnego.

Drobiazg, na którym mi zależy: skracanie długich wpisów

Druga zmiana jest znacznie mniejsza, ale jestem z niej dumny. Amie jest tekstowa, więc pod koniec dnia, po wpisaniu wielu posiłków, notatka robi się długa i ciężka do czytania. Teraz bardzo długie wpisy Amie potrafi automatycznie skrócić. Towarzyszy temu ładna animacja i FTUX — first-time user experience, czyli wyjaśnienie pokazywane osobom, które widzą daną funkcję po raz pierwszy. Gdy skracanie zadziała pierwszy raz, opowiemy użytkownikowi, co się stało, a każdy będzie mógł je wyłączyć w ustawieniach.

O budowaniu zaufania mówiłem w poprzednim filmie i chętnie powtórzę: to potwierdzenie tezy, że dobra aplikacja to tysiąc dobrze zrobionych drobiazgów, które w sumie układają się w porządne wrażenie. Czy auto-skracanie podniesie retencję? Pewnie nie. Ale jeśli zrobicie tysiąc takich drobnych rzeczy porządnie, wychodzi z tego dobre doświadczenie.

Stan na dziś i co dalej

Tak wygląda Amie obecnie — takie liczby i takie funkcje chciałem wam pokazać. Szczerze? Chyba niewiele zostało do dodania. Aplikacja osiągnęła stan stabilny; została drobna polerka i eksperymenty. Może nagram kiedyś o próbach, które nie weszły do produktu: testowałem funkcję społecznościową oraz automatyczne podpowiadanie posiłków, ale na razie ich nie wypuściłem — może podzielę się nimi w innej aktualizacji.

Obecnym stanem jestem bardzo zadowolony i wierzę, że to jeden z najlepszych trackerów kalorii na rynku — jeśli nie najlepszy. Najważniejsze jednak, że ludzie, którzy z niego korzystają, zostają i lubią aplikację.

Jeśli ten film przekonał was do zbudowania aplikacji na Apple Watch albo rozszerzenia share sheet — dajcie znać w komentarzach. Zaczynam też newsletter, link znajdziecie w opisie: tam będę szczegółowo dzielić się strategią i przemyśleniami o budowaniu aplikacji — tym, na co nie ma miejsca na YouTube. Na przykład w filmie o moim stanowisku testowym mówiłem o nowej kamerze Amie przez 30 sekund, a nakręciłem na ten temat jakieś 20 minut materiału, które wyciąłem, bo robiło się nudnawo. Z tych 20 minut powstał wpis na newslettera, który czyta się znacznie przyjemniej. Chcecie poznać moje otwarte przemyślenia o projektowaniu aplikacji i budowaniu doświadczenia — zajrzyjcie tam. Planuję publikację raz w tygodniu. Jeśli podobał wam się ten materiał, śledźcie mnie na Instagramie i TikToku — codziennie albo co drugi dzień wrzucam tam aktualizacje z pracy nad aplikacjami. I oczywiście zapiszcie się na kanał. Dzięki za obejrzenie — do zobaczenia w następnym filmie.

10 najważniejszych takeaways — z kontekstem zastosowania

1.Prawdziwa specyfikacja rodzi się z codziennego użytku, nie z promptu

Na czym polega: Pierwsza wersja na zegarek pokazywała „ile kalorii zjadłem”, ale autorowi realnie chodziło o „ile zostało do końca dnia”. Ujawniło się to dopiero po kilku minutach samodzielnego używania aplikacji — i doprowadziło do komplikacji na tarczy zegarka.

Jak stosować: Po każdej iteracji korzystaj z funkcji przez kilka dni na własnej skórze i notuj momenty irytacji lub zbędnych kliknięć — to gotowa lista wymagań na kolejną wersję.

Na co uważać: Agent wykona prompt, ale nie odgadnie intuicji użytkownika; prompt nie zastąpi własnego testu na żywo.

2.Przygotuj agentowi pełne środowisko testowe: dwa symulatory i dostęp do builda

Na czym polega: Autor dał Codexowi symulator iPhone’a i Apple Watcha jednocześnie, polecił używać Xcode Build MCP (kompilacja i strumień logów) oraz sterować oboma symulatorami w trakcie testów. Dzięki temu agent sam sprawdzał komunikację zegarka z telefonem.

Jak stosować: W prompcie jawnie opisz środowisko: jakie symulatory, jak kompilować, skąd czytać logi. Im więcej agent może zweryfikować sam, tym mniej błędów wróci do ciebie.

Na co uważać: Bez dostępu do logów agent działa na ślepo i „zgaduje” poprawność. Symulatory nie oddają też warunków realnych — np. zrywania połączenia przez system.

3.Zegarek to dziś funkcja, a nie projekt — planuj iteracje, nie perfekcję

Na czym polega: Pierwsza działająca wersja integracji powstała w około dwie godziny pracy agenta; dopracowanie (komplikacje, dyktowanie, stabilność) zajęło kilka dni. Dwa lata temu taka integracja oznaczała projekt wielkości osobnej aplikacji.

Jak stosować: Wyceniaj wersję na zegarek jako zwykłą funkcję w sprincie i zaczynaj od jednej kluczowej wartości dla użytkownika, a nie od portowania całości.

Na co uważać: „Działa w symulatorze” to nie to samo co stabilne na produkcji — prawdziwy koszt tkwi w dopracowaniu architektury i szczegółach typu komplikacje.

4.Komplikacje generowane przez AI wymagają brutalnej selekcji

Na czym polega: Gdy autor kazał agentowi stworzyć wiele typów komplikacji naraz, większość okazała się bezużyteczna, ucięta w połowie lub niedziałająca. Dopiero ręczne testowanie i iteracje dały wartościowy efekt.

Jak stosować: Generuj szeroko, ale testuj każdą komplikację osobno na prawdziwej tarczy i zostaw jedną–trzy, które realnie coś wnoszą.

Na co uważać: Komplikacja to osobny byt względem aplikacji — ma osobny kod i osobne wymagania testowe; „jednym rzutem” tego nie załatwisz.

5.Nie buduj kluczowych akcji na połączeniu zegarka z telefonem

Na czym polega: W architekturze opartej na WatchConnectivity zegarek przesyłał audio do telefonu, a telefon do backendu. Okazało się, że o połączeniu rządzi Apple — np. tryb oszczędzania energii na telefonie może je zerwać — i dyktowanie losowo zawodziło. Przeniesienie dyktowania i wyliczania kalorii na urządzenie (plus bezpośredni dostęp do backendu) dało stuprocentową poprawę stabilności.

Jak stosować: Oddziel funkcje krytyczne czasowo (tu i teraz, na nadgarstku) od danych, którym chwila opóźnienia nie szkodzi. Te pierwsze realizuj na urządzeniu lub bezpośrednio z backendem; przez „most” do telefonu przesyłaj tylko synchronizację w tle.

Na co uważać: Przeniesienie logiki na zegarek zwiększa złożoność (sieć, bateria, utrzymanie kodu na dwóch platformach) — nie każda funkcja tego potrzebuje; u części aplikacji zależność od telefonu jest w pełni uzasadniona.

6.Różnicuj się tam, gdzie konkurencja zaniedbała

Na czym polega: Nawet w śledzeniu kalorii — jednej z najbardziej nasyconych kategorii — niewiele aplikacji ma porządną wersję na zegarek, a żadna nie oferuje dyktowania głosem (MyFitnessPal bez głosu, Cal AI bez możliwości zdjęcia z zegarka). Amie wypełniła obie luki naraz.

Jak stosować: Przejrzyj czołową konkurencję w swojej kategorii pod kątem platform i punktów wejścia: watchOS, widżety, Siri, share sheet. Znajdź lukę pasującą do twojego przypadku użycia i zbuduj ją tanio z agentem AI.

Na co uważać: Luka ma sens tylko wtedy, gdy odpowiada realnej potrzebie użytkownika — zdarzają się produkty, dla których zegarek nic nie wnosi.

7.Zakres wersji na zegarek: jedna, często sprawdzana funkcja

Na czym polega: Autor podkreśla, że nie przenosi całej aplikacji na zegarek, lecz wybiera dane, które użytkownik chce widzieć wielokrotnie w ciągu dnia (pozostałe kalorie, szybkie logowanie głosem) — i to stanowi całe doświadczenie.

Jak stosować: Wskaż najkrótszą pętlę „sprawdź / zrób” w swoim produkcie i zbuduj wokół niej cały interfejs zegarka plus komplikację na tarczy.

Na co uważać: Próba zmieszczenia całego interfejsu z telefonu na zegarku psuje prostotę — a uwagę użytkownika na tarczy zdobywa się tylko jedną, czytelną informacją.

8.Automatyczny przegląd kodu jako zespół zastępczy solowego dewelopera

Na czym polega: Autor wysyła kod na produkcję sam, bez inżyniera. Greptile recenzuje każdy PR w kontekście całej bazy, ocenia go w skali 1–5, a agent (Claude Code/Codex) dostaje pętlę: czekaj na recenzję, popraw uwagi, powtarzaj aż do piątki. Release dopiero przy 5/5.

Jak stosować: Podłącz repozytorium do narzędzia przeglądu AI, ustal twardą regułę jakości (np. „wydaję tylko przy maksymalnej ocenie”) i zautomatyzuj pętlę agent–poprawki–recenzja.

Na co uważać: Ocena automatu nie gwarantuje bezbłędności — łącz ją z własnym testem na żywo. Pamiętaj też, że to fragment sponsorski: zweryfikuj narzędzie na własnym kodzie, zanim je standardyzujesz.

Na czym polega: Własna akcja w systemowym panelu udostępniania pozwala jednym dotknięciem przesłać do Amie zdjęcie, które aplikacja inteligentnie klasyfikuje (menu, danie, lista składników) i odpowiednio do tego dobiera interfejs — od wyboru pozycji z menu po od razu gotowe makroskładniki.

Jak stosować: Zmapuj, skąd twoi użytkownicy realnie biorą dane (zrzuty zamówień, menu, etykiety), i daj im możliwość „wysłania” tego materiału prosto do aplikacji, zamiast wymuszać przepisywanie lub dyktowanie.

Na co uważać: Rozpoznawanie musi być odporne na przypadkowe obrazy, a przetwarzanie zdjęć wiąże się z prywatnością — użytkownik powinien wiedzieć, co dzieje się z materiałem; przy nowej funkcji pomaga proste wyjaśnienie FTUX.

10.Retencji nie buduje jedna funkcja, tylko suma drobiazgów

Na czym polega: Ani Siri, ani widżety, ani zegarek, ani auto-skracanie wpisów — każde z osobna — nie zatrzymały churnu w Amie. Razem jednak tworzą bezwysiłkowe doświadczenie: autor przeniósł już 30–40% korzystania z aplikacji i ok. 40% logowania na zegarek.

Jak stosować: Traktuj kolejne usprawnienia jako elementy jednego celu — usuwania tarć w codziennej pętli użytkownika — i mierz udział poszczególnych kanałów użycia, żeby widzieć, czy suma faktycznie pracuje na wygodę.

Na co uważać: Wzrost udziału użycia nowego kanału to metryka pośrednia; ostatecznie zweryfikuj efekt na twardych danych o retencji, zanim uznasz strategię za skuteczną.