Materiały źródłowe do tej serii:
1. Nowa aplikacja: https://aleksanderfigiel.pl/ios-new-app-tutorial-1
2. TestFlight: https://aleksanderfigiel.pl/ios-testflight-tutorial-2
3. Instalacja przez kabel: https://aleksanderfigiel.pl/ios-macos-cable-tutorial-3

Przed rozpoczęciem otwórz i przeczytaj stronę części, której dotyczy ten prompt. Korzystaj z jej instrukcji, ilustracji i kodu. Pozostałe części traktuj jako kontekst i sięgaj do nich, gdy wymaga tego bieżący krok. Zachowaj zakres tej części i prowadź mnie po jednym kroku. Jeśli nie masz dostępu do strony lub nie została jeszcze opublikowana, powiedz o tym i poproś o jej treść albo pliki; nie udawaj, że ją przeczytałeś.


Poprowadź mnie po polsku przez tutorial 3: budowanie aplikacji iOS w GitHub Actions i instalację na iPhonie przez kabel z Maca. Pracuj po jednym małym kroku na wiadomość, czekaj na moje potwierdzenie. Nie wymagaj screenshotów, jeśli opis lub wynik polecenia wystarcza. Nie proś o hasła, tokeny, zawartość certyfikatów ani sekrety.
Najpierw sprawdź, czy mam Maca, iPhone'a, Apple Developer Program, App ID i repozytorium z aplikacją. Korzystaj z mojego OWNER/REPO, Bundle ID i nazw projektu, nigdy z przykładów jako moich danych.
CSR nie jest certyfikatem. Jeśli mam CSR z TestFlight i odpowiadający klucz prywatny, użyj go do wystawienia Apple Development. Apple Distribution nie zastępuje Apple Development. Jeśli mam już ważny Apple Development z kluczem, pomiń wystawianie. W przeciwnym razie przejdź przez CSR, wystawienie i import development.cer oraz eksport DevelopmentCertificate.p12 z hasłem.
Dodaj trzy Repository secrets: DEVICE_CERTIFICATE_P12_BASE64, DEVICE_CERTIFICATE_PASSWORD, DEVICE_PROVISIONING_PROFILE_BASE64. Hasło jest surowym tekstem, pliki są kodowane Base64. Profil APP_STORE_PROVISIONING_PROFILE_BASE64 zostaje dla TestFlight i nie może być użyty jako profil Development.
Pokaż początkującemu USB, zaufanie do Maca i Finder. UDID pojawia się po kliknięciu wiersza informacji bezpośrednio pod nazwą iPhone'a (model / pojemność / bateria), nie samej nazwy. Nie myl UDID z EID. Nie każ wyłączać ani rejestrować ponownie istniejącego urządzenia. Użytkownik sam sprawdza swój UDID, nie musi publikować go w czacie.
Przejdź przez profil iOS App Development: istniejący App ID zgodny z kodem, offline No, właściwy Apple Development, rzeczywiste urządzenie, Generate i Download. Nowy profil zakoduj do właściwego sekretu. Sprawdź APPLE_TEAM_ID i XCODE_PROJECT w Variables, wykorzystaj istniejące poprawne wartości.
Użyj dołączonych device-build.yml i install-latest-device-build.sh. Workflow wymaga XcodeGen project.yml, zgodnej nazwy projektu/schematu/produktu .app oraz jednego celu. Dostosuj do rzeczywistego repozytorium, jeśli się różni. Nie deklaruj kompatybilności bez sprawdzenia. Nie zmieniaj samowolnie Bundle ID ani TestFlight. Nie dodawaj tagu [testflight] do commita dotyczącego tylko kabla.
Sprawdź gh i devicectl; jeśli devicectl jest dostępne, nie wymagaj ios-deploy. Bez niego użyj ios-deploy. Homebrew instaluj tylko jeśli jest potrzebne; podaj komendę z brew.sh i przypomnij Next steps. GitHub CLI ma też oficjalne wydania bez Homebrew. Sprawdź gh auth status i w razie potrzeby gh auth login, potem połączenie USB i Tryb dewelopera. Samo wykrycie urządzenia nie oznacza, że instalacja działa.
Po buildzie przeprowadź przez pobranie skryptu, chmod +x i instalację. Dla devicectl ustaw DEVICE_ID. Bez SHA skrypt wybiera najnowsze uruchomienie z niewygasłym artefaktem na domyślnej gałęzi, niekoniecznie ostatni commit. Z SHA bierze artefakt uruchomienia workflow o tym head_sha, bez fallbacku na inny commit. DEVICE_BRANCH działa tylko bez SHA. Sprawdź oba warianty, jeśli użytkownik chce pełną weryfikację. Nie twierdź, że testowałeś na jego sprzęcie bez jego potwierdzenia.
Wyjaśnij zastępowanie wersji TestFlight i kabla przy zgodnym Bundle ID/podpisie, możliwą animację ikony i sprawdzenie wyniku w Terminalu. Opcjonalna czysta instalacja przez usunięcie aplikacji usuwa lokalne dane. Kabel pomija App Store Connect Processing, TestFlight działa bez kabla i Maca przy skonfigurowanym cloud build. Nie podawaj 30 buildów dziennie jako zweryfikowanego limitu bez oficjalnego źródła.
W przypadku błędu zajmij się konkretnym komunikatem. Nie omijaj zaufania certyfikatu przez Always Trust. Korzystaj z oficjalnej dokumentacji i faktycznego stanu użytkownika. Nie używaj znaku em dash. Zakończ po potwierdzonej instalacji aplikacji; nie publikuj jej w App Store.