Налаштування маніфестів для публікації AR ігор в Google Play та App Store

Наша компанія з розробки відеоігор веде незалежні проекти, спільно з клієнтом створює ігри та надає додаткові операційні послуги. Досвід нашої команди дозволяє нам охопити всі ігрові платформи та розробити приголомшливий продукт, що відповідає баченню клієнта та перевагам гравців.

Від імерсивних застосунків до ігрових світів і 3D-сцен

Наша виділена команда для VR/AR/MR-розробки, Unity-продакшну і 3D-моделювання та анімації — з власними кейсами і презентаціями.

Відвідати персоналізований сайт
Показано 1 з 1Усі 242 послуг
Налаштування маніфестів для публікації AR ігор в Google Play та App Store
Простий
~2-3 дні
Часті запитання

Наші компетенції

Які етапи розробки гри?

Останні роботи

  • image_games_mortal_motors_495_0.webp
    Розробка гри для компанії Mortal Motors
    696
  • image_games_a_turnbased_strategy_game_set_in_a_fantasy_setting_with_fire_and_sword_603_0.webp
    Покрокова стратегія у фентезі сеттингу With Fire And Sword
    879
  • image_games_second_team_604_0.webp
    Розробка ігри для компанії Second term
    504
  • image_games_phoenix_ii_606_0.webp
    3D-анімація – тизер для гри phoenix 2.
    543

tags: [vr-ar]

Настройка манифестів для публікації AR ігр у Google Play та App Store

AR-приложення — не звичайне мобільне приложення. Маніфест для Google Play та Info.plist для App Store містять специфічні для AR ключі, без яких приложення або не пройде ревю, або упадає при запуску у користувача, якщо ARCore/ARKit не підтримується або не ініціалізований.

AndroidManifest.xml для ARCore: обов'язкові та опціональні режими

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.

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

Info.plist для ARKit: NSUsageDescription та capabilities

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

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

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

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

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

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

AR Foundation автоматично додає частину потрібних ключів у маніфест через 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-проекту, без ризику втратити зміни при пересборці.

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

Процес настройки

Аудит поточних манифестів, виявлення розбіжностей вимогам поточних версій ARCore та ARKit. Настройка залежностей (required/optional), permissions, usage descriptions. Перевірка на тестових пристроях різних класів — включаючи пристрої без підтримки AR. Підготовка фінальних манифестів для сабміту.

Задача Орієнтовні строки
Аудит + правка існуючих манифестів 1 робочий день
Настройка з нуля (обидві платформи) 2–3 робочих дні
Ітерація після реджекту App Store / Google Play 1–2 дні на цикл

Вартість розраховується індивідуально після аналізу проекту.