Augmented reality apps overlay digital objects onto the physical world through a device's camera. A furniture app lets you place a virtual couch in your living room. A navigation app draws turn-by-turn arrows on the road in front of you. A retail app lets you try on sunglasses without visiting a store. The technology runs on ARKit (iOS) and ARCore (Android), using the camera, gyroscope, accelerometer, and sometimes LiDAR to understand the physical environment and render 3D objects in it.
Testing these apps is fundamentally different from testing a standard mobile app. In a regular app, the input is a tap on a screen and the output is a UI change. In an AR app, the input is the physical world (lighting, surfaces, movement, GPS coordinates), and the output is a 3D object rendered in real time on top of a live camera feed. You can't test that with a screenshot comparison or an emulator. The environment changes every time.
What makes AR testing different from regular mobile testing
Standard mobile testing assumes a controlled, deterministic UI. You tap a button, the next screen appears, you validate the text. AR testing doesn't have that luxury. Here's why.
The camera is the input layer. Every AR session starts with the device camera scanning the environment. The quality of that scan depends on lighting, surface texture, distance, and movement speed. A white wall with no texture gives ARCore nothing to track. A dimly lit room degrades the camera feed. A user walking too fast causes tracking jitter. These aren't edge cases. They're normal usage conditions.
The environment is non-deterministic. If you test a login screen, it looks the same every time. An AR scene changes depending on where the user is standing, what's in front of them, and how much light is in the room. Two test runs in the same location 10 minutes apart can produce different results because the sun moved.
3D rendering runs in real time. AR apps maintain 60 frames per second while simultaneously processing camera data, running spatial mapping algorithms, and rendering 3D objects with correct lighting and perspective. If the frame rate drops below 30 fps, the experience feels broken. If it drops below 20 fps, users get motion sickness. Performance testing for AR isn't optional. It's a safety concern.
Sensor fusion is complex. AR frameworks combine data from the camera, gyroscope, accelerometer, magnetometer, and (on newer iPhones) LiDAR to build a model of the physical space. Each sensor introduces its own error margin. Gyroscope drift accumulates over time. GPS is accurate to 3-5 meters outdoors and useless indoors. Testing has to account for these sensor limitations on specific devices.
6 areas to test in an AR app
1. Spatial tracking accuracy
Virtual objects need to stay anchored in physical space. If you place a virtual chair next to a real table, that chair should stay put when you walk around the room, look away, and look back. Test this by placing an object, then moving the device in a circle around it. Walk 5 meters away and come back. Tilt the device up and down. On lower-end devices or in low-texture environments, you'll see the object drift or jump. That's a tracking failure.
Also test on surfaces that are hard for AR to read: glass tables, solid-color floors, reflective surfaces, and very dark rooms. These are common in real-world usage and they break tracking more often than you'd expect.
2. Environmental occlusion
When a virtual object is behind a real-world object, it should be hidden. If you place a virtual lamp behind a real couch, the couch should block the lamp from view. Without proper occlusion, the virtual object floats on top of everything, which looks wrong and breaks immersion.
LiDAR-equipped devices (iPhone 12 Pro and later) handle occlusion well because they have depth data. Non-LiDAR devices estimate depth from the camera feed, which is less accurate. Test both device types.
3. Performance under real conditions
AR apps are CPU and GPU intensive. Test frame rate on mid-range devices (not just flagships), because that's what most users have. Run the AR experience for 5+ minutes continuously and monitor for thermal throttling. When the device gets hot, the OS reduces CPU/GPU clock speed, and frame rates drop. Also measure battery drain: a 10-minute AR session that burns 15% battery is a problem.
Test with background apps running. A user with Spotify playing, GPS navigation active, and notifications coming in is a realistic scenario. AR performance degrades when the system is under memory pressure.
4. Lighting adaptation
AR rendering needs to match the real-world lighting. A virtual object in a bright room should have bright highlights and sharp shadows. The same object in a dim room should look darker. ARKit and ARCore provide light estimation APIs that feed real-world brightness and color temperature to the rendering engine.
Test in at least four conditions: bright daylight (outdoor), indoor fluorescent, dim room with warm light, and mixed lighting (window on one side, lamp on the other). The transition between lighting conditions matters too. Walk from a bright room into a dark hallway and check if the virtual object adapts smoothly or flickers.
5. Camera and sensor behavior across devices
Not all devices are equal. An iPhone 15 Pro with LiDAR gives ARKit dense depth maps. An iPhone SE gives it a single camera with no depth sensor. ARCore on a Samsung Galaxy S24 behaves differently than on a Pixel 8 because of different camera hardware and ISP processing.
Test the same AR flow on at least 3-4 devices across different tiers: a flagship, a mid-range, and the oldest device your app still supports. Pay attention to gyroscope drift on older devices (the virtual world slowly rotates even when the device is still) and GPS accuracy for location-based AR features.
6. Cross-platform consistency
If your app runs on both iOS and Android, the AR experience can look different on each. ARKit and ARCore use different algorithms for plane detection, lighting estimation, and object tracking. A surface that ARKit detects in 2 seconds might take ARCore 5 seconds on the same physical surface. Virtual object placement can be offset by a few centimeters between platforms.
Test the same scenarios on both platforms and document the differences. Not every difference is a bug. Some are framework limitations. But your users don't care about the framework. They care that the couch they placed looks correct.
Tools for AR testing
AR testing tooling is limited compared to standard mobile testing. Here's what exists.
ARKit diagnostics (iOS): Xcode's Reality Composer and ARKit debugging overlays show you feature points (the dots ARKit tracks on surfaces), plane detection boundaries, and world origin. Xcode Instruments profiles CPU, GPU, memory, and thermal state during AR sessions. This is the best tool for diagnosing iOS AR performance issues.
ARCore tools (Android): Android Studio's profiler tracks CPU, memory, and GPU rendering during ARCore sessions. The ARCore Geospatial API has a built-in visualization mode that shows tracking quality and anchor accuracy. Android GPU Inspector gives you frame-level GPU performance data.
Unity Test Framework: If your AR app is built in Unity (common for games and retail AR), Unity's Test Framework can run automated tests on AR scenes. You can validate object placement, physics interactions, and rendering states. But you still can't automate the camera input. The tests assume a simulated environment.
Manual testing protocols: Most AR testing teams rely on structured manual test scripts: go to location X, point at surface Y, place object Z, walk around it, validate from 3 angles. It's slow, but it's the only way to test real-world environment variability. Recording video of every test session helps with bug reproduction.
Why automated AR testing is still mostly manual
This is the honest part. AR apps are hard to automate because the things that make them unique are the things automation can't control.
3D objects don't have element IDs. You can't write tap("virtual_chair") because the chair exists in 3D space relative to a camera feed, not in a DOM or accessibility tree. There's no selector for "the object 1.5 meters in front of the camera, 30 degrees to the left."
Camera input can't be reliably mocked. You can feed a pre-recorded video into the camera pipeline, but it won't match the sensor fusion data (gyroscope, accelerometer, LiDAR) that the AR framework expects. The result is broken tracking.
The environment is a variable, not a constant. Running the same test twice in the same room can produce different results because the lighting changed, someone moved a chair, or the device started from a slightly different angle.
This means the AR-specific parts of your app (object placement, tracking, occlusion, rendering) will stay largely manual for now. But here's the thing: every AR app also has non-AR screens. Onboarding flows, login, permissions dialogs, settings pages, purchase flows, navigation menus, and the transition between AR and non-AR views. Those screens are standard mobile UI, and they're fully testable with automation.
That's where mobile test automation fills the gap. Tools like Drizz can test every non-AR flow in your app on real devices using plain English test steps and Vision AI. "Open the app, skip onboarding, grant camera permission, tap Try AR, validate the AR view loaded, tap Back, validate the home screen." The Vision AI sees the screen the way a user does, so it works regardless of how the UI is built. It doesn't break when the UI changes, and the same test runs on both iOS and Android.
You'll still need manual testers for the AR experience itself. But the 60-70% of your app that's standard mobile UI? That can be automated today, and it should be, so your manual testers can focus their time on the spatial, visual, and environmental testing that actually requires human judgment.
FAQ
What is augmented reality testing?
Augmented reality testing is the process of validating that an AR app correctly overlays digital objects onto the real world through a device's camera. It covers spatial tracking, object occlusion, rendering performance, lighting adaptation, sensor accuracy, and cross-device compatibility. It's different from standard mobile testing because the physical environment is part of the test input.
What tools are used for AR testing?
Xcode Instruments and ARKit debugging overlays are the main tools for iOS AR testing. Android Studio Profiler and Android GPU Inspector cover ARCore apps. Unity Test Framework handles automated tests for Unity-built AR apps. Most AR-specific testing (tracking accuracy, occlusion, lighting) is still done manually with structured test protocols.
Can AR testing be automated?
Partially. The AR-specific parts (3D object placement, spatial tracking, occlusion, environmental rendering) are hard to automate because they depend on camera input and real-world conditions that can't be reliably mocked. The non-AR parts of an AR app (onboarding, login, settings, purchase flows, navigation) can be automated with standard mobile testing tools.
What's the biggest challenge in AR testing?
Environment variability. The same AR app can behave differently depending on lighting, surface texture, device hardware, and user movement. A test that passes in a bright office might fail in a dim apartment. This non-deterministic behavior makes it hard to create repeatable test cases.
How do you test AR performance?
Monitor frame rate (target 60 fps, minimum 30 fps), measure thermal throttling during extended sessions (5+ minutes), track battery drain, and test on mid-range devices, not just flagships. Use Xcode Instruments (iOS) or Android GPU Inspector (Android) for frame-level GPU profiling.
Do AR apps need cross-device testing?
Yes. ARKit and ARCore use different algorithms for plane detection, lighting, and tracking. LiDAR-equipped devices produce significantly better occlusion and tracking than non-LiDAR devices. An AR experience that works perfectly on an iPhone 15 Pro might have tracking drift on an iPhone SE or a budget Android phone.
