After finally releasing a Vision Pro version of my app last week, I've sold a total of 7 units. That's by far my worst software launch ever, even worse than my past failures.
Don't bother developing for this platform. The customer base is miniscule.
Don't bother developing for this platform. The customer base is miniscule.
A good hockey player don't skate to where the puck is. He skates to where it will be.
You should still get familiar with it in the event that the next one will be cheaper as that will increase the customer base a lot.
The rumor mill is saying it will be cheaper... but still not cheap at ~$2000.
https://www.uploadvr.com/non-pro-apple-vision-headset-report...
Meta is having enough trouble attracting developers with hardware that's an order of magnitude cheaper and has two orders of magnitude more units in the wild.
Apple does have the advantage of being able to project their 2D apps if they want, right? A $5k device seem like a dead end, and a $2k one seems pretty rough still (unless it total replaces your laptop, which might make it worth considering).
They clearly haven’t executed it correctly yet. But at least they do have some hope of beating the bootstrapping problem that everybody else seems to have—they could try and get users first, and then I bet developers would quickly follow.
On track to having sold less than 15% of their Y1 target (400,000 vs 3 MM), production deliveries slashed, and the reported shareholder near-revolts, I think it's clear that the Vision Pro has flopped and there won't be a sequel any time soon.
> On track to having sold less than 15% of their Y1 target (400,000 vs 3 MM)
This is a fictitious number. Apple never had the manufacturing capacity to reach that so-called target.
> the reported shareholder near-revolts
Citation needed.
So, a developer should spend ~$5000 with no chance of ROI on the off chance that at some undefined point in the future this will pay off when they would have to spend another ~$5000 developing for the newer/cheaper/whatever device?
I'm curious about the autoreleasepool. What's the reason to have it and how much of a difference does it make?
It's a lifetime management system for short-lived objects, same idea as memory arenas but for manually refcounted objects you got out of an API. It keeps the object alive until the end of the autorelease scope without anybody having to explicitly call the release method (the autoreleasepool does this instead). Not sure if the concept still makes sense with ARC though, it's probably just a no-op there - or probably not seeing that Swift seems to have inherited autoreleasepools from ObjC).
Hi! Yeah I know the concept from non-arc ObjC times but trying to understand the point in this context.
Looks great, thanks so much for writing this!
I've put everything I've learned while developing graphics for Apple Vision with the Metal API and Compositor Services in writing. It covers foveation, vertex amplification, stereoscopic rendering, and more techniques that extend beyond this particular device.
Thanks! Looks very interesting and usefull.