Jak budować aplikacje iOS w SwiftUI z OpenAI Codex: kompletny przewodnik

Codex zakłada projekt iOS, pisze widoki SwiftUI, kompiluje go poleceniem xcodebuild i poprawia kod, dopóki build nie przejdzie. Tak opisuje tę pracę dokumentacja OpenAI dla platform Apple: agent zostaje w terminalu i nie wchodzi do graficznego Xcode. Twoja rola przesuwa się z klikania w edytorze na wyznaczenie celu i ocenę tego, co z tego wyszło.

Jak Codex pracuje w projekcie iOS w SwiftUI

Klasyczna praca w Xcode wygląda tak: piszesz kod, klikasz Build, czytasz czerwone błędy, wracasz do edytora i powtarzasz. Agentowy workflow zamyka ten obieg w programie. Opisujesz cel, Codex pisze kod, sam uruchamia kompilację, sam czyta komunikat kompilatora i sam poprawia. Zatrzymuje się dopiero wtedy, gdy projekt się buduje albo gdy trafi na coś, czego nie umie rozwiązać bez Ciebie.

Ten wzorzec nie powstał dla iOS. To ta sama mechanika, którą opisaliśmy przy loop engineeringu: system podaje agentowi twardy test, a agent krąży w pętli, aż test przejdzie. W projekcie iOS testem jest kompilator Swifta i symulator iPhone'a, więc sygnał zwrotny jest wyjątkowo jednoznaczny. Kod albo się buduje, albo nie.

Cztery kroki, które agent wykonuje sam

1. Szkielet projektu. Dokumentacja OpenAI dla platform Apple radzi zacząć od prośby o startową aplikację iOS w SwiftUI wraz z małym skryptem, który buduje i uruchamia projekt.
2. Widoki SwiftUI. OpenAI opisuje SwiftUI jako najszybszy sposób prototypowania widoków, nawigacji i wspólnego stanu na iPhone'a oraz iPada, przy zachowaniu czytelnego kodu interfejsu.
3. Pętla xcodebuild. Agent kompiluje z linii poleceń i od razu czyta wynik, zamiast czekać, aż klikniesz przycisk w oknie Xcode.
4. Zrzut z symulatora. Agent ogląda, co faktycznie wyrenderowało się na ekranie, i koryguje układ.

Dlaczego kompilacja z linii poleceń jest tu warunkiem

Dokumentacja Codeksa jest w tym punkcie konkretna: xcodebuild potrafi wylistować schematy oraz obsłużyć build, test, archive, build-for-testing i test-without-building prosto z terminala, dzięki czemu agent zostaje w swojej pętli, zamiast odbijać się do graficznego Xcode. To nie jest kosmetyka. Agent, który nie ma jak uruchomić kompilacji, produkuje kod wyglądający poprawnie i niedziałający.

Swift jest tu sojusznikiem. Typy, opcjonalne wartości i sprawdzanie zgodności protokołów sprawiają, że pomyłki agenta mają szansę wyjść już przy kompilacji, a nie dopiero na telefonie testera. Kompilator zwraca konkretny plik, numer linii i powód. To materiał, z którego model potrafi zrobić poprawkę bez zgadywania.

Zrzuty z symulatora, czyli jak agent widzi swoją pracę

Kompilujący się kod potrafi wyrenderować przycisk poza ekranem albo tekst schowany pod paskiem systemowym. Kompilator tego nie wyłapie, bo składniowo wszystko jest w porządku. Dlatego do pętli dokłada się obraz.

OpenAI kieruje w tym miejscu do serwera MCP o nazwie XcodeBuildMCP i wskazuje moment, w którym warto go włączyć: gdy schematy, targety, sterowanie symulatorem, zrzuty ekranu, logi i interakcja z interfejsem zaczynają mieć znaczenie, a same polecenia powłoki przestają wystarczać. Sam serwer jest projektem open source, a jego repozytorium prowadzi dziś Sentry, pod adresem getsentry/XcodeBuildMCP. Praktyczny wniosek dla mniejszego projektu jest prosty: zacznij od czystego terminala, a serwer MCP dołóż dopiero wtedy, gdy agent zaczyna zgadywać wygląd ekranu.

Liquid Glass, czyli skąd bierze się wygląd aplikacji

Liquid Glass to materiał interfejsu, który Apple pokazało na WWDC 2025 w sesji o budowaniu aplikacji SwiftUI w nowym wyglądzie. Apple opisuje go jako adaptacyjny materiał kontrolek i elementów nawigacji, inspirowany właściwościami optycznymi szkła i płynnością cieczy, dostosowujący się do treści przewijanej pod spodem. Nowy wygląd wchodzi wraz z iOS 26 i macOS Tahoe, a projekt trzeba zbudować na SDK z Xcode 26.

Dla agenta to wygodna sytuacja, bo mówimy o nazwanych modyfikatorach z dokumentacji SwiftUI: glassEffect() nakłada efekt na widok, GlassEffectContainer łączy kilka takich widoków, żeby ich kształty zlewały się i przechodziły jeden w drugi, a glassEffectID() spina przejścia między nimi. Agent umie to poprawnie wstawić. Decyzja, gdzie efekt pomaga, a gdzie psuje czytelność, zostaje po Twojej stronie.

Uprawnienia, czyli co Codex może zrobić na Twoim komputerze

Agent, który sam uruchamia polecenia, potrzebuje granic. Codex ma trzy tryby piaskownicy: read-only bez prawa zmiany plików, workspace-write z prawem edycji i uruchamiania poleceń w obrębie katalogu roboczego oraz danger-full-access bez piaskownicy, którego dokumentacja odradza. Do tego dochodzą polityki zatwierdzania: on-request, never i untrusted.

Dostęp do sieci jest domyślnie wyłączony, a dokumentacja OpenAI wprost ostrzega, że jego włączenie otwiera drogę do wstrzyknięcia instrukcji: agent może pobrać i wykonać polecenia z niezaufanego źródła. To ta sama klasa ryzyka, którą opisywaliśmy przy agentjackingu. Dla zwykłego projektu iOS rozsądny układ domyślny to workspace-write plus zatwierdzanie na żądanie.

Druga strona medalu

Dokumentacja opisuje ten sposób pracy głównie na nowych projektach i mniejszych zadaniach. Nie wiemy, jak zachowa się w kilkuletnim projekcie z setkami plików, własnym systemem budowania i zależnościami z kilku źródeł. Dopóki ktoś tego nie zmierzy na projekcie podobnym do Twojego, relacje o aplikacji zbudowanej w jeden wieczór traktowałbym jako pojedyncze przypadki, a nie normę.

Przechodząca kompilacja nie oznacza też poprawnej aplikacji. Build mówi tylko tyle, że kod jest składniowo i typowo w porządku. Czy ekran liczy właściwą cenę i czy formularz zapisuje dane tam, gdzie trzeba, sprawdzisz testami i własną ręką. Zostaje wreszcie część, której agent nie przejdzie za Ciebie: konto Apple Developer, podpisywanie aplikacji i recenzja w App Store. Bywa dłuższa niż samo pisanie kodu. Podobne wnioski wyciągał szef produktu Codeksa, o czym pisaliśmy w 10 wnioskach z jego wystąpienia.

Co z tego ma właściciel małej firmy

Najbardziej praktyczna zmiana dotyczy nie programowania, tylko rozmowy z wykonawcą. Zamiast opisywać pomysł na aplikację w mailu, możesz zbudować działający prototyp i pokazać go zamiast briefu. Wycena robi się konkretniejsza, a nieporozumień jest mniej. Jeśli dopiero szukasz sensownego zastosowania, zacznij od listy pomysłów na aplikacje AI na iPhone i wybierz ten, który rozwiązuje realny problem w Twojej firmie.

Prototyp nie jest jednak produktem. Utrzymanie, aktualizacje po każdym większym wydaniu iOS, obsługa zgłoszeń i zgodność z RODO to praca, którą ktoś i tak musi wziąć na siebie. Zanim zdecydujesz, komu ją zlecić, porównaj koszty i ryzyka w zestawieniu freelancer AI kontra firma wdrożeniowa.

Ścieżka na start jest krótka: zainstaluj Xcode 26 na Macu, dodaj Codex CLI, ustaw tryb workspace-write, poproś agenta o szkielet aplikacji razem ze skryptem budującym, a potem każde zadanie kończ poleceniem kompilacji. Serwer MCP ze zrzutami ekranu dołóż dopiero wtedy, gdy zaczniesz pracować nad wyglądem.

Najczęstsze pytania

Czy Codex zbuduje całą aplikację iOS?

Tak, od scaffoldu projektu, przez widoki SwiftUI, po kompilację w pętli, zrzuty z symulatora i styl Liquid Glass, bez ręcznej pracy w graficznym Xcode.

Dlaczego ważna jest pętla xcodebuild?

Bo kompilacja z linii poleceń daje agentowi twardy sygnał zwrotny. Czyta błędy i poprawia kod, aż projekt faktycznie się buduje i działa.

Po co agentowi zrzuty z symulatora?

Żeby „zobaczyć" efekt swojej pracy i skorygować układ interfejsu, zamiast działać w ciemno.

Czy nadal potrzebuję wiedzy o iOS?

Do decyzji produktowych i oceny rezultatu tak. Agent wykonuje pracę, ale to Ty wyznaczasz cel i sprawdzasz, czy aplikacja robi to, co trzeba.

Źródła: OpenAI, Codex: Build for iOS (scaffold aplikacji SwiftUI, pętla xcodebuild, XcodeBuildMCP), OpenAI, Codex: zatwierdzenia i bezpieczeństwo (tryby piaskownicy, dostęp do sieci), Sentry, repozytorium XcodeBuildMCP (opiekun projektu), Apple, Build a SwiftUI app with the new design, WWDC 2025 (Liquid Glass, iOS 26, Xcode 26), Apple, Applying Liquid Glass to custom views (glassEffect, GlassEffectContainer, glassEffectID).