What made you buy it?
What made you buy it?
I did know that the Quest Pro would not live up to that task (and it doesn't), but I wanted to see how close you could get today for $1500 (now, $1000).
I also do boxing and similar fitness games almost every day, so I knew it would at least serve me well for that, despite being pretty expensive. (An yeah, for that, it's pretty great.)
The new Apple gizmo looks way better for programming and work like that, though, so I'm excited about it. After many years, we appear to be getting close to something that is actually pleasant to use. (Even the Quest Pro technically can be used for this, but the experience is far from pleasant.)
The resolution isn't the problem with Quest Pro (although I always want more) but the passthrough of the real environment around you is terrible. It's very distorted, as if the cameras are far lower resolution than the screen is.
I've heard that this aspect of the experience is better on the Apple Vision Pro, although I don't know for sure since I haven't yet tried it myself.
This actually doesn't matter that much, because the resolution is still good enough to walk to the fridge and grab a drink (or whatever) without taking it off.
The other super interesting thing to me is the external display of your eyes on the surface of the headset.
This sounded so stupid to me when it leaked before they announcement, that now I am embarrassed, because the problem is one we have all the time in my own house. I've realized it is a fundamental problem with these devices, and one I even had all the time, and yet I couldn't see how that would solve it. But it really does seem to.
The problem we always have is, our kids put on one of the headsets we have, but then we (their mom and I, and their siblings/friends) can't tell whether they can see us or not. This actually really matters a lot -- if the wearer cannot see, then we need to make sure no other kids get near them, otherwise there is a risk of collision and injury. This is partially solved by casting the view from the headset to the TV or whatever, but this is glitchy and sometimes even disabled.
The other scenario where this is really useful is at the office, or even a coffee shop. When a coworker walks up to you, they have a visual indicator of whether you can see them or not. Actually a very important social cue.
Or when the waitress comes up to bring you your coffee. You can look at her and accept the coffee, and it is obvious to her that you can see the cup she's handing you. Sure, she'll still probably be a little weirded out the first time, but she'll get used to it. :-D
Based on Apple's track record, they're going to disallow development on the Vision like they do for all iOS/iPad devices.
(This does require a Mac to be also present, though.)
Secondly, none of these devices have anywhere close to enough computing power to make doing builds on them directly feasible — at least not for most coding work, including the work I do.
So I want to develop using the model popularized by tools like VS Code's remote development extensions or GitHub Codespaces. I want the headset to render all the editors and other windows locally. I want the device to connect to my mechanical keyboard and mouse, so that I can do all my normal coding stuff. But the machine where the code actually is, where the build is actually done, and where the local dev server or similar runs -- all remote.
This is actually the workflow I now prefer even on desktops and laptops, now that the tooling is so good. But for a spatial computing headset device, this will have to be the main model.
And while I also am not at all a fan of Apple's limiting what we can do on our devices the way they do, putting that aside you can already do this workflow in iPad. You can use CodeSpaces in the browser, but there is a cool native app called Blink[1] that lets you use your own hardware as the build machine.
I use a large and high-spec Linux workstation with 4 large monitors in my day-to-day work. But with VS Code remote, when I have to travel with my laptop, I just connect to the Linux workstation (via Tailscale in my case, but there are various options) and use the code editor locally on the laptop, but the CLI, build, etc is happening on the remote machine.
On a laptop, this works great. It is better than the regular workflow of doing it all on the laptop, because the tooling (if you use VS Code, anyway, but others are also working on this) is so good and the remote build machine is so much more powerful than a laptop. It also lets you just switch to a new device whenever you want without worrying about having to commit your changes first. So I can go to the office or just a different room of my house and just sit down at whatever computer is available and pick up where I left off.
But I've also done this using both the Quest Pro and iPad, just to check in with the state of the art on those devices. Both of them can do it. The Quest sucks in lots of ways (clunky OS, low-quality passthrough of the real environment, glitches). The iPad actually works fine, except teven the largest iPad Pro is a laughably tiny monitor to work on. (YMMV tho... if you are one of those "I love small screen!" people then this workflow works fine, and an iPad works as well as a laptop.)
For me, Quest Pro and iPad aren't good enough. But I want to do this workflow on a headset device, and Vision Pro looks promising.
Anyway, my point here is that even if Apple does make weird restrictions about being able to use dev tools locally on the device, that won't prevent it from doing the workflow I am interested in.
[1] https://apps.apple.com/us/app/blink-shell-build-code/id15948...
(heavy, considering there's no included battery)