Hell would freeze over before Apple conformed and contributed to an existing open standard. They even failed to follow the Godot contribution guide for the PR itself.
Better get some blankets because Apple has made significant contributions to many open standards - for example, USB-C. And, back in the day, OpenGL.
Its a mistake to think of a large company like apple as if it were a person, with their own goals and ideas. Apple is just too big for that. I mean, they have 164,000 staff. Thats big enough that "small" business units will still have thousands of people. So each area will end up creating its own culture, and have its own way of doing things.
The graphics division - these days - seems very intent on doing their own thing. But that doesn't tell us much about the rest of apple. 164 000 people is a lot of people. That's an awful lot of different opinions about open standards.
Apple makes great things for their users when they collaborate with the industry. That's why we're concerned when they abandon standards and demand convergence on suspicious centralized cloud crap.
Is DirectX a standard? Is Playstation NDK (or whatever it's called) a standard?
Vulkan is not a "standard". It's a designed-by-committee API that arrived on the scene years after "non-standard" APIs.
So a "standard"?
Maybe I'm biased as I was involved with the standardization - but the whole point of a standard is something is legally possible to implement, communicates the needed information to the layer below, and general enough that it doesn't require specific hardware.
All boxes are checked by Vulkan? At least that was the intention.
So what if the origin of Vulkan was AMD's donation of Mantle, and the committee knocked the "hardware specific" points off - isn't that the desired result?
Apple is a top-down hierarchy with ruthless business strategy. Not a value judgment; merely a fact to keep in mind when entering a business relationship with Apple.
Mike Rockwell, serves as the Vice President of the Vision Products Group. Rockwell has been instrumental in spearheading the Vision Pro project and the underlying visionOS platform. His leadership has been pivotal in advancing Apple’s spatial computing initiatives.
To think he and his team have not made intentional choices to support/advance or undermine OpenXR would be naïve in my view.
I'm sure their choices are intentional. But thats just one business unit. Apple is a huge company. And different areas have different priorities.
I agree with your point - Apple clearly wants Metal & friends to be their own thing. But the comment I was replying to above commented on Apple and standards. It didn’t mention graphics at all. I replied, discussing Apple as a whole.
Because they already have their own graphics API called Metal. Why aren't you asking Microsoft to drop DirectX and start first-party support for Vulkan?
I can empathize with Apple’s desire to get more adoption of Metal, but I predict it is an uphill battle to insist on it on platforms like spatial computing that is already having a very hard time to win adoption.
If Apple wanted Metal to be a success then they'd need Windows devices to support it, and ideally a console too (like DirectX with Xbox).
There's a lot of bad things you can say about Vulkan's market position relative to DirectX, but it's clearly more successful than Metal. More games and work applications are written in it. I don't see what Apple gains from going their own way. Maybe Vulkan will rot by committee like OpenGL once did, but that hasn't happened yet.
By the way, I am still waiting to see those toaster like games on WebGL 2.0.
VisionOS doesn't support VR gaming at a basic controller level. All it can do is the same traditional console controllers that other Apple devices support (PlayStation, Switch, Xbox, etc).
Metal vs. DirectX vs. Vulkan isn't the problem, the basic input devices and lack of interoperability with other non-graphics VR tooling/SDKs are the problem.
I know that Apple doesn't see it as a gaming device and mostly sucks at interfacing with the non-mobile gaming sphere, but if they had come out of the gate with messaging that was more like "We have built-in support for popular VR controllers, game developers can just do XYZ simple thing to port their games to VisionOS," they would have had some immediate momentum to help bolster the other select few things the device excels at.
But as it stands, nobody can make any of the kinds of abstractions you are referring to because the hardware is not capable of using the basic input devices that VR games depend on. Full stop.
Instead, prospective buyers are almost certainly comparing the Vision Pro with devices like the Meta Quest Pro and thinking "well, the Apple thing does some Apple stuff that nothing else can do, but I can't even play any occasional VR games on my Vision Pro and it's literally the most expensive headset money can buy."
The truth of the matter is that a Quest 3 can do pass-through vision, VR web content, and web browsing along with a decent selection of non-gaming apps at a tiny fraction of the cost of a Vision Pro and you don't even lose all that much due to it being less premium and advanced.
Even if we are comparing against a hypothetical $999 future Vision device where the external battery is gone and it weighs less it still doesn't compare all that well in that context. An analogy would be like if the iPhone wasn't allowed to make video calls and Android was. Maybe I don't use video calling every day but I can't justify buying a phone that doesn't have a feature like that as a concept.
IMO Apple thinks that controlling the device with just the hands and no controllers is the future. They feel like they have the iPhone all over again and that all the competitors using the metaphorical stylus and built-in keyboard are wrong. But as we found out with the iPad, sometimes a specialized input device (Apple Pencil) does serve a specific subset of customers very well to the point where it's considered a basic necessity.
And then refused to use it until the EU forced them
If you're worried about the port in a classroom environment you can use a short extension that you plug in on the device end, it will make the connection separate much easier if something unfortunate happens.
After that, I was a big fan of MagSafe, but today’s USB-C and better batteries situation solves a lot of problems that MagSafe did in a different way. It allows for you to have multiple reasonably priced chargers, so the one on your desk can be safely placed, with a short unsnaggable cable. And you can still go to meetings and take your laptop home – because you have another cable in your bag and another at home.
So these days, I barely use the MagSafe cable on my MacBook Pro.
If you spent the time developing an in house graphics API since open standards weren’t moving forward, why would you rewrite everything a second time just a few years later? Shouldn’t you expect to get a decade or two out of your existing API and only do the massive rewrite when the benefits become more substantial?
Vulkan & OpenGL applications can translate to Metal with MoltenGL and MoltenVK, respectively.
Apple's GPUs support a decent chunk of the Vulkan featureset, you can go boot it up on an M1 with Asahi. Same goes for OpenXR. These are things that Apple neglects because they want to use their customerbase as leverage to market proprietary APIs. This hurts users, because Apple has neither industry-leading standards nor the leverage to force the industry to adapt. And they sure as hell lack the humility to just support both in the name of fair competition.
Yeah, that's why iOS doesn't have any games either. /s
And there's the chicken/egg problem of gamers just not being present in large enough numbers on macOS. The platform already has a fairly small marketshare in the overall PC space, the number of gamers are vanishingly much smaller; Steam stats put macOS at 1.58%, less than Linux.
https://store.steampowered.com/hwsurvey
All of the major game engines support Apple's Metal, so API compat from that perspective isn't an issue.
Crossover is another option, though I have no need to pay for it as I own a Windows PC/consoles.
https://www.reddit.com/r/linux_gaming/comments/gt3fat/proton...
The single biggest things Apple could do to bolster gaming on their platforms is to pay studios to do it or for Apple to license DirectX from MS. Anything else will barely move the needle.
That's not entirely true. Whiskey being depreciated to support Codeweavers was a headline story this week - something that outright would not need to exist if Apple users could run upstream DXVK instead of GPTk.
> pay studios to do it or for Apple to license DirectX from MS.
That doesn't work either! Paying Eidos and Capcom and Hello Games did not start an avalanche of ports. Apple could license DirectX from Microsoft, but they could also just support Vulkan 1.2 and get perfect DX12 coverage through translation.
The bigger point is that the Metal-only route isn't working. We can argue over the merits of Vulkan until the cows come home, but the simple issue is that Metal doesn't get ports. Native APIs on Apple platforms just get ignored.
For macOS, no. For iOS, yes, and that's where Apple makes almost all their revenue. Apple wants your primary target to be iOS. If you decide to do a macOS port, that's nice but not essential. Of course this doesn't work for AAA games, but that's a sacrifice they're happy to make.
Vulkan and DirectX are the favored graphics rendering technologies for VR.
Godot supports Vulkan rendering via OpenXR.
To get a vibe for Apple’s general posture in this regard it is worth noting that Vulkan rendering through OpenXR on macOS is technically possible via MoltenVK, but macOS does not have an official OpenXR runtime. You’d need to use third-party workarounds or wait for broader support.
Why is this the dichotomy? Why not support both?
I have a natural inclination to agree with this thinking, but I think it's important to recognize that this is the sunk cost fallacy at work[1].
Why the vitriol?
Apple did in fact initiate and co-create the WebGPU standard [1].
[1] https://en.wikipedia.org/wiki/WebGPU
Edit to include quote of parent comment.
In this context, what’s relevant is OpenXR. Apple’s visionOS does not natively support OpenXR, the open standard developed by the Khronos Group for cross-platform AR/VR development. Apple has not indicated any plans to adopt OpenXR, choosing instead to promote its proprietary frameworks such as ARKit, RealityKit, and PolySpatial for spatial computing on the Vision Pro.
What Apple is finding, however, is that there’s virtually no consumer or developer appetite for visionOS / Vision Pro.
> Hell would freeze over before Apple conformed and contributed to an existing open standard.
This is patently false given the fact I posted.
Now to add to the unhelpfulness in what I hope is a humorous way, we in fact have some evidence that hell did freeze over:
https://www.npr.org/sections/thetwo-way/2014/01/08/260735693...
It's a miracle they actually allowed Microsoft to be a member of the Khronos group.
I should try an make an image of Fahrenheit's beta cds some day.
From an article talking about their decision to build WebGPU[1]. I was definitely being dramatic, but do think that Apple's overall vibe doesn't mesh well with open standards.
Caniuse says it's still behind a feature flag, are you sure you didn't enable that at some point?
https://webgpu.github.io/webgpu-samples/?sample=texturedCube
So definitely not enabled by default yet.
WebGPU is still in progress in Safari - it is available as a technology preview. The same is true for Firefox.
That's kind of the point, Chrome shipped it across multiple platforms two years ago, while Safari still has no timeframe despite having a much narrower set of APIs and hardware to support. Firefox at least has the excuse of needing broad compatibility like Chrome but with a fraction of the development resources. Apple are just dragging their feet.
Chrome ships a lot of things. Even now WebGPU is marked as experimental technology on MDN.
WebGPU didn't even become a Candidate Recommendation until December 2024 (half a year ago)
> Apple are just dragging their feet.
Or they are not in any rush to implement APIs that haven't reached consensus, haven't passed reviews, are subject to change etc. Chrome has very very cavalier attitude towards shipping APIs.
Chrome has routinely shipped junk APIs with no concern for privacy, security or battery life.
It's why fingerprinting works so incredibly well on their browsers.
When open source types complain about this, I always enjoy the irony that macOS is POSIX compliant while Linux is not.
Counterpoint: WebKit and Swift.