One Web, Fifty Standards: Why Cross-Platform Development Is Becoming a Nightmare (And What To Do About It)

Remember when the browser wars were "over"? When we finally got to a place where writing one codebase meant it would mostly work across Chrome, Firefox, Safari, and Edge without too many tears? Yeah, those days feel quaint now. Because a new round of fragmentation is underway, and this one is messier, more consequential, and moving faster than the CSS vendor-prefix era ever did.

The culprit this time isn't just browser vendors being stubborn. It's the collision of spatial computing, XR platforms, device-specific APIs, and a W3C standardization process that—through no fault of its own—simply can't keep pace with the speed at which Apple, Meta, Google, and Microsoft are shipping platform-defining features. The result is a cross-platform development landscape that's quietly becoming a minefield.

The Fragmentation Map, As It Stands

Let's name the actual fault lines, because they're worth understanding clearly.

WebXR is the W3C's attempt at a unified standard for immersive web experiences across VR and AR devices. In theory, it's the answer—write once, deploy to any XR-capable browser or device. In practice, implementation support is wildly uneven. Chrome on Android supports it reasonably well. Safari on visionOS supports a subset of it, wrapped in Apple's own additional layers. Meta's browser on Quest devices has its own quirks. Mozilla's WebXR implementation has historically been ahead of the spec in some areas and behind in others. The "standard" exists, but the standard is not the experience.

Apple's spatial APIs for visionOS are elegant, well-documented, and almost entirely proprietary. RealityKit and ARKit are powerful tools, but they're Apple tools. If you build natively against them, you're building for one ecosystem. Apple's visionOS browser does support WebXR, but with enough limitations that serious spatial experiences often push developers toward native development—which is, of course, exactly what Apple wants.

Meta's Horizon OS SDK follows a similar pattern. The platform is increasingly open in its hardware strategy (third-party headsets, etc.), but the software layer is still very much Meta's territory. Their Presence Platform APIs for mixed reality have no meaningful cross-platform equivalent.

Google's approach is arguably the most fragmented of all. WebXR was largely Google's push, but their own Android XR platform (targeting Samsung's headset hardware) introduces yet another layer of device-specific considerations. Their ARCore platform for mobile AR doesn't map cleanly onto WebXR either.

And then there are the platform-specific JavaScript SDKs, the Unity-to-web export pipelines, the Unreal Engine WebGL/WebGPU paths, and a dozen smaller players all pushing their own abstractions. It's a lot.

Why This Is Happening (It's Not Random)

Fragmentation at this scale doesn't happen by accident. There are real business and technical reasons behind it, and understanding them helps you make smarter bets as a developer.

First, the market isn't settled yet. Nobody knows which spatial computing platform wins—or if any single one does. When the outcome is uncertain, every major player has an incentive to establish proprietary standards that create switching costs and developer dependency. This is Platform Strategy 101. Apple locked in iOS developers with Swift and proprietary APIs. Google locked in Android developers. Now everyone's trying to do it again with spatial computing before the ecosystem calcifies.

Second, the W3C process is genuinely slow. This isn't a criticism—it's a structural reality. Consensus-based standards development takes time, and when companies are shipping spatial hardware on 18-month product cycles, waiting for a fully ratified spec isn't commercially viable. So they ship what they need to ship, and the spec catches up later. Sometimes.

Third, performance requirements diverge by device. What's technically feasible on a Vision Pro is fundamentally different from what works on a $300 Android phone. Standards that try to cover both often end up doing neither particularly well, which gives platform-specific implementations a real quality advantage.

The Developers Caught in the Middle

The companies feeling this most acutely are mid-size dev shops and independent teams trying to build spatial or XR-adjacent products for real clients. Enterprise clients don't want to hear "it works on Quest but not Vision Pro." Brands running immersive commerce experiences can't afford to maintain three separate codebases for three different platforms.

The cost isn't just time—it's architectural debt. Teams that make early bets on a proprietary SDK and then watch the platform lose market share face painful rewrites. Teams that bet purely on WebXR sometimes deliver experiences that feel noticeably worse than native alternatives, which is its own kind of business problem.

Startups like Niantic (with their 8th Wall platform), PlayCanvas, and Needle Tools are all trying to solve this with abstraction layers—tools that let you write once and target multiple runtimes. They're useful, and getting better, but they're also adding a dependency layer that comes with its own risks. What happens to your codebase if 8th Wall gets acquired or pivots?

Practical Strategies for Not Getting Burned

Okay, enough doom. Here's what actually works for developers trying to navigate this landscape without losing sleep.

Bet on open formats, not open platforms. glTF for 3D assets. WebXR for device interaction where it's supported. Web Components for UI. These aren't perfect, but they're the closest thing to genuinely portable foundations that exist right now. The more your core logic and assets live in open formats, the easier it is to retarget when platforms shift.

Build a feature detection layer from day one. Don't assume capability—query for it. The navigator.xr.isSessionSupported() pattern in WebXR is your friend. Graceful degradation from full spatial to flat-screen fallback isn't a nice-to-have; it's the architecture that lets you ship to the widest audience without maintaining separate codebases.

Treat proprietary SDKs as optimization targets, not foundations. If you need to ship a native visionOS experience, do it—but keep your core application logic and data layer platform-agnostic. The platform-specific code should be a thin layer, not the structure holding everything up.

Watch the WebXR Layers API and WebXR Hand Input spec closely. These are the areas where the gap between spec and implementation is narrowing fastest. Developers who build against these specs now, with appropriate fallbacks, are positioning themselves well for when support becomes more consistent.

Pick your abstraction layer carefully. If you go with a cross-platform tool like 8th Wall or Needle Tools, understand their business model and their platform coverage roadmap before you commit. An abstraction layer that doesn't cover your target platform is just another dependency.

The Uncomfortable Truth

Here's the thing nobody really wants to say out loud: the "build once, run everywhere" dream for spatial computing is probably a few years away from being genuinely achievable—if it gets there at all. The current standards wars are going to produce winners and losers, and some of the platforms developers are building for today won't exist in their current form by 2027.

That's not a reason to sit on the sidelines. It's a reason to build smart—to keep your architecture portable, your assets open, and your platform bets diversified. The web survived the first browser wars. It'll survive this one too. But the developers who come out ahead will be the ones who understood the battlefield, not the ones who trusted that someone else would sort it out.