> The visionOS platform doesn't have OpenGL support, as it's not supported by visionOS.
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.
> Hell would freeze over before Apple conformed and contributed to an existing open standard.
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.
> The graphics division - these days - seems very intent on doing their own thing.
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.
Not relevant. The VisionOS crew have decided to not support OpenXR and Apple has broadly decided not to support Vulkan, which, together with DirectX are the primary VR rendering technologies.
Not relevant to what? I think we’re talking past each other.
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.
> The VisionOS crew have decided to not support OpenXR and Apple has broadly decided not to support Vulkan
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?
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.
Even without a standard, people will create abstractions on top so all you need to do is add support to those abstractions. If needing to conform to a standard was hampering Apple's ability to get developers to make software for their platforms they would add support. It's obviously not materially affecting them.
I think this whole thread is besides the point anyway.
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.
Most of those games could be written to run on a toaster. Most of those games are written by people who use Unity, so they don't really care about the underlying system and may not even understand what Metal is at all.
The reality is that virtual reality and gaming technology have largely converged on DirectX and Vulkan for rendering.
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.
I think people are (rightfully) upset at the business-oriented decisions that limit MacOS as a platform, prevent competition on iOS and demand annual tithes from their developers like they're peons tilling land for coin. These are fair criticisms, prosecuted in a few courts even, and well within the realm of reasonable change.
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.
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?
I lost a Mac laptop in the pre-MagSafe days, to a bullpen environment –a sysadmin was rushing to a meeting, snagged his foot, and took the cable and the laptop off the desk at high speeds.
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.
I agree with you, but in practice I've never had a problem with USB-C at all and everything mobile I own has USB-C except my face trimmer, and the next one will be USB-C for sure.
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.
Come on. USB-C has been shipped on MacBooks since 2015, and most of their other systems since ~2020. Heck they caught a bunch of flack when they killed MagSafe on their MacBooks and went USB-C only (not just for the lack of mag safe, but also plenty of grief for lack of Ethernet and HDMI too). With or without the EU mandates they were clearly on a trend moving their devices to USB-C
OpenGL is quite dated for VR/AR. In the Apple ecosystem they supported OpenGL 4.1 for quite some time before moving to Metal, which was announced 2 years before Vulkan.
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.
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.
> 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?
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].
In an ideal world, Apple would have just built DirectX and sold the Xbox too. But you can't look at it from an executive's perspective, you have to look at it from the developer's point-of-view. This insistence on high-investment, low-ROI APIs is why the Mac doesn't have games. If you run the Metal playbook with VR again, you will have developers outright abandon you. We've already seen what happens.
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.
APIs are the last reason there aren't 'major' games on macOS. You've got architecture changes; PPC to Intel was a big loss of game compatibility, and then again when x86-32 support was removed from OS X nuked most of a user's Steam library.
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.
APIs are the exact reason. Why can't you run Proton on MacOS? WoW64 works. Rosetta and Wine work. Is there any technical limitation besides API support preventing the Macbook from working like a Steam Deck?
Proton relies on Linux sys APIs not available on macOS, but the Porting Toolkit is available. I've been able to "play" Noita on my M2 Air (granted the perf sucks, but that's what I get for owning an Air). This discussion hasn't been centered around kernel APIs, but rather graphics APIs (D3D/Vulkan), if you're going for that "gotcha!".
Crossover is another option, though I have no need to pay for it as I own a Windows PC/consoles.
It’s more that devs can’t be arsed to write non-mobile games in anything but DirectX unless they’re being paid to (as the console vendors do). Vulkan support is quite rare in commercial games, it’s almost entirely DirectX or Sony/Nintendo’s things. If Apple somehow flipped a switch that turned on Vulkan support, almost nothing would change.
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.
> If Apple somehow flipped a switch that turned on Vulkan support, almost nothing would change.
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.
The bigger point is that the Metal-only route isn't working.
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.
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.
An excellent comment for it's humor value. (not to ruin the humor with an explanation, but this is a masterful use of sophistry as it's logically sound, but clearly not a serious argument).
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:
Ahhh Khronos. Lovely Fahrenheit where Microsoft strung SGI along to make Fahrenheit fail (now Open Scene Graph) and incorporate the IP in Direct3D..
Shitty tactics.
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.
It's my impression that the WebGPU spec design team went to extreme lengths to accommodate Apple's wishes, and Apple in turn does not even support WebGPU in Safari. Why not express vitriol? Apple does not seem to act in good faith.
Confirmed my M1 iPad Pro iOS 18.4.1 also doesn’t have it enabled. Took a bit of digging in the settings app to discover where to enable feature flags too, confirmed it’s off.
It’s disabled still on my iPhone on iOS 18.4.1. Either it was enabled specifically on 18.2, and then disabled, or you enabled it manually. (Or some other weird thing, like it’s only enabled on iPhone Pros.)
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.
> That's kind of the point, Chrome shipped it across multiple platforms two years ago
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.
> Cross-platform dev is for low-rent chumps, unless it's our cross-platform dev
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.
Those are fantastic examples.
At the same time it begs the question: why does Apple not play nicely with graphics standards? It could be that the those standards bodies are dysfunctional or too slow so Apple has to go their own way. However, I suspect that that is not the main reason.
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.