We are an ARKit consultancy, so you might expect this post to end with "build a native app." It does not always. Some of the most effective AR we have seen on iPhone is a USDZ file behind a link, and the most expensive AR failures are native apps built for use cases a link would have served. Here is how we actually advise clients to choose between the three ways of putting AR in front of Apple users in 2026.
The three options
AR Quick Look. A USDZ (or Reality) file opened by the system viewer. On the web it is an <a rel="ar"> link around an image; in Messages, Mail, Files, and Safari it just works; in a native app it is QLPreviewController. Zero install, zero AR code. The viewer handles surface placement, scaling, rotation, lighting, and on Apple Vision Pro shows the model as a volume in the room.
WebXR. AR inside the browser via the WebXR Device API. Cross-platform in principle, and on Android it is well supported in Chrome. On iOS, Safari's WebXR support has been limited to specific modes on visionOS; on iPhone, Safari does not offer a general WebXR AR session, so the iPhone experience is usually delivered by a "fallback" that is really Quick Look, or by a third-party browser app. Check current Safari release notes for the state of support when you read this; it has changed year to year.
Native ARKit + RealityKit. A SwiftUI app with RealityView, full access to ARKit tracking (planes, images, objects, faces, body, LiDAR meshing), custom UI, analytics, persistence, multi-user sessions, and the same code path to visionOS. Also: App Store review, install friction, and a development budget.
Decision table
| You need... | Quick Look | WebXR | Native |
|---|---|---|---|
| "See it in your room" for a product | Yes | Partial on iOS | Yes (overkill) |
| True-to-scale placement | Yes | Depends on browser | Yes |
| Zero install, shareable link | Yes | Yes | No |
| Android reach from the same asset | No (use glTF + Scene Viewer) | Yes | No (separate app) |
| Custom UI inside the AR view | No | Yes | Yes |
| Color/material configurator | No (one file per variant) | Yes | Yes |
| Image or object tracking | No | Limited | Yes |
| LiDAR scene understanding, occlusion | Automatic, basic | No on iOS | Yes, full control |
| Multi-user / shared sessions | No | Hard | Yes (SharePlay, collaborative sessions) |
| Persistence across sessions | No | Limited | Yes |
| Analytics beyond the link click | Minimal | Yes | Yes |
| Apple Vision Pro | Yes (volume) | Partial | Yes (full spatial app) |
| Offline / enterprise environments | Yes, if file is local | No | Yes |
| Typical cost | Asset production only | Web dev + asset pipeline | App dev + asset pipeline |
When Quick Look is the right answer
- Product visualization in e-commerce. A furniture retailer with 2,000 SKUs needs 2,000 good USDZ files far more than it needs an app. Our Object Capture tutorial covers the asset pipeline that makes this practical.
- Marketing and sales collateral. A model in an email or a QR code on a trade-show banner.
- Proof of concept. Before committing to a native build, put the model in Quick Look and watch how users actually react.
Quick Look's constraints are real: one file per variant, no custom UI, minimal analytics. But Apple keeps improving the viewer — Vision Pro support arrived with no work from content owners — and a Quick Look link is the only option where the iPhone user needs nothing installed and the experience is guaranteed to be polished.
When WebXR is the right answer
- Android is the majority of your audience and the AR feature is a simple placement or a marker-based experience.
- The experience is a web property — a campaign microsite, a browser game — with no reason to exist as an app.
- You can accept that iPhone users get a reduced experience or are routed to Quick Look.
Be clear-eyed about the iPhone reality. If your audience is largely iOS and the feature matters, WebXR's cross-platform promise is not delivered on iPhone in 2026, and the web build is effectively an Android build plus a Quick Look fallback. That can still be the right call; it should be a deliberate one.
When native is the right answer
- Tracking beyond surface placement. Image tracking for print, object tracking for equipment, face tracking for try-on, body tracking for fitness. None of this exists in Quick Look or in iOS WebXR.
- The AR is the product. Interior design tools, field-service guidance, training, measurement, games.
- Enterprise. Offline, managed devices, integration with backend systems, and soon the cross-platform object tracking across iPhone and Vision Pro that iOS 27 and visionOS 27 bring.
- Vision Pro as a first-class target. A native RealityKit app is the only path to a real spatial app, and a RealityKit iOS app is most of the way there.
- You need data. Dwell time in AR, which products were placed, what was measured, what was shared.
Native costs more, and the install step loses casual users. The way to soften both is to keep Quick Look as the top-of-funnel path and make the native app the place where the deeper features live. The same USDZ assets serve both.
A combined recommendation
For most consumer product companies our advice is staged:
- Start with Quick Look and a real asset pipeline. This is the cheapest AR you will ever ship and it validates demand.
- Add a native RealityKit feature to your existing app only when you have a specific capability Quick Look cannot deliver — a configurator, tracking, persistence — and evidence that users want it.
- Treat WebXR as an Android strategy, not a cross-platform one, unless the Safari situation changes.
- Build on RealityKit, not SceneKit, from day one, so the Vision Pro question is a packaging decision rather than a rewrite.
Not sure where your project sits? RealityRogue's consultants will give you a straight answer, including "you do not need an app." Contact us.