Hacker News

It still applies to this specific case. He's released a version of his existing app hoping others might use, instead of solving a problem he identified would be best tackled with a Vision Pro than with a desktop app.

All I'm saying is "don't build an app for the masses if the market is small. build something that solves a real need that you have personally identified"

I'm not convinced the demographic of people willing to spend $2000 on an Apple headset is much different from the demographic of people willing to spend $3500 on an Apple headset

> The rumor mill is saying it will be cheaper... but still not cheap at ~$2000.

That same rumor mill has always said that an affordable consumer version is the long term goal.

Apple has started development on a consumer version of the tech in a glasses form factor several times over the years, only to decide the current tech still doesn't allow for what they want.

For instance, an iteration that was tethered to an iPhone that made it to test production in 2019:

> Apple could begin production of its long-rumored augmented reality glasses as early as the end of this year, noted analyst Ming-Chi Kuo has said.

https://www.theverge.com/2019/3/8/18256256/apple-ar-glasses-...

Apple does have the advantage of being able to project their 2D apps if they want, right? A $5k device seems like a dead end, and a $2k one seems pretty rough still (unless it totally 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.

It's not just hand tracking. We're literally here commenting on a tutorial for the Apple-exclusive Metal API.

Every step of development is a reason not to write software for this thing, and it doesn't exist in a vacuum, either.

I have trouble believing that even a successor to the Vision Pro would look significantly better than my $800 Pimax Crystal Light.

> 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.

All supply chain reports before the release were in line with the fact that the in-headset screens were capped at 1million maximum production possible for the first year, and two screens are required for each headset.

3MM was never possible, not sure where you got these numbers.

If you can't grok an analogy, that's on you. But let me simplify.

Don't bother developing for this platform. The customer base is miniscule.

1975: Don't bother writing MicroSoft BASIC. The customer base is miniscule.

I'm not pushing Apple's AR goggles. I'm not a customer, or even the target demographic. But if your company, or its leadership, lack vision for the future and only invest in the present, don't be surprised when the world passes you by.

* median, below median

a good hockey player doesn’t skate in the direction that absolutely nobody else is heading

That doesn't make sense in this context. Unless you consider Meta, Loft Dynamics, Valve, HTC, and dozens of other companies to be "absolutely nobody."

Thanks both for pulling on this point. In drafting, I was both torn and fuzzy about the nomenclature. Also trying to be distinct about hardware features (dynamic vertex data?) versus language/API constructs. But you are right, it's important to be clear because they are different and hardware might not support both.

I was trying to see if the other graphics APIs (Vulkan, DirectX) had this Vertex Amplification in Vertex Shader feature, but it doesn't seem so? Maybe it was easier for Apple to inject the concept into Metal (advantage of controlling of the whole stack).

There's an autoreleasepool around the per-frame code - which seems to be standard procedure for Metal code - so any object within a render frame that has been created with autorelease will be released at the end of a frame.

Metal has a couple of 'frame transient' objects (like MTLRenderPassDescriptor and MTLRenderCommandEncoder) which have a new instance created in each frame, and I guess the main job of the autoreleasepool is to clean up those transient objects (along with any other 'short-lived-junk' that might be returned from Metal API methods).

And my guess for why this is still needed in the age of ARC: I guess that ARC has a 'autorelease-blindness', e.g. it cannot figure out at compile time what objects are registered with autorelease pools (especially when the objects are passed across DLL boundaries) - it can only add retain/release calls on top. Just speculation on my part though.

The render thread is running an infinite loop. You need to manually drain the autorelease pool, otherwise autoreleased objects created during rendering won't be released until the thread exits (there's an implicit top-level pool in each NSThread which is drained on exit). In UIKit/AppKit, the autorelease pool is drained at the end of each NSRunLoop iteration by the framework, so you don't typically drain it yourself. Here they created their own runloop - an infinite `while` loop that calls `onRender()` - so they must drain the pool themselves.