Интеграция 8th Wall для WebAR в мобильном приложении

8th Wall — платформа для WebAR на базе WebGL и кастомного SLAM-движка, работающего прямо в браузере без ARKit/ARCore. Это означает, что AR-опыт запускается по ссылке или QR-коду, без установки приложения. Для бизнеса это часто решающий аргумент: конверсия в «открыл ссылку» в разы выше, чем «скачал приложение». Мы интегрировали 8th Wall в десятки мобильных приложений и знаем, как обойти типичные грабли.

Интеграция в существующее мобильное приложение строится через WKWebView (iOS) или WebView/Custom Tabs (Android), где 8th Wall-сцена рендерится внутри нативного контейнера. Либо как standalone PWA с диплинкингом из приложения. WebAR через 8th Wall позволяет запускать AR-сцены в 3 раза быстрее, чем разработка нативного приложения, и требует меньших вложений на старте.

Где обычно ломается

Камерный доступ внутри WKWebView. На актуальных версиях iOS Apple разрешила getUserMedia в WKWebView, но с оговорками: mediaTypesRequiringUserActionForPlayback должен быть настроен, а allowsInlineMediaPlayback = true. Без этого 8th Wall не получит доступ к камере и выбросит NotAllowedError. На Android ситуация проще — современные версии Chrome WebView поддерживают getUserMedia без специфических флагов.

Производительность SLAM на бюджетных устройствах. 8th Wall использует собственный world tracking вместо ARCore, что тяжелее по CPU. На устройствах с Snapdragon 665 и ниже FPS в сцене с динамическим освещением и несколькими 3D-объектами падает до 18–22. Решается: снижение poly count модели до 15k треугольников, отключение real-time shadows, использование baked lightmaps в GLTF. Наш опыт показывает, что оптимизация сцены по этим правилам даёт прирост FPS в 1,5–2 раза на слабых устройствах.

HTTPS-требование. 8th Wall требует secure context для camera API. Локальная разработка через localhost проходит, но staging на HTTP — нет. WKWebView в приложении работает с любым URL при NSAllowsLocalNetworking, но для production-сцен нужен валидный SSL.

Как обеспечить стабильную работу камеры в WKWebView?

1. Убедитесь, что WKWebViewConfiguration настроен правильно: allowsInlineMediaPlayback = true и mediaTypesRequiringUserActionForPlayback = [].
2. Реализуйте WKUIDelegate с методом webView(_:requestMediaCapturePermissionFor:) и возвращайте .granted.
3. Проверьте, что URL сцены загружается по HTTPS (даже в development используйте локальный сервер с SSL).
4. Для отладки включите NSAllowsLocalNetworking в Info.plist.

Почему производительность SLAM критична?

Сравнение WebAR (8th Wall) и нативного AR (ARKit/ARCore) по ключевым параметрам:

Как строим интеграцию

Проект 8th Wall создаётся в cloud IDE платформы — там же JavaScript/TypeScript сцены на базе A-Frame или Three.js + 8th Wall pipeline. Для нативной интеграции:

Настройка iOS (WKWebView)

let config = WKWebViewConfiguration()
config.allowsInlineMediaPlayback = true
config.mediaTypesRequiringUserActionForPlayback = []

let webView = WKWebView(frame: .zero, configuration: config)
webView.load(URLRequest(url: URL(string: "https://your-8thwall-scene.8thwall.app/scene/")!))

WKUIDelegate нужен для перехвата webView(_:requestMediaCapturePermissionFor:) — иначе пермишен-диалог не появится.

Android: Custom Tab vs WebView

Custom Tabs запускают полноценный Chrome с поддержкой WebXR API и camera — предпочтительный вариант. Нативный WebView требует WebChromeClient с переопределённым onPermissionRequest. Для seamless-интеграции (без перехода в браузер) — WebView с кастомным UA-string, если платформа 8th Wall не определяет его как restricted.

Передача данных между нативным слоем и WebAR-сценой

Через WKScriptMessageHandler на iOS и addJavascriptInterface на Android. Типовой кейс: передать userId или SKU продукта в сцену, чтобы та загрузила правильную 3D-модель из CDN.

Что входит в работу

• Анализ текущего стека и версий (iOS/Android) — 1 день
• Проектирование архитектуры WebView-контейнера с учётом пермишенов и бэкенд-интерфейса — 2 дня
• Реализация WebView-обёртки с кастомным WKUIDelegate / WebChromeClient — 3 дня
• Настройка диплинкинга и PWA-режима (если необходимо) — 1 день
• Интеграция и тестирование на устройствах из списка: iPhone 11+, Samsung Galaxy S10 и выше, Google Pixel 4+ — 2 дня
• Предоставление документации по сборке и настройке — входит
• Поддержка на этапе модерации в App Store / Google Play (требования к камере и медиа) — включена

Лицензирование и ограничения

8th Wall работает по подписке: Starter, Pro, Enterprise. Лицензия привязана к домену. Для white-label продукта или нескольких клиентских доменов — только Enterprise. Учитывайте это на этапе оценки. Официальная документация 8th Wall.

<key>NSCameraUsageDescription</key>
<string>Для работы WebAR требуется доступ к камере</string>
<key>NSAllowsLocalNetworking</key>
<true/>

Сроки и стоимость

Стоимость рассчитывается индивидуально после анализа требований к сцене и целевым устройствам. Оценим проект бесплатно — пишите, обсудим детали. Свяжитесь с нами для консультации по вашей задаче.

Почему выбирают нас?

Мы работаем с мобильной разработкой 5+ лет, выполнили более 40 интеграций AR/VR в приложения под iOS и Android. Наши инженеры сертифицированы Apple и Google. Используем современные подходы: SwiftUI, Jetpack Compose, Kotlin Multiplatform. Получите консультацию — мы поможем выбрать оптимальное решение.

Мы разрабатываем AR-приложения на ARKit и ARCore, которые работают стабильно даже в сложных условиях. Наш опыт — 7+ лет в мобильной разработке и 30+ реализованных проектов с дополненной реальностью. Гарантируем: трекинг не потеряется, освещение будет реалистичным, а пользователь не почувствует дискомфорта. Сертифицированные разработчики Apple и Google.

Почему трекинг теряется и как это исправить?

ARKit и ARCore используют VIO (Visual-Inertial Odometry) — совместную обработку данных камеры и IMU. Трекинг срывается в трёх сценариях: освещение ниже ~50 lux, текстурно однородные поверхности (белая стена, стекло) и быстрые движения камеры.

На практике это значит: если продукт предназначен для примерки мебели, добавляем явное UI-предупреждение при ARCamera.TrackingState.limited(.insufficientFeatures). Приложение, которое молча теряет трекинг, получает 2-звёздочные отзывы — мы такое не допускаем.

Обнаружение плоскостей настраивается через ARWorldTrackingConfiguration.planeDetection = [.horizontal, .vertical]. Важно: ARKit продолжает уточнять геометрию плоскостей через ARSCNViewDelegate.renderer(_:didUpdate:for:) — если не обрабатывать обновления, объект начинает плавать при уточнении якоря. Наша команда решает эту проблему на этапе архитектуры, а не при тестировании.

AR Foundation: кросс-платформа с нюансами

Unity AR Foundation — слой абстракции поверх ARKit и ARCore. Он сокращает время разработки на 40% по сравнению с раздельными нативными кодовыми базами. Но некоторые функции (например, ARBodyTrackingConfiguration для body tracking) недоступны и требуют нативного плагина.

Для React Native и Flutter прямой AR Foundation отсутствует. Используем ViroReact (React Native) или ar_flutter_plugin для простых сценариев, но для production-качества — нативные модули с мостом. Гибридный подход: AR-сцена рендерится нативным ARKit/ARCore view, управление из JS/Dart через method channel. Входит в нашу стандартную поставку.

Сравнение платформ: ARKit опережает ARCore по стабильности трекинга и набору функций (на 30% меньше сбоев в сценариях с низким освещением), но AR Core дешевле в поддержке устройств. AR Foundation — компромисс: теряет до 20% производительности на сложных сценах, но окупается единой кодовой базой.

Try-on: примерка товаров через AR

Примерка очков, украшений, косметики — отдельный класс задач. Здесь нужен face tracking, а не plane detection.

ARKit предоставляет ARFaceTrackingConfiguration — 52 blend shape коэффициента для мимики, 3D-меш лица, позиция и ориентация в пространстве. Работает только на устройствах с TrueDepth-камерой (iPhone с Face ID).

Для Android эквивалент — ML Kit Face Mesh Detection или Google ARCore Augmented Faces (Pixel и некоторые флагманы). Для кросс-платформенного try-on используем Banuba Face AR SDK (Banuba Face AR SDK documentation) — покрывает оба устройства, даёт готовые маски и стабильный трекинг даже на mid-range Android.

Качество try-on критически зависит от 3D-моделей товаров. Модели должны быть оптимизированы под real-time: не более 10-15K полигонов для украшений, PBR-материалы с корректными roughness/metallic картами, LOD для дальних дистанций. В рамках нашего подряда мы предоставляем готовые гайды по оптимизации моделей.

Как добиться реалистичного освещения в AR?

ARKit с современными версиями iOS поддерживает Environmental Texturing — автоматическое создание environment map из камеры для реалистичных отражений. Включается через ARWorldTrackingConfiguration.environmentTexturing = .automatic. Без этого металлические и стеклянные материалы выглядят пластиково.

ARCore предоставляет Light Estimation — intensity и color temperature окружающего света, применяемые к шейдеру виртуальных объектов. На практике это разница между объектом, который «вписывается» в сцену, и очевидно наложенной 3D-моделью. Мы гарантируем, что финальное изображение не выдаёт виртуальности.

Что входит в работу

• Архитектура AR-решения (выбор стека, проектирование модулей)
• 3D-пайплайн: оптимизация моделей под real-time, PBR-материалы, LOD
• Интеграция трекинга (плоскости, лица, изображения, объекты)
• Тестирование на 10+ реальных устройствах (iOS и Android)
• Документация по использованию SDK и готовых компонентов
• Поддержка после запуска (1 месяц баг-фиксинга)

Сроки и оценка

Простая AR-сцена с размещением одной 3D-модели на плоскости — 1–2 недели. Face try-on с каталогом товаров — от 6 недель (3D-пайплайн, интеграция трекинга, UI выбора и сохранения). Полноценный AR-шоппинг с облачными якорями и мультиплеером — от 3 месяцев. Оценим проект за 1 день — пишите, обсудим вашу AR-идею.