Services / AR / VR (ARKit, LiDAR, visionOS)
AR / VR (ARKit, LiDAR, visionOS)
Survey-grade spatial work on hardware your users already carry.
We treat AR as an engineering problem, not a marketing one - the question is whether the spatial signal carries the product, and what it takes to keep it accurate on the phones your users actually hold. Real-time point clouds, mesh reconstruction, RTK-grade georeferencing, custom Metal shaders, and visionOS scenes - immersive spaces, hand-tracking-driven interactions, and shared coordinate work on the Vision Pro hardware - on top of that foundation. We've built survey-grade scanners on iPhone, and we'll tell you when AR earns its place and when it doesn't.
Right call when…
- →Your problem is fundamentally spatial (measurement, capture, overlay).
- →Customers are willing to point a phone at something for results.
- →On-device performance matters more than cross-platform reach.
How we think about this work.
What LiDAR adds over camera-only AR
The LiDAR scanner in iPhone Pro and iPad Pro models is a direct time-of-flight sensor - it measures true hardware depth instead of inferring it from camera motion. That single difference decides which class of product you can build: camera-only ARKit is fine for placement and try-on, while LiDAR moves an app into measurement and documentation territory.
| Attribute | LiDAR (active depth) | Camera-only (passive SLAM) |
|---|---|---|
| Depth | True hardware depth, instant | Inferred from motion parallax and texture |
| Initialization | Instant placement, no scan-the-floor step | Manual scanning to build a feature map |
| Low light | Works in darkness (active infrared) | Fails when image features get noisy |
| Blank surfaces (white walls) | Handles them | Struggles badly |
| Drift | Significantly reduced scale drift | Accumulates faster |
The accuracy we design around
Our scoping rule for LiDAR products: close range on cooperative surfaces is centimeter territory, building scale is decimeter territory, and past 5 meters - or on glass and polished metal - the sensor is no longer your instrument. Those boundaries go into the statement of work before any code is written, because an accuracy budget is a scoping decision, not a hope.
What actually decides project outcomes is the processing pipeline: drift correction, quality gating, registration, export semantics. Independent benchmarks show an order-of-magnitude quality spread between apps running identical hardware - which is why the pipeline, not the sensor, is where we spend the engineering budget.
Where spatial capture earns its keep
Enterprises pay for the deliverable, not the scan: floor plans captured in minutes instead of hours of tape measuring, claim-ready documentation that saves adjusters a reported $300-500 per claim, parcel dimensioning that avoids $15,000-80,000 fixed scanning stations, and AR remote assistance with an audited 138% ROI (Forrester TEI study of Dynamics 365 Remote Assist, commissioned by Microsoft).
Our reference build in this space is a survey-grade scanning product that pairs an iPhone with an external RTK receiver and holds survey tolerances in real field conditions - shipped to working crews and maintained through OS releases. The full engineering story, from correction streaming to the point-cloud renderer, lives in the posts linked from this page.
Questions people ask about AR / VR (ARKit, LiDAR, visionOS)
What ARKit and LiDAR work have you actually shipped?
Survey-grade 3D scanning, real-time point clouds with millions of points, RTK-grade georeferencing, custom Metal shaders, and visionOS scenes. Specific case studies are kept private under NDA.
When does AR earn its place in a product?
When the problem is fundamentally spatial - measurement, capture, overlay - and users are willing to point a phone at something for the result.
Can the AR feature work on Android too?
Some can via ARCore, but the iOS path with ARKit + LiDAR is typically deeper. We tell you when the answer is iPhone-only honestly.