Is visionOS Development Worth It Yet? visionOS 27 Reviewed

Every visionOS release generates the same two genres of coverage: a feature roundup and an argument about whether Vision Pro is doomed. Neither answers the question a working developer actually has: whether building for the platform pays for itself.

That question has had an uncomfortable answer for two years. visionOS 27 changed part of the arithmetic, though not the part the roundups led with.

In this post:

• The honest state of the argument
• What actually changed
• The pathways matter more than the features
• What didn't change
• The testing problem nobody mentions
• Who this is now worth it for
• My take

The Honest State of the Argument

Worth setting the baseline without spin. Vision Pro has been available a little over two years, received an M5 hardware revision last autumn, and has been the subject of persistent discourse about its future amid reportedly slow sales.

That's the context every one of these decisions gets made in, and pretending otherwise helps nobody. The install base is small. A developer arguing for spatial work on a roadmap is arguing against a colleague who can point at iPhone numbers, and losing.

Apple has also kept building. The depth in visionOS 27, covering expanded object tracking, Reality Composer Pro 3, and third-party engine and accessory support, points to continued platform investment regardless of commercial pressure. That signals Apple's intent, not your return on investment. The two are different questions, and the coverage tends to conflate them.

What Actually Changed: The Work Transfers Now

Here's the item from Apple's own WWDC26 visionOS guide that I think matters most, and which the feature roundups largely skipped.

visionOS 27 takes object tracking further. High-frame-rate tracking gives more frequent pose updates as objects move, an extended Create ML training option improves accuracy particularly for objects held in hand, and a new API provides object pose in metric space without display corrections, unlocking high-precision uses such as surgical navigation training.

Then the part that changes the business case: these features are available on both visionOS and iOS, object tracking doesn't require platform-specific training, so reference objects you've already created work in both your iOS and visionOS apps without retraining, and an ARKit API for iOS supports the same object tracking functionality as visionOS.

Read that as an economics statement rather than a feature note.

The expensive part of an object-tracking feature was never the code. It was producing and training the reference objects, a specialised, slow, asset-heavy process with no obvious owner on most teams. And until now, that investment was stranded on a platform with a small install base, which made it nearly impossible to justify to anyone holding a budget.

Now the same reference object drives a feature on iPhone. The training work amortises across two platforms with wildly different install bases. That doesn't make Vision Pro sell better. It makes the spatial work you do for Vision Pro stop being a bet on Vision Pro.

The Pathways Matter More Than the Features

Apple's own framing at WWDC26 is worth noticing. The visionOS 27 session lays out several routes onto the platform: native Apple tools and frameworks, streaming immersive content from a Mac or PC, third-party engines, or porting existing iOS apps.

Two of those four are explicitly "don't rebuild your app." Streaming frameworks let teams extend existing Mac and PC software to the headset without rebuilding it, and porting an existing iOS app is presented as a first-class route rather than a fallback.

That's a meaningful shift in posture. The early platform pitch was that spatial computing demanded spatial-native software, a new interaction paradigm requiring new applications. That framing produced beautiful demos and very little sustainable commercial work, because it asked for a full rebuild in exchange for access to a small audience.

The visionOS 27 framing is closer to: bring what you have, and go deeper only where it pays. Less romantic, and considerably more likely to result in software people actually use.

The Spatial Accessories framework fits the same pattern. Third-party tracked hardware connects through the Game Controller framework, with RealityKit or ARKit tracking each accessory's movement and orientation in space. Existing framework, existing mental model, new capability.

What Didn't Change

The counterweight, stated plainly:

The install base is still small, and nothing in a software release fixes that. Any revenue model that needs volume is still wrong for this platform.

Spatial design skill doesn't transfer. Your iOS layout instincts are actively misleading in a room-scale context, and that learning cost is real regardless of how much code you reuse. This is the part that consistently gets underestimated, because code portability is easy to measure and design competence isn't.

There's no public beta programme for visionOS, unlike iOS and macOS. Your users won't be running the new OS before general availability, so you get no early signal from a wide audience, and a narrower feedback loop than you're used to elsewhere in the Apple ecosystem.

Hardware cost is a per-developer tax. Not one Vision Pro for the team, but enough that people can actually work.

The Testing Problem Nobody Mentions

This is the part I'd want to know before committing a team, and I've not seen it discussed anywhere.

Spatial features can't be tested in CI. Not "are difficult to." Structurally cannot. An object-tracking feature requires the physical reference object to be present, in a real space, with real lighting, in front of real cameras. No simulator configuration stands in for that, and no build agent can hold up a handheld object.

Consider what that means for a discipline that has spent twenty years moving verification into automated pipelines. Every other category of mobile feature, including layout, networking, persistence and even camera work to a degree, has some automatable proxy. Spatial features reintroduce manual testing as a structural necessity, not a choice. Your regression suite for that feature is a person, in a room, with the object.

And it degrades quietly. Object tracking accuracy depends on lighting, distance, how the object is held, and how similar it looks to other things in view. None of those produces a failure. They produce worse tracking, which is a gradient rather than a boolean. There's no assertion to write.

Here's where the cross-platform change earns its place a second time, and this is the connection I'd most want a team lead to notice.

If reference objects work on both platforms without retraining, and iOS has ARKit support for the same object tracking, then your tracking-pipeline testing doesn't require a Vision Pro. You can validate that a reference object is trained well, that tracking holds up under real lighting, that pose data is sane, all on an iPhone. A device every member of your team already has, and which you can hand to someone in another office, or another country, to try.

That converts "we need three headsets before we can meaningfully test this" into "we need headsets before we ship, and iPhones for everything up to that point." For a team trying to get spatial work approved, that's a materially different proposal.

The honest limits: it doesn't test the spatial presentation, the interaction, or anything about how the thing feels at room scale. Those still need the hardware and a person. But asset quality and tracking robustness, the parts most likely to be quietly wrong and most expensive to discover late, move onto cheap, plentiful devices.

Who This Is Actually Worth It For, Now

Worth it: teams already shipping an iOS app with a camera or AR feature where object tracking has a plausible use. The reference-object work now pays for itself on iPhone alone, and visionOS support becomes an increment rather than a project.

Worth it: anyone in enterprise or training contexts where value per user is high enough that install base is irrelevant. The metric-space pose API being pitched at surgical navigation training is a fair signal of where Apple thinks the money is, and they're probably right.

Worth it: teams with existing Mac or PC software who can reach the headset via streaming rather than a rebuild.

Not yet worth it: consumer apps needing volume. Nothing here changes that.

Not yet worth it: anyone treating visionOS as a way to learn spatial design on company time. The learning is real and valuable, but the ROI case isn't there, and dressing it up as one costs you credibility for the next thing you propose.

My Take

The most useful change in visionOS 27 is one that reduces the platform's specialness, and I mean that as praise. Cross-platform object tracking, iOS porting as a first-class route, and streaming existing desktop software are all mechanisms for making spatial work less of a bet. The early pitch asked developers to believe in a paradigm shift. This release asks them to reuse assets. The second is a much better foundation for an ecosystem, because it survives a bad sales quarter.

Having shipped on Apple platforms through a few of these cycles, the pattern is familiar. Every new Apple platform begins by insisting it needs native-first thinking and ends by making it easy to bring existing work across. Apple Watch went through it. iPad went through it, repeatedly and painfully. The turn usually comes when someone internally accepts that developer attention is the scarce resource, not developer imagination.

I'd raise the testing constraint in the planning meeting, not the install base. Everyone already knows the install base is small. It's the first objection anyone makes, and it's priced in. What nobody has costed is that a spatial feature carries a permanent manual verification requirement, forever, on every release. That's an ongoing operational cost, not a one-off build cost, and it doesn't appear on any estimate I've seen. If you take one thing from this post into a planning conversation, make it that, and make the cross-platform tracking point immediately afterwards, because it's the mitigation.

And the honest bottom line: visionOS development is worth it in 2026 if you can construct a version of the work that pays for itself without Vision Pro. That's now genuinely possible for a real category of app, which wasn't true a year ago. It is still not worth it if the whole case rests on people buying the headset.

FAQ

Does object tracking work on iPhone now?
Yes. visionOS 27's object tracking features are available on both visionOS and iOS, with an ARKit API on iOS supporting the same functionality.

Do I need to retrain reference objects for each platform?
No. Object tracking doesn't require platform-specific training, so reference objects work in both iOS and visionOS apps without retraining.

What's new in object tracking specifically?
High-frame-rate tracking for more frequent pose updates, an extended Create ML training option that improves accuracy for handheld objects, and a new API that provides object pose in metric space without display corrections.

Is there a public beta of visionOS 27?
No. visionOS has no public beta programme, so most users will get it at general availability, expected in autumn 2026.

Can I bring an existing Mac or iOS app to Vision Pro without rebuilding?
Apple offers streaming from a Mac or PC and porting existing iOS apps as first-class routes onto the platform, alongside building natively.

Can spatial features be tested automatically?
Object tracking can't be, since it needs the physical object in a real space. You can, however, validate reference-object quality and tracking robustness on an iPhone rather than requiring a headset for every developer.