Shipping AR as static files

Shipping AR as static files

Releasing a native AR app is a process with gates in it: build per platform, sign, submit, wait for review, publish, wait for users to update. Releasing a web AR experience is git push.

That is a genuine advantage and it relocates the difficulty rather than removing it.

What the deployment actually is

For this project: static files. The site is assembled by a build script that produces one output tree — a landing page at the root and each demo app under its own sub-path — which a CDN serves. No server, no runtime, no per-user state.

Consequences worth noticing:

• Rollback is redeploying the previous build. No store, no review, no waiting.
• Every app ships together. One tree, one deploy, one version of everything.
• Cost is approximately zero and does not scale with users.
• The computation has no server to be offline from. The alignment runs entirely on-device — no positioning service, no round trip. That is a real property and an unusual one for location-based AR. The page, though, is a different matter: these apps have no service worker today, so "install it and use it with no signal" is not yet true, and making it true is filed work rather than a shipped feature.

What replaces store review

Store review is a bad quality mechanism, but it is a quality mechanism, and removing it leaves a gap that something must fill. In practice:

The gate before the commit. Formatting, linting, type-checking, unit tests, end-to-end tests and a dead-code check, run on the packages a change touches. That is the thing standing between a mistake and production, so it has to be trusted, which means it has to be green for real reasons — a flaky test in the gate is more corrosive here than in a project with a human review step downstream.

Knowing what the gate cannot see. A favicon 404 survived many green runs in this project because headless Chromium never requests a favicon. No test configuration would have caught it; only opening the real app does. Cataloguing those blind spots is part of the release discipline, not an admission of failure.

Deploy previews. Because deployment is cheap, a branch can be a URL. For AR specifically that is transformative: reviewing a change means opening a link on a phone and walking outside, which is the only complete test that exists.

What replaces the version matrix

Nothing, and that is the win. There is one version live. "Which version are you on" has one answer, bug reports need no version field, and there is no population of users on a build from four months ago.

The flip side is that there is no staged rollout unless you build one, and everyone gets a regression simultaneously. Cheap rollback is what makes that acceptable — the honest arrangement is fast forward, fast back, rather than slow and careful.

The parts that are harder than native

Distribution is your problem. No store listing, no search, no charts. A URL is only as good as the places it appears — which for location-based work means signage, QR codes at the place itself, and whatever the web can be persuaded to surface. This is the genuine cost of leaving the store, and it is paid in marketing rather than engineering.

Caching, if you add it, becomes your problem. A service worker is what makes a page work offline — and it introduces "why is the user still on last week's build" in the same breath, which is a sharper risk when there is one live version and no staged rollout. Nothing here uses one yet.

Device support is narrower. WebXR immersive-ar means ARCore-class Android today. That is not a deployment question, but it is the first question every user's device answers.

Permissions have no install-time story. A native app asks at a moment of the user's committed attention. A web app asks a person who arrived thirty seconds ago.

The honest summary

The web release loop is dramatically faster and structurally less protected. It suits a project that iterates constantly, deploys small changes, keeps a gate it actually trusts, and treats "open the real app on a real phone" as a step rather than an afterthought.

It suits less well a project that would rather batch changes into a release and rely on someone else's process to catch what its own does not.