Implementing AR Plane Detection in a Mobile App
We often encounter this scenario: a client wants to place a virtual sofa in a room, but the app shows a "floating" object without clear alignment to the floor. The user is disappointed, and the developer hits the limitations of platform SDKs. Stable plane detection is key to convincing AR. Without it, any AR object feels foreign. We have learned to bring plane detection to a "looks like it belongs" state within 5-8 days.
Platform APIs and Their Real Limitations
ARKit (iOS). ARWorldTrackingConfiguration with planeDetection: [.horizontal, .vertical]. ARKit returns ARPlaneAnchor with ARPlaneGeometry—a plane mesh that updates as scanning progresses. The problem: in the first seconds, ARKit returns a small rectangle that aggressively changes size and orientation. If you place an object immediately, it will "jump" on the next update.
The solution is a minimum confidence threshold and debounce on updates. ARPlaneAnchor does not have an explicit confidence field, but the plane size (extent) serves as an indirect indicator of maturity: do not show the placement UI until extent.x < 0.3 and extent.z < 0.3 meters.
ARCore (Android). Plane with TrackingState.TRACKING and PlaneType.HORIZONTAL_UPWARD_FACING / VERTICAL. ARCore additionally provides Plane.getSubsumedBy()—when two planes merge into one. This breaks the logic if anchors were attached to the original planes; you need to transfer the Anchor to the subsuming plane.
Vertical planes. ARKit reliably detects vertical planes on textured surfaces (patterned wallpaper works well, monotonous white walls do not). ARCore with vertical detection is even less confident. For products where wall mounting is critical (pictures, shelves), it is better to combine plane detection with LiDAR (iPhone 12 Pro+) to fill in missing geometry.
How LiDAR Changes the Game?
On devices with LiDAR (iPhone 12 Pro, 13 Pro, 14 Pro, 15 Pro, iPad Pro), ARKit builds a dense mesh of the environment through ARMeshAnchor. Plane detection with LiDAR works fundamentally differently: planes are derived from the mesh, not from visual SLAM. This yields:
- Plane detection in 1-2 seconds instead of 5-10
- Stable boundaries even on uniform surfaces
- Correct detection of steps, ramps, and sloped planes
For applications where LiDAR devices are the primary target audience (professional photography, renovation, construction), switching between ARWorldTrackingConfiguration and a configuration with sceneReconstruction: .mesh provides a significant quality leap.
Why Does the Plane "Jump" and How to Fix It?
The main reason is placing the object before the plane stabilizes. Confidence threshold and debounce solve 80% of the issue. Our proven approach:
- Do not show the placement button until the plane size exceeds 0.3 meters on each axis.
- When the plane updates, smoothly move the anchor with animation (e.g.,
SCNActionin SceneKit orUIView.animatein RealityKit). - Use
ARWorldTrackingConfiguration.isAutoFocusEnabledto improve frame quality.
Detailed checklist for stable placement
- Check `ARPlaneAnchor.extent.x > 0.3` and `extent.z > 0.3` - Ignore plane updates for 0.5 seconds after the first detection - On LiDAR devices, use `ARMeshAnchor` for more accurate geometry - Always handle `ARCamera.TrackingState` and block UI when `LIMITED`Visualizing Scanning Progress
The user does not know they need to "sweep" the camera—clear guidance is needed. Typical patterns:
- Animated scanning ray from the bottom of the screen
- Plane outline that "grows" as detection progresses
- Text instructions that auto-hide after the first successful detection
For drawing plane boundaries in RealityKit—ModelEntity with wireframe material attached to PlaneAnchor. In SceneKit—SCNNode with SCNGeometry from ARPlaneGeometry.boundaryVertices. In ARCore with SceneKit/Filament—a custom mesh from Plane.getPolygon().
Typical Production Problems
Plane "breaks" with excessive camera motion—tracking state transitions to LIMITED(.excessiveMotion). Block object placement and show a warning, do not crash.
On dark surfaces (dark laminate, black carpet), ARKit and ARCore lose features for visual SLAM. Warning via ARCamera.TrackingState.Reason.insufficientFeatures—must be handled and communicated to the user.
What's Included in the Work
- Testing on target devices with stability evaluation
- LiDAR optimization (if supported)
- Multi-plane selection (ability to select a plane by tapping)
- ARWorldMap persistence for scene reuse
- Integration and configuration documentation
- Guarantee of stable operation: 30 days of free support after delivery
| Platform | API | Features |
|---|---|---|
| iOS (ARKit) | ARPlaneAnchor, ARWorldTrackingConfiguration | Fast start, but debounce required |
| Android (ARCore) | Plane, getSubsumedBy() | Plane merging, anchor transfer |
| LiDAR devices | ARMeshAnchor | Detection in 1-2 sec, stability |
Visualization Methods Comparison
| Tool | Boundary Visualization | Performance | Flexibility |
|---|---|---|---|
| RealityKit | ModelEntity with wireframe | High | Medium |
| SceneKit | SCNNode from boundaryVertices | Medium | High |
| ARCore + Filament | Mesh from getPolygon() | Medium | High |
Apple ARKit documentation: ARKit Plane Detection Google ARCore documentation: Plane Detection
Estimated Timeline
Basic plane detection with visual hints and object placement—5 to 8 days. Adding LiDAR support, multi-plane selection, and ARWorldMap persistence—another 5-7 days. Cost is calculated individually, depending on complexity. Get a consultation—contact us to evaluate your project.
Our team has 5+ years of AR development experience and over 20 successful projects. Order a turnkey implementation and get a free consultation.