Your WebXR experience already exists.
SixR makes it run on iPhone.

SixR is a WebXR browser for iPhone. It opens standard WebXR experiences — built with Three.js, A-Frame or plain JavaScript — and runs them on ARKit. No native port, no proprietary SDK, no rebuild.

Your experience keeps its original HTTPS URL. You host it, you own the domain, you ship updates by deploying your site. SixR is the runtime layer in between: it exposes the WebXR Device API inside its browser and feeds it with ARKit tracking, camera and input.

SixR ships as:

• a full app with a browser and QR reader,
• an App Clip, so a link or QR code opens an experience directly with nothing pre-installed,
• a free runtime — every developer hosts and controls their own site,
• future premium features such as image tracking, object tracking and custom App Clips.

SixR is not a platform and not an experience builder. It is the layer that brings WebXR to iOS while the web, the domain and the code stay in the developer's hands.

Quick start

There is nothing to install and no SixR library to add. If your experience runs as WebXR on Android Chrome, it runs in SixR.

1 · Build a standard WebXR experience

const session = await navigator.xr.requestSession("immersive-ar", {
  optionalFeatures: ["hit-test", "dom-overlay"],
  domOverlay: { root: document.body }
});

2 · Host it over HTTPS

Any static host works. WebXR requires a secure context, so plain HTTP will not start a session.

3 · Open it in SixR

Type the URL, scan its QR code, or point an App Clip code at it. The experience starts in AR exactly as deployed — same URL, same code.

Supported WebXR

Frameworks that target the standard WebXR Device API work without changes; Three.js and A-Frame are what we test against on every release.

Browser detection

Detect capabilities, not browsers. The same check you already use for Android Chrome answers whether SixR can start your session:

const supported =
  await navigator.xr?.isSessionSupported("immersive-ar");

If you do need to identify the runtime — analytics, support links, feature flags — SixR identifies itself in the User-Agent:

... SixR/<version> ...

Some older pages hard-block WebXR when they detect iOS. For those, SixR offers an optional Android-compatibility mode that presents an Android-style User-Agent so the capability check above runs normally. Prefer fixing the detection; use the mode when you can't touch the page.

Known limitations

Not everything in the WebXR spec is available yet. Currently missing:

Sessions that request these as optionalFeatures still start; the feature is simply reported as unavailable. Requesting them as requiredFeatures fails the session, as the spec mandates. Guard accordingly.

SixR extensions

Capabilities that go beyond the current WebXR spec will ship as optional, namespaced features — never as changes you must make to a standard experience:

const session = await navigator.xr.requestSession("immersive-ar", {
  optionalFeatures: ["sixr-target-tracking"]
});

A page that ignores every extension keeps working. A page that opts in gets the extra capability inside the same session model. Extensions will be documented here as they land.

Samples

Known-good starting points. All of them are standard WebXR and run unmodified:

• Three.js — hit test · place objects on detected surfaces
• Three.js — cones · minimal select-to-spawn example
• A-Frame — showcase · declarative scene, AR-ready
• Immersive Web samples · the reference test suite for the spec

Mini-games

Three tiny games, each one self-contained HTML file served next to these docs. All follow the same session flow: hit test places the board, a countdown runs in the DOM overlay, then you play.

• Pop · bubbles rise from your floor — burst them before they drift away
• Stack · drop sliding blocks and build the tallest tower on your table
• Whack · octahedra pop out of a 3×3 board — tap them down in 30 s

The demo below is also a sample: view-source this page for a complete hit-test implementation with a graceful no-hit-test fallback.

Try it