8th Wall Integration for WebAR in Mobile Applications

8th Wall — a WebAR platform built on WebGL and a custom SLAM engine running directly in the browser without ARKit/ARCore. This means AR experiences launch via a link or QR code, no app installation required. For businesses, this is often a decisive factor: conversion to "opened link" is significantly higher than "downloaded app". We have integrated the platform into dozens of mobile applications and know how to avoid the typical pitfalls.

Integration into an existing mobile app is done through WKWebView (iOS) or WebView/Custom Tabs (Android), where the AR scene renders inside a native container. Alternatively, as a standalone PWA with deep linking from the app. WebAR via 8th Wall allows launching AR scenes 3 times faster than native app development and requires lower initial investment.

Common Pitfalls and Solutions

Camera access inside WKWebView. On current iOS versions, Apple permits getUserMedia in WKWebView, but with caveats: mediaTypesRequiringUserActionForPlayback must be set, and allowsInlineMediaPlayback = true. Without these, the platform cannot access the camera and throws NotAllowedError. On Android, the situation is simpler — modern Chrome WebView supports getUserMedia without specific flags.

SLAM performance on budget devices. 8th Wall uses its own world tracking instead of ARCore, which is heavier on CPU. On devices with Snapdragon 665 and below, FPS in a scene with dynamic lighting and multiple 3D objects drops to 18–22. Solutions: reduce model poly count to 15k triangles, disable real-time shadows, use baked lightmaps in GLTF. Our practice shows that optimizing the scene with these rules gives a 1.5–2x FPS boost on low-end devices.

HTTPS requirement. The platform requires a secure context for the camera API. Local development via localhost works, but staging on HTTP does not. WKWebView in an app works with any URL if NSAllowsLocalNetworking is set, but production scenes need a valid SSL certificate.

Ensuring Stable Camera Operation in WKWebView

1. Configure WKWebViewConfiguration correctly: allowsInlineMediaPlayback = true and mediaTypesRequiringUserActionForPlayback = [].
2. Implement WKUIDelegate with the method webView(_:requestMediaCapturePermissionFor:) and return .granted.
3. Verify that the scene URL is loaded over HTTPS (even in development, use a local server with SSL).
4. For debugging, enable NSAllowsLocalNetworking in Info.plist.

Why SLAM Performance Matters

Comparison of WebAR (8th Wall) vs native AR (ARKit/ARCore) by key parameters:

Our Integration Process

The WebAR project is created in the platform's cloud IDE — there you write JavaScript/TypeScript scenes based on A-Frame or Three.js plus the 8th Wall pipeline. For native integration:

iOS Setup (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/")!))

A WKUIDelegate intercepts webView(_:requestMediaCapturePermissionFor:) — otherwise the permission dialog won't appear.

Android: Custom Tab vs WebView

Custom Tabs launch a full Chrome with WebXR API and camera support — the preferred option. A native WebView requires a WebChromeClient with overridden onPermissionRequest. For seamless integration (without switching to browser), use WebView with a custom UA string if the platform doesn't detect it as restricted.

Passing Data Between Native Layer and WebAR Scene

Via WKScriptMessageHandler on iOS and addJavascriptInterface on Android. A typical case: pass userId or SKU to the scene so it loads the correct 3D model from CDN.

What's Included in Our Service

• Analysis of current stack and versions (iOS/Android) — 1 day
• Architecture design of WebView container with permissions and backend interface — 2 days
• Implementation of WebView wrapper with custom WKUIDelegate / WebChromeClient — 3 days
• Deep linking and PWA mode setup (if needed) — 1 day
• Integration and testing on devices from the list: iPhone 11+, Samsung Galaxy S10 and above, Google Pixel 4+ — 2 days
• Provision of build and configuration documentation — included
• Access to 8th Wall cloud IDE and project setup — included
• Training session for your development team (2 hours) — included
• Post-launch support for 2 weeks — included
• Support during App Store / Google Play moderation (camera and media requirements) — included

Licensing and Limitations

8th Wall operates on a subscription model: Starter, Pro, Enterprise. The license is tied to a domain. For a white-label product or multiple client domains — Enterprise only. Keep this in mind during evaluation. 8th Wall Official Documentation

<key>NSCameraUsageDescription</key>
<string>Camera access is required for WebAR</string>
<key>NSAllowsLocalNetworking</key>
<true/>

Timelines and Cost

Cost is calculated individually after analyzing scene requirements and target devices. We'll assess your project for free — get in touch, let's discuss the details.

Why Choose Us?

With 5+ years of experience in mobile development and over 40 successful AR/VR integrations across iOS and Android, our certified engineers (Apple and Google) deliver robust solutions. We use modern approaches: SwiftUI, Jetpack Compose, Kotlin Multiplatform. Get a consultation — we'll help you choose the optimal solution.

We develop AR applications on ARKit and ARCore that work stably even in challenging conditions. Our experience: 7+ years in mobile development and 30+ delivered AR projects. Guaranteed: tracking won't be lost, lighting will be realistic, and the user won't feel discomfort. Certified Apple and Google developers.

Why does tracking get lost and how to fix it?

ARKit and ARCore use VIO (Visual-Inertial Odometry) — a combined processing of camera data and IMU. Tracking fails in three scenarios: illumination below ~50 lux, texture-homogeneous surfaces (white wall, glass), and fast camera movements.

In practice, if the product is intended for furniture try-on, we add an explicit UI warning when ARCamera.TrackingState.limited(.insufficientFeatures). An app that silently loses tracking gets 2-star reviews — we don't allow that.

Plane detection is configured via ARWorldTrackingConfiguration.planeDetection = [.horizontal, .vertical]. Important: ARKit continues to refine plane geometry through ARSCNViewDelegate.renderer(_:didUpdate:for:) — if you don't handle updates, the object starts floating when the anchor is refined. Our team solves this at the architecture stage, not during testing.

AR Foundation: cross-platform with nuances

Unity AR Foundation is an abstraction layer over ARKit and ARCore. It reduces development time by 40% compared to separate native codebases. But some features (e.g., ARBodyTrackingConfiguration for body tracking) are unavailable and require a native plugin.

For React Native and Flutter, direct AR Foundation is missing. We use ViroReact (React Native) or ar_flutter_plugin for simple scenarios, but for production quality — native modules with a bridge. Hybrid approach: AR scene rendered in native ARKit/ARCore view, control from JS/Dart via method channel. Included in our standard delivery.

Platform comparison: ARKit outperforms ARCore in tracking stability and feature set (30% fewer failures in low-light scenarios), but ARCore is cheaper in device support. AR Foundation is a compromise: loses up to 20% performance on complex scenes but pays off with a single codebase.

Try-on: product fitting via AR

Fitting glasses, jewelry, cosmetics — a separate class of tasks. Here, face tracking is needed, not plane detection.

ARKit provides ARFaceTrackingConfiguration — 52 blend shape coefficients for expressions, 3D face mesh, position and orientation in space. Works only on devices with TrueDepth camera (iPhone with Face ID).

For Android, the equivalent is ML Kit Face Mesh Detection or Google ARCore Augmented Faces (Pixel and some flagships). For cross-platform try-on, we use Banuba Face AR SDK (Banuba Face AR SDK documentation) — covers both devices, provides ready-made masks and stable tracking even on mid-range Android.

Try-on quality critically depends on 3D product models. Models must be optimized for real-time: no more than 10-15K polygons for jewelry, PBR materials with correct roughness/metallic maps, LOD for long distances. Within our engagement, we provide ready-made optimization guides.

How to achieve realistic lighting in AR?

ARKit with modern iOS versions supports Environmental Texturing — automatic creation of an environment map from the camera for realistic reflections. Enabled via ARWorldTrackingConfiguration.environmentTexturing = .automatic. Without it, metallic and glass materials look plastic.

ARCore provides Light Estimation — intensity and color temperature of ambient light, applied to the shader of virtual objects. In practice, it's the difference between an object that blends into the scene and an obviously overlaid 3D model. We guarantee that the final image doesn't betray virtuality.

What's included

• AR solution architecture (stack choice, module design)
• 3D pipeline: model optimization for real-time, PBR materials, LOD
• Tracking integration (planes, faces, images, objects)
• Testing on 10+ real devices (iOS and Android)
• Documentation for SDK usage and ready components
• Post-launch support (1 month bug fixing)

Timeline and estimation

Simple AR scene with placing one 3D model on a plane — 1-2 weeks. Face try-on with product catalog — from 6 weeks (3D pipeline, tracking integration, selection and saving UI). Full AR shopping with cloud anchors and multiplayer — from 3 months. We'll estimate your project in 1 day — contact us to discuss your AR idea.