Технічна підтримка VR-додатків після запуску
Після публікації VR-додатку в Meta Horizon Store або Steam робота не закінчується—змінюється її характер. Замість розробки нових функцій починається реакція на те, що сломалося у реальних користувачів з реальним обладнанням. VR-специфіка особливо жорстока: оновлення платформ (Horizon OS, SteamVR) ломають роботу додатків без попередження, і у вас нема тижнів на реакцію.
Що ломається після оновлення платформ
Meta регулярно оновлює Horizon OS—у 2024 році вийшло понад десять значимих оновлень. Кожне може сломати щось в робочому додатку. Типові проблеми: зміна поведінки OVRCameraRig при оновленні Oculus Integration SDK (старі версії перестають правильно трекати позицію, якщо проект не оновлений до сумісної версії). Або зміна в passthrough compositor, після якої MR-додатки показують розбіжні шари.
SteamVR поводить себе аналогічно. Після оновлень OpenVR API періодично змінюються сигнатури event callbacks—EVREventType.VREvent_InputFocusChanged перестає приходити, додаток втрачає фокус без коректної обробки. Користувачі бачать завислий контролер в сцені.
Системні оновлення iOS та Android також впливають на ARKit/ARCore додатки: змінюються дозволи камери, ARCore на деяких прошивках Android 14 потребує повторної авторизації ARCore Services.
Як організована підтримка
Моніторинг помилок—через вбудовані в релізну збірку системи crash reporting. Для Unity-проектів використовуємо Firebase Crashlytics або Sentry Unity SDK, налаштовані з symbolication для native стеків. Без symbolication стек крешу для IL2CPP-збірки виглядає як набір hex-адрес—безкорисно. З symbolication—повний C# стек викликів, включаючи рядки кода.
Для Meta Quest додатково—Meta Developer Hub з ADB logcat у режимі моніторингу. Quest-специфічні краші з кодами SIGABRT або SIGSEGV у native шарі Oculus runtime потребують окремого розбору через NDK stack unwinder.
Класифікація інцидентів за пріоритетом: P1—краш при старті або на критичному пути (>5% сесій затронуто), P2—деградація функціональності без повного краша, P3—візуальні артефакти або edge-case збої. Для P1—реакція та hotfix протягом 24–48 годин.
Оновлення сумісності з новими версіями SDK
Звичайна задача в post-launch підтримці—оновлення залежностей. Oculus Integration SDK, XR Interaction Toolkit, AR Foundation мають release notes з breaking changes. Типовий цикл: нова версія SDK вийшла → локальний тест на staging збірці → перевірка критичних шляхів → публікація оновлення.
Важливо не оновлюватися на мажорні версії негайно після виходу. XR Interaction Toolkit 3.x мав кілька регресій у перших релізах відносно 2.x—додатки, які оновились одразу, отримали broken grab interactions. Очікування 2–4 тижнів після мажорного релізу та моніторинг community issues—частина процесу.
Робота з відзивами та краш-репортами користувачів
Відзиви в Store містять сигнали про технічні проблеми, які не потрапляють до автоматичного crash reporting—«у мене слітає трекинг при яскравому світлі», «після оновлення не запускається на Quest 2». Систематизація відзивів та кореляція з даними Crashlytics дозволяє пріоритизувати виправлення.
Для Steam-додатків—моніторинг Steam Discussions, Steam Workshop (якщо використовується) та Steam Reviews. Community-reported bugs часто містять конкретну конфігурацію обладнання, яка відтворює проблему: конкретний GPU + headset + версія driver.
| Рівень підтримки | Що включає |
|---|---|
| Реактивна (за запитом) | Виправлення критичних багів при зверненні |
| Регулярна (щомісячно) | Моніторинг краш-репортів, оновлення SDK-сумісності |
| Повна супровід | Пріоритетна реакція, регулярні оновлення, аналітика |
Вартість визначається після обговорення обсягу додатку, платформ та необхідного SLA.