iPhone Duo potrzebuje aplikacji — a AI potrafi je napisać

2026-10-02 • Riley Brown • AI zagraniczne •tutorial •waga 4/5 •16 min czytania

Cztery kroki i pięć promptów wystarczą, by z Claude Opus 5.5 zbudować aplikację na nowego iPhone'a Duo — bez linijki kodu. Solidny przewodnik dla twórców chcących wejść w świeży ekosystem jako pierwsi.

Robocza publikacja redakcyjna na podstawie publicznego transkryptu YouTube. Źródło: YouTube.

Oryginalny tytuł filmu

The iPhone Duo Needs Apps

O czym jest ten film

  1. Riley Brown buduje od zera aplikację na świeżo zapowiedzianego iPhone’a Duo — z modelem Claude Opus 5.5, bez pisania choćby jednej linijki kodu.
  2. Całość mieści się w czterech krokach: przygotowanie narzędzi, pomysł z prototypem, przeniesienie danych do chmury, testy i doszlifowanie.
  3. Warsztat to Mac (M1 lub nowszy), aplikacja Claude na komputerze i Xcode 27.1 beta — dopiero ta wersja dodaje symulator iPhone’a Duo do panelu DeviceHub.
  4. Zanim powstanie właściwy program, agent dostaje polecenie kontrolne: prosty „Hello World” w Swiftcie, który weryfikuje całą drogę od kodu do symulatora.
  5. Właściwa budowa odbywa się jednym promptem: tablica w stylu Excalidraw po lewej, generator naklejek po prawej; pierwszy przebieg trwa 37 minut.
  6. Grafiki przychodzą z wyszukiwarki Google (przez SerpApi), tło wycina remove.bg, a białą obwódkę w stylu naklejki model wymyślił sam.
  7. W segmencie sponsorskim Riley przedstawia Convex — chmurowe zaplecze z bazą działającą na żywo i oficjalną wtyczką do Claude Code.
  8. Kolejne polecenie przenosi dane do chmury i dodaje linki do udostępniania tablic; przebieg trwa 57 minut, a zmiany widać natychmiast w przeglądarce.
  9. Ostatnia iteracja porządkuje interfejs: mniej przycisków, animacja powstawania naklejki, filtrowanie już wygenerowanych grafik i nowa nazwa — Native Board.
  10. Łącznie pięć promptów; kod trafił na publiczne repozytorium na GitHubie z instrukcją instalacji „od zera”, a autor zapowiada kolejne eksperymenty, gdy tylko dostanie fizyczne urządzenie.

10 najważniejszych takeaways — z kontekstem zastosowania

1.Nowy sprzęt to krótkie okno dla pierwszych

Na czym polega: Riley powtarza sprawdzoną prawidłowość z ekosystemu Apple: przy każdej premierze urządzenia garstka twórców pisze pierwsze naprawdę dobre aplikacje i przez dłuższy czas cieszy się rozpoznawalnością, dopóki konkurencja jest niewielka. iPhone Duo właśnie został zapowiedziany, więc pula gotowych programów jest wciąż uboga.

Jak stosować: śledź zapowiedzi sprzętowe i miej pomysł „w szufladzie” — prosty, ale rozwiązujący jedną konkretną potrzebę (tu: tablica z wyszukiwalnymi naklejkami). Dzięki agentom prototyp zrobisz w weekend, a nie w kwartał.

Na co uważać: okno zamyka się szybko, a aplikacja znana tylko z symulatora to nie to samo, co działająca na fizycznym urządzeniu — autor sam dopiero za około trzy tygodnie dostanie Duo.

2.Zanim zbudujesz aplikację, sprawdź środowisko „Hello Worldem”

Na czym polega: pierwsze polecenie Riley’ego nie tworzy docelowego produktu, tylko minimalną aplikację „Hello World” w Swiftcie, skompilowaną i odpaloną w symulatorze. To test całej ścieżki: kod → budowanie → uruchomienie.

Jak stosować: na starcie projektu każ agentowi wygenerować najprostszą możliwą aplikację i uruchomić ją na właściwym symulatorze. Dopiero gdy to działa, wydawaj „grubszego” prompta na właściwą budowę.

Na co uważać: jeśli symulatora Duo nie ma na liście urządzeń, winna jest wersja Xcode (potrzebna 27.1 beta), a nie treść polecenia — bez tego model będzie walczył ze środowiskiem zamiast budować.

3.Dawaj agentowi kontekst: obrazy, inspiracje i polecenie „doczytaj w sieci”

Na czym polega: w głównym prompcie Riley opisuje zachowanie aplikacji (tablica po lewej, naklejki po prawej, układ poziomy), dołącza zrzut z Twittera i grafikę wygenerowaną przez AI, a dodatkowo każe modelowi samemu poszukać w internecie dobrych praktyk projektowania pod Duo.

Jak stosować: zamiast „zrób ładną apkę” opisz podział ekranu, cel użytkownika i wskaż wzorce; pozwól modelowi dopowiedzieć sobie konwencje nowej platformy.

Na co uważać: im mniej konkretów, tym bardziej bezbarwny efekt — pierwsza wersja u Riley’ego wyglądała na tyle słabo, że osobny prompt poświęcił wyłącznie odświeżeniu wyglądu.

4.Pierwszy prompt budujący puszczaj z wysokim rozumowaniem

Na czym polega: przy poleceniu, które tworzy aplikację od zera, Riley ustawia wysoki poziom rozumowania. Model zużywa więcej tokenów i lekko więcej kosztuje, ale przy złożonym zadaniu jakościowo się to opłaca.

Jak stosować: rozumowanie podnoś przy zadaniach architektonicznych (budowa od zera, przenoszenie danych do chmury), a obniżaj przy drobnych poprawkach.

Na co uważać: wysoki poziom wydłuża przebieg i rachunek; przy kosmetycznych zmianach to przepłacanie.

5.Prototyp na lokalnej bazie, chmura dopiero przy współdzieleniu

Na czym polega: pierwsza wersja aplikacji zapisuje dane w bazie wbudowanej w iPhone’a — działa, ale widzi je wyłącznie właściciel. Gdy pojawia się potrzeba udostępniania tablic, Riley jednym poleceniem przenosi wszystko do Convexa.

Jak stosować: na etapie pomysłu proś o lokalne przechowywanie; migracja do chmury jest na tyle prosta, że nie warto komplikować sobie prototypu od pierwszej minuty.

Na co uważać: jeśli od początku zakładasz plan zespołowy albo wersję webową, powiedz o tym agentowi wcześniej — dane lokalne i chmurowe różnią się zakresem tego, co trzeba potem przenieść.

6.Wtyczka Convex zdejmuje z agenta synchronizację i spójność danych

Na czym polega: zamiast kazać modelowi pisać synchronizację, cache i reguły spójności, Riley włącza oficjalną wtyczkę Convex do Claude Code. Agent dostaje gotową bazę działającą na żywo, funkcje zaplecza i miejsce na pliki; widzi też logi i strukturę projektu, więc gdy coś się posypie, sam odnajduje przyczynę. Dane mieszkają poza aplikacją — później można dorzucić wersję webową na tej samej bazie.

Jak stosować: konto na convex.dev zakładasz bezpłatnie, wtyczkę instalujesz w Claude Code (Dostosuj → Wtyczki), a potem wystarczy poprosić agenta o bazę w czasie rzeczywistym i linki do udostępniania.

Na co uważać: to segment sponsorski, więc entuzjazm autora traktuj z dystansem; sama migracja zajęła agentowi niemal godzinę.

7.Wklejone do czatu klucze API to prosta droga do wycieku

Na czym polega: Riley wkleja klucze do SerpApi i remove.bg wprost w rozmowie z Claude — sam przyznaje, że to niezalecana praktyka, choć dla wygody tak robi; na filmie starannie ukrywa ich wartości.

Jak stosować: w prototypie wystarczą tanie, osobne klucze „do zabawy”, które regularnie rotujesz; docelowo trzymaj sekrety w zmiennych środowiskowych, poza kodem i historią rozmów.

Na co uważać: przy publikacji repozytorium upewnij się, że klucze nie zostały w plikach ani w historii zmian — Riley wprost każe agentowi sprawdzić, czy nic poufnego nie wyciekło.

8.Godzinne przebiegi agenta to norma — odpal zadanie i odejdź

Na czym polega: budowa aplikacji trwała 37 minut, przejście na Convexa blisko godzinę. Riley uruchamia polecenie i idzie coś przekąsić; po powrocie zastaje agenta wciąż dopracowującego drobiazgi, o które nikt nie prosił.

Jak stosować: duże zadania uruchamiaj i zostawiaj sobie czas na przerwę; po powrocie metodycznie przetestuj każdą funkcję, a przy płatnych modelach ustaw limit wydatków.

Na co uważać: długi, samodzielny przebieg potrafi dokleić zmiany spoza zakresu polecenia — przed akceptacją przejrzyj, co dokładnie się zmieniło.

9.Iteruj listą zmian, nie serią pojedynczych poleceń

Na czym polega: zamiast dziesięciu osobnych próśb Riley spisuje jedną, numerowaną listę: odśwież stronę główną („wygląda tandetnie”), dodaj animację przeistaczania obrazu w naklejkę, wytnij zbędny slogan, zostaw jeden przycisk pełnego ekranu, zmień nazwę na Native Board i spraw, by wyszukiwarka podpowiadała już wygenerowane naklejki.

Jak stosować: po każdej sesji testów zbieraj wszystkie irytacje w jedno polecenie — agent utrzyma wtedy spójność zmian w całym interfejsie.

Na co uważać: zbyt ambitna lista zwiększa ryzyko, że coś pęknie; po każdym przebiegu testuj aplikację w całości, a nie tylko ostatnio zmieniony fragment.

10.Niech dane opisują się same w trakcie użycia

Na czym polega: Riley każe zapisywać każdą naklejkę pod frazą, którą wyszukano — naklejka „Sam Altman” nazywa się w bazie dokładnie „Sam Altman” — a pasek wyszukiwania filtruje bibliotekę na bieżąco, w miarę wpisywania liter. Efekt: często używane naklejki wracają na tablicę bez ponownego generowania, a katalog buduje się sam, bez ręcznego tagowania.

Jak stosować: projektując z agentem aplikację, zwróć uwagę na kontekst, który powstaje przy okazji korzystania z funkcji — często jest to najlepsza, darmowa etykieta danych.

Na co uważać: ta sama fraza może zwrócić różne obrazy, więc warto od razu ustalić, jak rozstrzygać powtarzające się nazwy.

Redakcyjne tłumaczenie

Nowy sprzęt Apple to zaproszenie dla twórców

Dziś zbudujemy z modelem Opus 5.5 aplikację na iOS-a — i to nie byle jaką, bo na iPhone’a Duo, świeżo zapowiedziany sprzęt Apple. Przy każdej premierze nowego urządzenia garstka ludzi pisze pierwsze naprawdę dobre aplikacje. Tym razem nie trzeba już umieć programować, żeby do tej garstki dołączyć — zwłaszcza że Anthropic wydało właśnie najlepszy na świecie model do kodowania, a przy tym przystępny cenowo. Zbuduję więc aplikację na iPhone’a Duo od zera, w aplikacji Claude, z Opusem 5.5 pod maską. I choćbyście w życiu nie napisali ani jednej linijki kodu, po tych czterech krokach będziecie mieć w rękach porządny program.

Krok 1: cztery rzeczy do przygotowania

Zanim cokolwiek powstanie, trzeba zgromadzić narzędzia: jedną rzecz sprzętową i trzy programy do pobrania na komputer.

Mac. Pracuję na MacBooku Pro z M4, ale spokojnie wystarczy każdy nowszy MacBook — od M1 wzwyż.

Aplikacja Claude na komputerze. W niej piszemy kod i budujemy całość. Znajdziesz ją bez trudu: wystarczy wpisać w Google „Claude desktop download” i pobrać wersję na macOS.

Xcode z symulatorem Duo. Testy będą się odbywać na symulatorze iPhone’a Duo. Pozwala on obracać urządzenie, rozkładać je i uruchamiać programy — wczoraj np. odpaliłem w nim klon aplikacji Muse (Informacja dodatkowa: Muse to narzędzie do tworzenia tablic z inspiracjami.). Do symulatora dochodzi się przez Xcode: pobierasz go z App Store’a na komputerze. To jednak nie wszystko — w aplikacji Claude przechodzisz do zakładki Claude Code i wklejasz polecenie:

„Upewnij się, że symulator działa. Chcę zbudować aplikację, uruchomić kod, a potem przetestować ją w symulatorze. Główny cel: aplikacja na iPhone’a Duo uruchomiona w symulatorze. Proszę o wersję 27.1 beta — to ona dodaje symulator Duo.”

Dokładnie tak konfigurowałem to u siebie. W skład symulatora wchodzi panel DeviceHub z listą urządzeń — obok iPhone’a 17 Pro znajdziesz tam Duo, ale wyłącznie przy wersji 27.1.

Convex — ale nie od razu. Czwarty element to baza danych; na start nie jest potrzebna. Przyda się, gdy zechcesz trzymać dane w chmurze — choćby po to, by w przyszłości dorobić wersję webową korzystającą z tej samej bazy.

To wszystko: Mac z aplikacją Claude, Claude Code i Xcode. Można zaczynać.

Krok 2: pomysł i prototyp

Skąd pomysł. Moja koncepcja wygląda na niszową, ale dajcie jej chwilę. Na Twitterze trafiłem na kogoś, kto po prawej stronie ekranu trzyma naklejki, a po lewej prowadzi mały dziennik. Do tego mam na komputerze aplikację, która wyszukuje w internecie dowolne obrazy: gdy potrzebuję grafiki iPhone’a Duo, znajduję ją w sekundę, jednym kliknięciem usuwam tło, kopiuję i wklejam do Excalidraw (Informacja dodatkowa: Excalidraw to popularne, działające w przeglądarce narzędzie do szkicowania diagramów i notatek w stylu odręcznym.).

Chcę więc jeden program, który połączy te światy: po prawej generator naklejek i obrazów, po lewej tablica à la Excalidraw; każdą stronę da się powiększyć na pełny ekran i przechodzić między nimi. Naklejką ma móc stać się każdy — wpisuję „Sam Altman”, dostaję jego naklejkę, przeciągam na tablicę, dopisuję kontekst i powstaje plansza, która tłumaczy pomysły lepiej niż goły tekst.

Środowisko robocze. Nie używamy zwykłego czatu, tylko Claude Code. Klikamy zakładkę, wciskamy Cmd+N i przed nami główne okno. Zawsze zaczynam od utworzenia nowego folderu na projekt — ten wyląduje w Dokumentach.

Zdanie kontrolne. Pierwsze polecenie w nowym projekcie brzmi: „Zaraz zbudujemy aplikację na iPhone’a Duo w Swiftcie. Na początek zrób podstawową aplikację Hello World: zbuduj ją i uruchom w symulatorze. Właściwa aplikacja przyjdzie zaraz po niej — teraz chcę tylko spiąć całość i upewnić się, że działa.” Swift to natywny język iOS-a; w tej chwili nie tworzymy nic konkretnego, tylko sprawdzamy, czy połączenie między kodem a symulatrem działa. Chwila i gotowe.

Hello World rusza na symulatorze iPhone’a, więc przełączam urządzenie na Duo — i patrzcie: najprostsza z możliwych aplikacji działa na symulatorze nowego telefonu.

Właściwy prompt. Czas na pierwsze polecenie budujące docelową aplikację:

„Zbuduj aplikację przeznaczoną na iPhone’a Duo. Wyszukaj w internecie i ustal, jak projektuje się najlepsze aplikacje pod nowego Duo. Musi dobrze wyglądać w układzie poziomym. To narzędzie do tworzenia ciekawych dokumentów z naklejkami i prawdziwymi zdjęciami; prawa strona ma opierać się na naklejkach.”

Do polecenia dołączam dwa obrazy: zrzut z Twittera i grafikę przed chwilą wygenerowaną przez AI. Pracujemy na Opusie 5.5, a pierwsze zapytanie budujące puszczam z rozumowaniem ustawionym na „wysokie” (Informacja dodatkowa: wyższy poziom rozumowania oznacza, że model poświęca więcej czasu i obliczeń na przemyślenie zadania — wychodzi wolniej i drożej, ale zwykle staranniej.). Zużyje nieco więcej tokenów i lekko podniesie koszt, ale przy tym modelu wciąż zostaje tanio.

Dopisuję jeszcze: „wszystko ma być starannie zapisywane w lokalnej bazie danych”. Convex dołożymy później — na razie prototyp korzysta z bazy wbudowanej w iPhone’a. Każda aplikacja na iOS-a może mieć taką lokalną bazę; problem w tym, że jeśli zechcesz kiedyś zrobić plan zespołowy, nikt poza tobą tych danych nie zobaczy. Dlatego później przeniesiemy ją do chmury — ale prototyp ma startować prosto.

Klucze do wyszukiwania obrazów. Skoro aplikacja ma wyszukiwać grafiki w internecie, potrzebny jest interfejs API. Wykorzystuję SerpApi (Informacja dodatkowa: SerpApi to komercyjna usługa udostępniająca wyniki wyszukiwania Google, w tym obrazy, przez interfejs programistyczny.); zakładam konto i pobieram klucz. Do wycinania tła służy remove.bg — płacę za nie, jeśli dobrze pamiętam, 5–10 dolarów miesięcznie za nieograniczoną liczbę obrazów — i stamtąd też biorę klucz.

Wracam do Claude’a: „Do wyszukiwania i usuwania tła obrazów używamy SerpApi i remove.bg; klucze wklejam poniżej.” Nie jest to zalecana praktyka — i mimo to tak robię. Samych kluczy nie pokazuję na filmie, żeby nie trafiły w niepowołane ręce.

Efekt. Będę szczery: to trwało wieczność, jakieś 37 minut. Ale spójrzcie — na urządzeniu działa aplikacja-wklejanka (scrapbook), zamknięta i rozłożona. Tworzę nowy dokument, zaznaczam pole, wpisuję „Claude 5.5” — czcionka ta sama co w systemie. Podwójne tapnięcie dodaje kolejny tekst: „Claude Opus 5.5”. Da się go przesuwać po ekranie. Teraz wyszukiwanie: wpisuję „Dario Amodei”, klikam i… zamieniam w naklejkę. Całą tę aplikację stworzył jeden prompt. Naklejkę powiększam na cały ekran — wygląda naprawdę dobrze. To samo z logo Claude: naklejka, otwieram tablicę, wciągam. Jeden strzał, 37 minut czekania — i mamy program na iPhone’a Duo.

Sekcja sponsorska: Convex

Poniższy fragment to płatna współpraca.

Każda porządna aplikacja potrzebuje miejsca, w którym przechowa dane i utrzyma je w spójności dla wszystkich użytkowników. W moich projektach tą rolę pełni Convex — zaplecze zaprojektowane pod to, jak dziś powstaje oprogramowanie: rękami agentów AI. Oficjalna wtyczka Convex do Claude Code instaluje się raz, a potem za każdym razem, gdy prosisz Claude’a o nową funkcję, agent może postawić prawdziwą bazę, funkcje backendowe i magazyn na pliki. Całość działa na żywo: gdy dane się zmienią, każdy ekran od razu się aktualizuje — bez odświeżania i bez pisania dodatkowego kodu. Normalnie agent musiałby sam budować synchronizację, cache i reguły spójności; w Convexie to już jest zrobione, więc model skupia się na samej aplikacji. Wtyczka daje mu też podgląd na strukturę projektu, logi i funkcje zaplecza — gdy coś się posypie, widzi przyczynę i ją naprawia. A ponieważ dane mieszkają w Convexie, a nie w środku jednej aplikacji, dziś możesz zacząć od iPhone’a, a później dorzucić wersję webową albo desktopową, korzystające z tej samej bazy. Konto zakładasz bezpłatnie — link jest w opisie filmu.

Krok 3: przenosimy dane do chmury i dodajemy udostępnianie

Wracamy do aplikacji. Baza, o którą teraz doprosimy agenta, ma działać w czasie rzeczywistym — jeśli w ramach konta zespołowego ktoś przesunie coś na tablicy, pozostali zobaczą to natychmiast. Convex aktualizuje dane błyskawicznie.

Ustawienie jest krótkie. Na convex.dev zakładasz konto. Następnie w aplikacji Claude: Claude Code → Dostosuj → Wtyczki, gdzie odszukujesz pozycję „Convex by Convex” i klikasz instalację. I polecenie, które dyktuję na głos:

„Hej, Claude Code, zamień to na bazę czasu rzeczywistego — później dodamy plan zespołowy. Wszystkie dane mają zapisywać się na bieżąco i działać bezbłędnie. Chcę też udostępniać tablice: wysyłam komuś link, a ten ktoś ogląda moje plansze wraz z obrazami — u znajomego i na telefonie. Zbuduj bazę w Convexie tak, jak uważasz za najlepsze; zrób to perfekcyjnie, a aplikacja będzie kapitalna.”

Odpalam i idę coś przekąsić. Wracam i nie mogę uwierzyć: agent siedzi nad tym już 57 minut i wciąż pracuje. Daję mu znak, żeby kończył. Po drodze naprawia drobiazgi, o które wcale nie prosiłem — ale działa.

Gdy w końcu cichnie, sprawdzam wyniki. Nowy dokument tworzy się jak wcześniej; mogę przypiąć napis „nowe funkcje OpenAI”, podwójnie tapnąć, wpisać „Codex”, wyszukać jego logo, zamienić w naklejkę i przeciągnąć prosto na tablicę. Dobra robota. Logo ChatGPT — od razu naklejka. Sam Altman — naklejka.

Najlepsze zaczyna się teraz, po podpięciu Convexa: mogę wygenerować link udostępniania. Kopiuję go i wysyłam znajomemu. Symulator nie ma żadnych kontaktów, ale na moim prawdziwym Duo zobaczyłbym tu ostatnie wiadomości tekstowe. Wklejam za to link do Chrome — dostaję stronę na domenie Convexa i wszystko działa: tablica, grafiki, naklejki. Aktualizacje widać na żywo: na telefonie dopisuję „ChatGPT”, klikam obok i napis pojawia się w przeglądarce. Wyszukuję „GPT image 2” i nim zdążę mrugnąć, naklejka jest już po drugiej stronie. Podgląd jest tylko do odczytu — dokładnie tak, jak chciałem. Tablicami można się dzielić.

Krok 4: testy i szlify

Ostatni etap: testować, poprawiać, doprowadzać do ideału. Otwieram symulator z aplikacją — i szczerze przyznaję, że wygląd mnie nie zachwyca. W Claude Code piszę listę poprawek:

  1. Ulepsz znacznie stronę główną. Bądź kreatywny — obecna wygląda tanio i blado; ogólnie zadbaj o front-end.
  2. Gdy zaznaczam postać albo obraz do zamiany na naklejkę, po prawej stronie ekranu ma odgrywać się animacja: obraz sprzed przekształcenia płynnie przechodzi w formę naklejki. Fajny detal.
  3. Usuń tekst na górze ekranu — „Little things, very you”. Nie znoszę go.
  4. U góry jest za dużo przycisków. Ogranicz je — prawdopodobnie wystarczy sam pełny ekran — i upakuj jakoś ciaśniej.
  5. Zmień nazwę aplikacji na Native Board.
  6. W polu wyszukiwania, w trakcie wpisywania, mają pokazywać się nazwy naklejek — a nazwą naklejki jest fraza, której użyto przy jej wyszukiwaniu. Naklejka „Sam Altman” zapisuje się w bazie właśnie jako „Sam Altman”. W miarę pisania biblioteka filtruje się na żywo: wpisuję „Sam” i mogę wcisnąć Enter, by wygenerować nową, albo jednym ruchem przerzucić na tablicę którąś z już istniejących — bez odtwarzania w kółko tych samych grafik. Po prostu przeszukuję własne naklejki.

Kilka dużych zmian naraz — wysyłam i myślę, że po tym będziemy gotowi. Szczerze? Nie wiem, co jeszcze można by tu dodać.

Gdy agent kończy — proszę. Zakładamy nową tablicę, naklejki są na miejscu, u góry mniej zakładek, o to dokładnie chodziło. Pełny ekran działa. Wpisuję „Sam” — naklejka wyskakuje. Dopisuję napis „jak działają LLM-y”, szukam Satyi Nadelli (nie pytajcie, czemu akurat jego) — jest. Czekaj, przecież dodałem animację: zaznaczam, zamieniam w naklejkę i… proszę, obraz przechodzi w formę naklejki. Ładne. Kolejna plansza: „nowe funkcje Copilota”; wpisuję „Copilot”. I zauważcie: gdy stukam „co”, wyskakują „ChatGPT”, „Claude” i „Codex” — aplikacja nie tylko przeszukuje grafiki Google, ale też przegląda to, co już wygenerowałem. Dopisuję „Microsoft AI”, tworzę link udostępniania, wklejam w przeglądarkę — działa na żywo. Dorzucam kolejnego Satyę i zmiana pojawia się od razu, bo pod spodem pracuje Convex. Rewelacja. A gdy złożę telefon i obrócą, aplikacja równie dobrze znosi układ pionowy. I tak powstaje program na iPhone’a Duo.

Na koniec: kod jako open source

Całość udostępniam publicznie. Polecenie: „Załóż nowe publiczne repozytorium. Dopilnuj, by w trakcie nie wyciekła żadna informacja poufna. Repo ma być publiczne, nosić nazwę native-board i znaleźć się na GitHubie Riley’a Browna. Dołącz instrukcję konfiguracji wszystkiego od zera — załóż, że użytkownik nie ma nawet Xcode — tak, żeby przy odrobinie pomocy Claude’a bez trudu postawił projekt u siebie.” Zanim obejrzycie ten materiał, kod będzie już dostępny na GitHubie.

Pięć promptów i gotowe

Co złożyło się na całość? Model Opus 5.5 — szczerze wierzę, że to dziś najlepszy model, zarówno do front-endu, jak i back-endu. Symulator Xcode, dzięki któremu możemy urządzenie obracać i składać. SerpApi do wyszukiwania grafik oraz remove.bg do wycinania tła — a pomysł z białą obwódką dookoła naklejki wymyślił sobie sam Opus. Convex zapewnił funkcję udostępniania i przechowuje dane w bazie działającej na żywo. Na koniec kilka rund testów i poprawek. Łącznie pięć promptów — a potem publikacja jako open source. Link do GitHuba znajdziecie w opisie; klonujcie śmiało.

Dzięki za obejrzenie. Dajcie znać, co mam zbudować, gdy dotrze do mnie fizyczny iPhone Duo — powinno to zająć jakieś trzy tygodnie — bo chcę wziąć się za kolejne eksperymenty.