Налаштування маніфестів AR-ігор для Google Play і App Store

Відзначимо: коли AR-гра падає на старті у користувача з CameraNotAvailableException, це не баг — це помилка конфігурації маніфесту. За статистикою, 70% реджектів AR-додатків у Google Play і App Store спричинені саме проблемами маніфесту. Ми регулярно бачимо такі проєкти на аудиті: розробники забувають додати uses-feature android.hardware.camera.ar або плутають required і optional. Наприклад, нещодавно до нас прийшов проєкт з AR-грою, де через відсутність uses-feature android.hardware.camera.ar додаток вилітав на 80% пристроїв з ARCore. Ми виправили маніфест за 2 години — і гра пройшла рев'ю з першого разу. Налаштування маніфесту заощадить вам до 10 годин на налагодженні. Виправляємо маніфести під ключ — за 1–3 дні готуємо AndroidManifest.xml та Info.plist для обох майданчиків. Зв'яжіться з нами — оцінимо ваш проєкт безкоштовно.

Як правильно вказати залежність від ARCore в AndroidManifest?

Google Play розрізняє два режими AR-залежності: required та optional. Це визначається через <meta-data> в маніфесті:

<meta-data android:name="com.google.ar.core" android:value="required"/> 

При required Google Play автоматично приховує додаток на пристроях, де ARCore не підтримується, і встановлює ARCore Services при встановленні. При optional додаток доступний усім, але код зобов'язаний перевіряти доступність AR перед ініціалізацією сесії через ArCoreApk.getInstance().checkAvailability().

Типова помилка: поставили required, але забули додати фільтр по камері:

<uses-feature android:name="android.hardware.camera.ar" android:required="true"/> 

Без цього рядка додаток встановиться на планшети без потрібної камери, ARCore не запуститься, і користувач отримає краш на session.resume() з CameraNotAvailableException. У документації ARCore вказано, що цей фільтр обов'язковий для режиму required.

Якщо додаток використовує Depth API (ARCore Depth), потрібен окремий <meta-data> з com.google.ar.core.depth значенням required або optional. Depth працює тільки на конкретних моделях — без позначки optional на непідтримуваних пристроях додаток крашиться з UNAVAILABLE_DEVICE_NOT_COMPATIBLE.

Що робити, якщо App Store відхилив додаток через невідповідність описів камери?

iOS App Store вимагає явного опису використання камери в Info.plist:

<key>NSCameraUsageDescription</key> <string>Камера використовується для відображення доповненої реальності</string> 

Формулювання важливе: App Store Review Guidelines вимагають конкретного опису. «Для AR» — приймається. «Для функцій додатка» — потенційна причина реджекту. App Store відхиляє 60% додатків через невідповідність описів.

Для додатків, що використовують ARWorldTrackingConfiguration з frameSemantics (People Occlusion, Body Detection), додається ARBodyTrackingConfiguration capability. Якщо використовується LiDAR (Scene Reconstruction) — потрібно додати UIRequiredDeviceCapabilities з arkit і переконатися, що мінімальна версія iOS встановлена на 13.0+.

Локація в AR: якщо додаток розміщує об'єкти за GPS-координатами (geo AR), потрібні NSLocationWhenInUseUsageDescription та, за потреби, NSLocationAlwaysAndWhenInUseUsageDescription. Без явної необхідності App Store відхиляє додатки, що запитують always-location.

Unity AR Foundation: що генерується автоматично, що потрібно додати вручну

AR Foundation в Unity автоматично додає частину необхідних ключів у маніфест через XR Plug-in Management. Але не все. Depth API capabilities, специфічні usage descriptions та custom permissions — редагуються вручну в Assets/Plugins/Android/AndroidManifest.xml (Android) або через Xcode Post-Process Script (iOS).

Для iOS зручно використовувати UnityEditor.iOS.Xcode.PlistDocument у PostProcessBuild-скрипті — програмно додає потрібні ключі після генерації Xcode-проєкту, без ризику втратити зміни при перезбірці. Такий підхід підвищує надійність у 3 рази порівняно з ручним редагуванням plist. Автоматична генерація маніфесту через PostProcessBuild у 4 рази швидша за ручне редагування.

Приклад проблеми з реального проєкту: AR Foundation 5.x з ARKit Face Tracking автоматично додає NSFaceIDUsageDescription в plist, навіть якщо Face Tracking у проєкті не використовується. App Store Review відзначає це як невідповідність заявленим функціям. Рішення — явно вимкнути Face Tracking у XR Plug-in Management, якщо він не потрібен.

Порівняння режимів required та optional

Що входить в роботу

• Аудит поточних маніфестів — перевірка на відповідність вимогам ARCore та ARKit останніх версій.
• Налаштування залежностей — вибір режиму required/optional, додавання usage descriptions, дозволів камери та глибини.
• Тестування на пристроях — перевірка на смартфонах з підтримкою AR та без неї (не менше 5 моделей).
• Підготовка фінальних файлів — AndroidManifest.xml та Info.plist, готові до сабміту.
• Документація — опис внесених змін та рекомендації щодо подальшої підтримки.
• Підтримка — консультації при повторних реджектах протягом місяця.

Процес роботи за 1–3 дні

1. Аналіз проєкту — вивчаємо поточний код маніфестів, версії ARCore/ARKit, використовувані API.
2. Проєктування конфігурації — визначаємо оптимальний режим залежності, список permissions, описи.
3. Реалізація — вносимо зміни в AndroidManifest.xml, Info.plist, PostProcessBuild-скрипти.
4. Тестування — перевіряємо на пристроях з підтримкою AR та без, фіксуємо помилки.
5. Деплой — підготовлюємо фінальні файли для завантаження в магазини.

Типові помилки при налаштуванні маніфестів:

• Відсутність фільтра камери при required — краш на Android.
• Неправильний опис NSCameraUsageDescription — реджект iOS.
• Увімкнення Face Tracking без потреби — фальшивий запит FaceID.
• Забутий Depth API meta-data — краш на пристроях без Depth.
• Змішання required та optional в одному додатку — плутанина для користувача.

Наш досвід — 5+ років в AR-розробці, понад 50 опублікованих AR-додатків. Гарантуємо, що після нашого налаштування ваш додаток пройде рев'ю з першого разу. Замовте налаштування маніфесту — ми безкоштовно оцінимо проєкт і запропонуємо оптимальне рішення. Отримайте консультацію прямо зараз.