THE VISION
When I got Apple Vision Pro, I tried using the native reading app. But the experience felt like a phone app that had simply been moved into a headset; the same interface, in a bigger space.
So I started asking a different question: what if reading were designed around what Vision Pro uniquely makes possible?
Two of its capabilities felt especially made for reading. First, you can interact just by looking; the most natural act there is. Second, it can change the space around you at will, so you're no longer stuck reading wherever you happen to be.
That's what Readspace is: to build the most immersive, most natural way to read.
Xcode(SwiftUI)
Reality Kit
ARKit(gaze/hand)
Apple Vision Pro

Reading should be about the words, not the controls around them. So the main control in Readspace is designed to almost disappear.
By default, it's just a small circle floating at the bottom of the page. Look at it and tap, and it fluidly expands into a full control bar; tap an option, and a menu opens above it. Look away for a few seconds, or glance elsewhere, and it gently collapses back into a single circle.
This follows one of Apple's core principles for visionOS - deference: keeping the focus on content, and letting the interface step back.


Reading should feel effortless, so the primary way to turn a page is simply to look: gaze at the edge of the page and it advances on its own, no hands needed.
But gaze isn't always the right tool. Sometimes tracking isn't perfect; sometimes you just want deliberate control over the pace. So Readspace also supports manual page; turning by pinch and drag, always there as a way to take control whenever you want it.
Together, the two cover the full range of reading: gaze for immersive, hands-free flow, and touch for precision when you need it.


Readspace is designed to be read in different immersive environments: a quiet forest, a stream, deep space.
In the current version, these environments are set through visionOS's native Environments, with Readspace layered inside them. Bringing environment switching directly into the app — so you can change your surroundings without leaving the reading experience is one of the next things I'm building.
Reading is personal, and so is comfort. Everyone's eyes and sense of space are different, so Readspace lets you adjust the window size and depth, the content size and font to whatever feels most natural to you — reducing eye strain and letting you read comfortably for longer.
My first idea for page scroll was simple: watch for when your eyes reach the last few words on the page, and turn it automatically. First instinct was using .onHover, since gaze-driven hover highlighting is very visible on visionOS. It even worked fine in the Simulator — because the Simulator uses mouse position to simulate gaze.
On the actual device, it was a different story. .onHover simply doesn't fire from gaze alone. Digging into Apple's developer forums cleared it up: raw gaze coordinates are never exposed to third-party developers on visionOS, not even through the Enterprise APIs . It's a deliberate privacy decision; eye-tracking data can reveal a lot about attention and behavior, so Apple just doesn't open that door
Which means, on visionOS, gaze-based interaction really only has two paths:
1. The native "look + pinch" gesture: the system hands you the combined event, but never the raw "where you're looking" data itself.
2. Apple's purpose-built semantic APIs, like .scrollInputBehavior(.enabled, for: .look)
The final app ended up combining two complementary interaction methods:
1. Gaze at the top/bottom edge of the page triggers an auto page-turn — built with .scrollInputBehavior(.enabled, for: .look), keeping the experience hands-free and immersive.
2. Pinch-and-drag as a manual page-turn — added as a complement to the first, giving users precise control when they want a more deliberate pace, or don't want to rely entirely on gaze timing.
Architecture first
Before any code gets written, I write a detailed spec for each part of the app:defining its structure, its components, its constraints, and the rules it has to follow. Readspace runs on a clean MVVM architecture: a documented map of every file and its responsibility, native visionOS components rather than reinvented ones, a fully tokenized design system so nothing is hard coded, and each module designed to be extended, with explicit hooks for the features still to come.
Directing the build
With those specs as the blueprint, I use an AI coding agent inside Xcode to move from specification to working implementation. My role is defining the architecture, making the technical decisions, diagnosing what goes wrong, and deciding how it gets solved.
A lot of the real work happens in the details: deciding that two floating panels needed to be fully isolated so they wouldn't interfere with each other's layout, or tracking down why an animation was starting from the wrong origin.
Keeping a growing codebase under control
As the project grew, the hardest part was making sure new work didn't break what already worked. So I built a governance system into the project: components that are finished get "frozen," with explicit rules about what can and can't change, down to the single modifier that's allowed to stay flexible. It's how I keep a fast, AI-assisted workflow from quietly eroding the parts that are already solid.

Readspace is an ongoing project. A few directions I'm building toward:
AI-powered translation:Read in one language with an instant translation in another. For anyone reading outside their native language.
AI reading extensions: Reading often sparks curiosity that a book alone can't answer. This feature surfaces related context and knowledge based on what you're reading, and turning reading from passive intake into active exploration.
In-app environments: Bringing environment switching directly into the app, making the immersive space fully part of Readspace itself.





