The interesting thing here is that Apple finally learned that games matter. Of course they go about it in the same "we're never wrong" attitude by never admitting it, like how their mice don't have two physical buttons to stay true to "a mouse should have one button" from the original Mac. They're learning though, it was voluntary unlike USB-C on their phones/tablets.
This indicates to me that the Apple Vision and visionOS product line and OS are not canceled internally and that Apple is still committed to its future.
While the Apple Vision Pro itself is not a good or successful product, progress in display technology will enable Apple to build a more attractive consumer product, in the form of light, comfortable and unobtrusive AR glasses.
In this line of thinking — not just focusing on the flopped AVP but looking at the product line on the long term - I think it makes sense for this OS to be added to Godot.
I do think the concern for who will carry the maintenance burden is valid. In my experience, Apple hasn’t been the most responsive company when it comes to obscure bugs or issues with their API (e.g. with Cocoa). I would be wary of depending on continued support from a large tech company that can change its goals at any time.
> 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?
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.
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.
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.
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.
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?
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.
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.
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.
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.
> 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.
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.
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.
> I would insist Apple conforms to the industry standard
Insisting Apple conforms to anything is useless, unless you're in control of government regulations.
You can stick to Apple's ridiculous custom APIs, or you can release your software without Apple support. Luckily, VisionOS seems to have gone the way of the Apple Pippin, so I don't think many people will care much about Apple's headsets not being supported by VR games. Apple certainly doesn't.
If Godot wants VisionOS support, this is probably the way to do it. The question then becomes: is an alteration this heavy worth the maintenance cost, especially for hardware that expensive and uncommon? You don't want to end up in a situation where the one guy with such a headset falls ill and suddenly you can't test your engine anymore without spending a couple thousand on new hardware.
It's a pretty well self regulating issue, isn't it? If there is no maintainer available, there's no market either, so it could be dropped. If there's enough people to develop for this expensive uncommon system, then surely there's enough money going round to pay someone.
Right now it looks like they have enough first party support and third party dyi efforts to at least give it a go.
Okay? That still doesn’t mitigate the need for this specific PR first though to even get to that discussion point. That line you mention is not part of the contents of this PR.
A good partner discusses startegy and shared interest first, negotiates terms of engagement, tradeoffs, shared roadmaps, etc.
Instead we get a pretty arrogant and presumptive interaction from the Apple crew.
It should be noted that Apple is struggling with visionOS and Pro adoption amongst consumers and developers, so their arrogance is unwarranted and they cannot rely on market power.
It feels like we're reading different discussions. All I see is Apple engineers addressing every raised concern.
Getting angry at companies for contributing to OSS is not the hill to die on. If it is -- I can't even imagine your feelings towards Intel, AMD, Qualcomm, Google, etc. for their contributions to Linux.
That’s what this PR is! It’s a first attempt to start that dialogue. You can even see the employee trying to address notes as they come in, and asking if there are better ways they should align with Godot.
Point to the arrogance involved. From all your comments I can see you have an intense distaste for Apple and I honestly feel it’s colouring your perception of this change.
The only person who seems upset is you. The Godot maintainers are positive, Miguel is positive.
Should contributors never open PRs until they’ve discussed it first? What if they want to get feedback on an idea in code form?
If Godot does nothing and insists that it's on Apple to to support OpenXR, then VR developers who want to support the Vision Pro will have to use Unity or Unreal or some other non-Godot engine. It achieves nothing other than to reduce Godot's relevance. Godot isn't big enough to pressure Apple.
I agree. I'm just saying that the result of responding "no, we won't accept this PR because we won't support visionOS until it supports OpenXR" only results in Godot not support ion visionOS. It doesn't result in visionOS gaining OpenXR support.
Now that doesn't mean it would be the wrong choice for the Godot project, they don't have to support visionOS.
I was so excited about the Vision and desperate to get one.
Finally my company has bought one for testing and I’m honestly not sure what to even use it for.
Maybe a big screen Mac? Is that it?
I think Apple has fallen into the same dead end they did with Apple TV: no controller = no games.
Both Apple TV and Vision Pro could have been filled with games from indie devs. But it’s impossible to play most games with a pinch or the worst TV control ever created.
> I was so excited about the Vision and desperate to get one. Finally my company has bought one for testing and I’m honestly not sure what to even use it for.
It’s nice to see this addition. I’m not sure if Godot would be better off bridging OpenXR to apple’s ar compositer or do as these PRs implement.
It isn’t much work to bridge from a metal renderer to the ar compositor. There are nice, if under documented c apis for Compositor Services in visionOS. I don’t think this will end up being a heavy maintenance burden, but they should donate some headsets as the second vertex amplification doesn’t run in the simulator. The max threads per thread group also differ. So real hardware is needed to measure performance.
“We already established above that the next paradigm is wearables. Wearables today, however, are very much in the pre-iPhone era. On one hand you have standalone platforms like Oculus, with its own operating system, app store, etc.; the best analogy is a video game console, which is technically a computer, but is not commonly thought of as such given its singular purpose. On the other hand, you have devices like smart watches, AirPods, and smart glasses, which are extensions of the phone; the analogy here is the iPod, which provided great functionality but was not a general computing device.
Now Apple might dispute this characterization in terms of the Vision Pro specifically, which not only has a PC-class M2 chip, along with its own visionOS operating system and apps, but can also run iPad apps. In truth, though, this makes the Vision Pro akin to Microsoft Mobile: yes, it is a capable device, but it is stuck in the wrong paradigm, i.e. the previous one that Apple dominated. Or, to put it another way, I don’t view “apps” as the bridge between mobile and wearables; apps are just the way we access the Internet on mobile, and the Internet was the old bridge, not the new one.”
This is surprising. From everything I've been hearing in the media, I got the impression Apple had mostly given up on their XR products and will keep them on life-support until the technology is ready for mass consumption.
The media loves to spin Apple things as failures right up until the point when they’re a success. See coverage of iPhone, Apple Pay, iPad, etc. Even “Apple faithful” media like MacRumors.com will be measured but pessimistic about Apple’s new efforts because negativity drives clicks more than positivity across the board.
Only an Apple fanboy would unironically think the media has an anti-Apple bias. And no, the fact that some people thought the iPhone would flop doesn't mean every product people are skeptical about will turn out to be a success.
There's more to development than just code. I'm sure the Godot developers value the contribution and will try to make the most of it, but they got zero input into how to implement it and this PR contains a lot of issues (e.g. it does some API breaking changes that can't just be done as-is.) On top of that, they have no idea (from the outset, I mean: obviously they are communicating now) if Apple intends to continue maintaining this code in the long run or if they just want to put the minimum amount of effort into shipping it and then consider that box checked, shifting the maintenance burden to volunteers. I don't think there needs to be intentional malice, even very nice gestures can work out poorly; we almost lost the Linux NTFS3 driver because Paragon initially stopped maintaining it and nobody else stepped up.
I think Apple can do good here but they should definitely communicate better. For open source, early and often is a good idea. (Though also good to follow through... I have been guilty of many licked cookies purely by accident and poor focus.)
There are many things that would be in Apple's interest to do, but they aren't so that's a complete non-argument.
I think it's a very valid question to ask, as many open source projects I've seen in the past that had to interface with Apple on the developer tooling front had to go through constant pain, as Apple isn't willing to e.g. provide references for certain .plist files, forcing many project to try and reverse-engineer what they do. More precisely there are usually people inside Apple willing to do that, but incapable to do that due to internal structures that result in a lack of clearly defined ownership.
So given that, I would say that if/once the original contributor of this PR moves on(/is made to move on) from that project, there is a good chance that this would also mark the end of cooperation from Apple's side.
The people making the latter comments are ignoring the contents of this PR however, and showing a lack of understanding of the engine itself in the process.
You cannot build this as an extension. It’s a different OS and Godot needs it to be done this way, as many people in the PR have commented as well. An extension would not cover it, and people suggesting that are probably used to the PC VR development model where VR is an extension of an existing supported platform, not a platform in and off itself.
Beyond that, even if Apple supported OpenXR, you’d still need this PR first because it’s covering build support first. It doesn’t cover any of the XR/Spatial rendering elements.
> VR development model where VR is an extension of an existing supported platform, not a platform in and off itself
This is the crux of the issue, both for Apple and for Godot.
In Apple’s case, they’re finding that their vision does not resonate with consumers or developers. So they’re searching for ways to expand chances of success but not entering with an equal partnership mentality. Thats their prerogative but I would argue the arrogance blinds them to reality.
From Godot’s perspective, the question is whether all this distraction is worth it for a platform that has for all intents and purposes failed to prove itself. There’s an opportunity cost and likely constraints that would flow from supporting Apple’s divergent and unproven vision.
In my books it seems clear that it would be a mistake for Godot to invest energy in supporting a niche, heretofore unsuccessful product that is not aligned with Godot’s technical and product roadmap.
I still don’t understand why I see people saying Vision is an unsuccessful and failed platform.
Vision Pro is very clearly an early adopter version of a platform that has yet to truly get started. Obviously, a huge $3500 headset on your head is not the actual intended final form of this platform. The actual intended final form is glasses.
And until those glasses are out you can’t say it failed, because it hasn’t even started yet.
As I understand things, proton allows windows games to just work (pun intended) on Linux. No porting, no rebuild - just download and run.
Who is going to bother doing all the extra work to port their game for Mac?! Time and time again there have been loads of articles on here over the years with developers saying it is simply not worth the hassle to support Linux and Mac.
The downside of relying on translation layers rather than porting from the perspective of Apple is likely that they vey much detest the lack of control that would result from that. Game devs targeting Linux have started viewing Proton/Windows runtime as a target, which has lead to native Linux ports becoming less common. As a person wanting to play the odd game on Linux, this has been a godsend, but for Apple, this would be viewed as an existential threat.
Personally, I'd wish for more extensive Vulkan support, but I have been informed that this is likely not as easily done considering Apples GPUs with TBDR differ somewhat from the industry standard.
At the end though, if Apple truly wanted, they could simply spent money on studios and incentives ports. None-Mobile-Gaming remains no priority for them, simple as that. I haven't seen any indication that the AVP has changed that in any way and I wouldn't be surprised if they view GoDot not as a game engine, but rather another way to create experiences.
The same folks that bother for iOS and iPad games, Nintendo Switch and PlayStation.
Most studios aren't religious about APIs like FOSS developers, they create API agnostic engines with plugabble backends and move on with what is relevant for their game IP.
It has been like this since the dawn of computer games being fully written in Assembly across 8 bit snowflakes.
And for additional context, when it comes to Vision Pro, Ubisoft has one game that is designed with it in mind (Rabbids: Legends of the Multiverse) and CAPCOM has none.
That should tell us something about the appetite to support visionOS.
Looks like Apple might be prioritizing gaming for the next gen Vision devices? Hopefully, as I know many, myself included that passed on the Vision because the gaming support wasn't there. Price was never an issue.
This to me smells of desperation - not so much as "prioritising gaming" and more "prioritising anyone making any kind of content at all please please please someone make something for our device".
It no more smells of desperation than when Apple contributed modern ScreenCaptureKit support to OBS Studio. They want great experiences for their own platforms and sometimes that means reaching out to other projects.
It's true that the Vision Pro hasn't seen the uptake that Apple's other platforms did at launch, like the iPhone, iPad, Apple Watch, etc. — but it's nearsighted to think that Apple can't play a long game. It has the patience (and money) to play it all the way to the eventual release of their glasses; by that time, the platform will already have plenty of fantastic software ported from iOS and, eventually, other platforms through ventures like this.
I think there is "playing the long game" and there is "flogging a dead horse".
I still can't believe that both apple and meta bet the farm on VR and screwed up so spectacularly. It was fairly clear that VR was never going to be mainstream for the same reasons that 3D movies and TVs vanished after all that fanfare and marketing a few years ago: people don't want to wear the glasses, and they don't want to pay extra either. We've been there and tried this - people are happy with 2D screens and don't see any real benefits of 3D glasses/headsets worth paying for (...apart from the nerdfactor).
Sure there might be some sort of market for "smart glasses" and people are continually releasing various iterations of those (and I'd be up for a pair too FWIW), but if the vision pro is any indication of what the tech is capable of today, we're a very very long way away from normal-glasses-style form factor units (i.e. size, weight, battery life, discreetness, price, nausea etc).
Tl;Dr - nice try doing something new, but if I were an apple investor I'd prefer they went back to what they knew and not waste further billions upon billions "playing the long game" on a dead-end because they can't accept they made a mistake.
You’re not looking very hard then because there are loads of new games released both with VR support and also exclusively for devices like the Oculus Quest.
What we’ve seen less of is AAA games bolt on VR support as an afterthought - and the reason for that is because it’s almost always a terrible way to play a game that was originally designed to be played with a keyboard and mouse, or traditional game controller.
My fear is that they won't treat godot first class and release updates for unity first.
That kind of first class support would be required for me to switch from unity.
"why this is not an extension" sounds like an awfully naive question. I'm not a Godot expert but I'd bet a very large amount of money that this is not in the realm of a simple extension, as flexible as Godot can be (and a check of the PR seems to confirm this)
Shiny. Unsolicited advice. visionOS is a distraction for the Godot team (whether or not you believe visionOS is a dead end or not). I would recommend focusing on high impact domains while Godot competitors like Unreal and Unity diffuse their attention.
If you officially support visionOS, it now requires all product and engineering innovation to take it into account, slowing down velocity for very little gain, if any.
It looks like Apple put their own people on this one.
If they want to maintain this, the Godot foundation needs to be extremely clear about that. You're talking about an extremely niche platform that will require tons of ongoing maintenance.
I would have hoped Apple also spent time working on the general engine and maybe tackling some bugs. Maybe they did maybe they didn't.
Apple TV for games is super niche, with very little market share in the big scheme of things.
Even when it comes to TV, Apple realized they had to create an Apple TV+ app for other platforms to extend the reach of their investment in shows/movies beyond their own hardware.
I think these connected to TV devices are a wasted opportunity for gaming. They are great for family type video games and with some marketing from apple or Google they could sell tons of games.
I happily paid for Beach Buggy, a Mario Kart type game, my kids are loving it and I think that the company makes a lot of money from this game alone.
But the support from Google is abysmal. No search functionality, developer hostility when trying to publish something etc.
There are however some games which thrive on apple tv. The virtual cycling game zwift is probably one of the most important apple tv games, it's the recommended system to get the game running on the cheap.
So, if you're making an app that benefits from a big screen and your customers are willing to buy a cheap dedicated device to easily use your app on a big screen, supporting apple tv might be a very sensible choice.
> if you're making an app that benefits from a big screen and your customers are willing to buy a cheap dedicated device to easily use your app on a big screen, supporting apple tv might be a very sensible choice.
Compared to other HDMI-connected devices (e.g. Google Streamer fka ChromeCast, Amazon FireTV, Roku) or major TV platforms like Android TV or Samsung and LG, the market share that Apple TV commands is dwarfed. Apple TV devices are also very expensive.
A startup like Zwift that bets on Apple TV as a key GTM strategy is making an error in judgment. Apple TV is extreme long tail footprint.
AppleTV is much more similar to a game console than the mentioned devices. It has a small set of powerful CPU/GPU/memory combos vs the menagerie of disparate and mostly much lower power hardware under the broad tent of “Google related tv platform” stuff.
Meh, I'd say it's a cheap addition when you already have to support iOS and iPadOS devices. Also market share is secondary if people are willing to buy it as a dedicated device and it is cheap (130$) when talking about people's expenditures for this hobby.
But yeah, I'm not an Insider and I'd love to know why they're supporting the apple tv but don't offer the Android App on the Google tv platform. Maybe something about non universal remote inputs or the wildly varying hw capabilities leading to support nightmares (but that's always an issue on Android).
> cheap addition when you already have to support iOS and iPadOS devices.
Presentation form factor and input modality is different on LRUD compared to touch, 10’ vs handheld.
There’s an opportunity cost: it is better to improve the user experience on the vast majority of TV devices (eg Samsung or Android TV or Fire tv) than it is to support a tiny market share device like Apple TV that you now also need to keep up to date.
If they could just let Geforce Now (NVIDIA Cloud gaming platform) ship a native app I would use my Apple TV much more. But no, they prefer to be extremely hostile to users over some app store bs.
Niche platform from one of the biggest companies on the planet isn’t as niche as others though. If there’s a way to get first party support from the vendor directly it could be beneficial to the other platforms too (iOS).
> it could be beneficial to the other platforms too (iOS).
In what way?
As far as I know, iOS support on Godot is almost entirely community-driven. If true, Godot has nothing to gain. Apple is struggling with adoption so they have most to gain from Godot support for visionOS, but is not obvious that visionOS support would benefit Godot in any strategic manner.
One strategic heuristic is that you don’t want to undertake the work to enable another company’s success on a product line, unless you depend on it or believe you have a strategic advantage against other competitors.
For example, if Godot negotiates for exclusivity or primary status for game engine positioning on visionOS and they believe VR is a material future footprint, that might be interesting. Anything less is in Apple’s favor and not in Godot’s.
> Apple; and they're eager to contribute back to it too.
To think Apple is interested in the success of Godot would be a mistake. It might feel like a compliment, but it would be a trap because Apple’s interest stems from increasing the chances of visionOS success and will be happy to externalize the ongoing maintenance tax to Godot.
Unless Godot feels they need visionOS then it isn’t in their interest to entertain Apple’s PR. If anything they should respond saying they already support standard interface in the form of OpenXR.
Did you get burned by a company contributing to an open source project before or what makes you so cynical about this PR? I feel like it's the ideal scenario that a company actually dedicates engineers and time to contribute to an open source project instead of doing their own thing, maybe even behind closed doors.
Have you contributed to Godot yourself or made something of note with it? Multiple developers are actively asking for visionOS support as people on the Godot team have mentioned. Why should your distaste for a platform preclude them from having platform support that would benefit the things they want to build?
Beyond that, have you even looked at the PR here to see what your supposed distraction would be? Most of the PR is shared infrastructure between the Apple embedded platforms.
> Why should your distaste for a platform preclude them from having platform support that would benefit the things they want to build?
They answered this in their initial comment:
> If you officially support visionOS, it now requires all product and engineering innovation to take it into account, slowing down velocity for very little gain, if any.
I'll leave this decision to the Godot maintainers but as an outside that only read the PR and comments it seems plausible that it's also in Apples favor to fix issues in the shared iOS / visionOS codebase that they are using, especially if they might come from Apple APIs that could be improved on their side too.
That's one of the things they are discussing in the comment chain. Apple hasn't directly addressed it yet. Seems like if they want this to be official, they ought to donate some headsets and money to offset the increased maintenance...
Apple has more to gain than does Godot. Money and headsets cannot faithfully account for additional complexity and coordination tax. Nevermind potential constraints on other platform expressions of the game engine.
What you want to do is first decide whether it is strategically valuable to be on this platform. If it is important, then you want to make sure there’s ROI in approach. Doing things in reverse, I.e. seeing whether there’s a cost-effective path to support another platform before deciding whether to support is is misguided in my opinion.
The PR to add the basic infrastructure for engine-level support was posted yesterday. There hasn't been enough time for anything to pass through App Store review yet, let alone all the work that has to happen before that, like writing and releasing the rest of the engine support for visionOS, and writing an application to use it.
Godot is open source. I'm sure, at least internally, Apple has tested these changes on one or more 'demo' apps. Any of which could be released as public demos.
If only had some sort of developer conference coming up in a little over a month. A conference where they release a bunch of demo and example projects. Well it's too bad no such thing exists.
It should probably be a plugin of some sort rather than built in the engine. It's a very small use case scenario and the devices are expensive and rare.
Like the comments said there are also concerns about maintaining it in the long term.
Having made games in Godot, I'm quite excited by the prospect of making the games within vision OS and playing them in a virtual 3D space. But Apple has only shown its vision for it and the future prospects are very uncertain due to the economic climate and affordability.
The interesting thing here is that Apple finally learned that games matter. Of course they go about it in the same "we're never wrong" attitude by never admitting it, like how their mice don't have two physical buttons to stay true to "a mouse should have one button" from the original Mac. They're learning though, it was voluntary unlike USB-C on their phones/tablets.
This indicates to me that the Apple Vision and visionOS product line and OS are not canceled internally and that Apple is still committed to its future.
While the Apple Vision Pro itself is not a good or successful product, progress in display technology will enable Apple to build a more attractive consumer product, in the form of light, comfortable and unobtrusive AR glasses.
In this line of thinking — not just focusing on the flopped AVP but looking at the product line on the long term - I think it makes sense for this OS to be added to Godot.
I do think the concern for who will carry the maintenance burden is valid. In my experience, Apple hasn’t been the most responsive company when it comes to obscure bugs or issues with their API (e.g. with Cocoa). I would be wary of depending on continued support from a large tech company that can change its goals at any time.
All that being said, this is exciting!
Can you read that much into it?
It seems equally possible that they're beginning to wind things down and they're just releasing what they've got to the public now.
Official upstreaming efforts are a significant investment even if they have internal PoCs. You can't just "release what you've got".
Godot already supports VR via OpenXR.
OpenXR is the Khronos-maintained industry standard for VR/AR devices—supported by SteamVR, Oculus, Vive, Pico, Windows Mixed Reality, Quest.
Notably absent is visionOS / Vision Pro.
I would insist Apple conforms to the industry standard. More scalable, open.
There is no need to have Apple conform to it, you can just expose the functionality, like this plugin does
https://github.com/jamuus/OpenVision/tree/main
Which was used by a community effort to bring VisionOS support to Godot:
https://github.com/jamuus/godot-vision
> 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.
> 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.
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?
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.
Forgetting about NVN and LibGNM/LibGNMX?
Because DirectX is a success and Metal is not.
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.
I am quite certain the folks selling iOS games see it otherwise.
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.
>Apple has made significant contributions to many open standards - for example, USB-C.
And then refused to use it until the EU forced them
USB-C has been in use on MacBooks for at least a decade.
Thank god they brought back MagSafe charging recently.
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.
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.
> That's why we're concerned when they abandon standards
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.
> It's a designed-by-committee API
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?
NVN on the Switch, PlayStation has two APIs, one high level and one low level one, LibGNMX and LibGNM respectively.
For some reason I can never remember those names :)
USB-C is not a Khronos standard.
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.
> OpenGL is quite dated for VR/AR.
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 would you rewrite everything a second time just a few years later?
Why is this the dichotomy? Why not support both?
Money
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.
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.
Ah, I guess that is why Nintendo and Sony also don't have games.
>This insistence on high-investment, low-ROI APIs is why the Mac doesn't have games
Yeah, that's why iOS doesn't have any games either. /s
> Hell would freeze over before Apple conformed and contributed to an existing open standard.
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.
I don’t know that that is relevant.
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.
You probably didn't see the comment I was replying to. I should have quoted:
> Hell would freeze over before Apple conformed and contributed to an existing open standard.
This is patently false given the fact I posted.
I don't see how you can say it's patently false. Do you have any proof that hell didn't freeze over before then?
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.
> 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.
[1]: https://www.theregister.com/2017/02/08/apple_webgpu/
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.
WebGPU works just fine in Safari on my iPhone. It was enabled by default starting with iOS 18.2.
https://caniuse.com/webgpu
Caniuse says it's still behind a feature flag, are you sure you didn't enable that at some point?
I don’t recall enabling it.
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.)
Because getting angry about things that are false is insane.
WebGPU is still in progress in Safari - it is available as a technology preview. The same is true for Firefox.
> WebGPU is still in progress in Safari
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 shipped it across multiple platforms
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.
> 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.
Correct... But from my understanding... OpenXR isnt reliant on OpenGL? it supports Vulkan, DirectX and metal -- https://github.com/godotengine/godot/pull/98872
> I would insist Apple conforms to the industry standard
Insisting Apple conforms to anything is useless, unless you're in control of government regulations.
You can stick to Apple's ridiculous custom APIs, or you can release your software without Apple support. Luckily, VisionOS seems to have gone the way of the Apple Pippin, so I don't think many people will care much about Apple's headsets not being supported by VR games. Apple certainly doesn't.
If Godot wants VisionOS support, this is probably the way to do it. The question then becomes: is an alteration this heavy worth the maintenance cost, especially for hardware that expensive and uncommon? You don't want to end up in a situation where the one guy with such a headset falls ill and suddenly you can't test your engine anymore without spending a couple thousand on new hardware.
Apple wants Godot to support the Vision Pro, hence the PR. Hence Godot has some leverage here (though possibly not enough).
> VisionOS seems to have gone the way of the Apple Pippin
There are rumours indicating that they working on multiple new models including one designed for tethering to the Mac:
https://www.macrumors.com/2025/04/13/vision-pro-2-two-rumore...
It's a pretty well self regulating issue, isn't it? If there is no maintainer available, there's no market either, so it could be dropped. If there's enough people to develop for this expensive uncommon system, then surely there's enough money going round to pay someone.
Right now it looks like they have enough first party support and third party dyi efforts to at least give it a go.
This would get you, maybe, VR/AR games/apps running on the device.
The PR from Apple also adds support for "flat" Godot games/apps running on Vision Pro.
This PR specifically is about getting Godot able to build for visionOS.
Even if Godot insisted on needing OpenXR support , you’d still need to land this PR to get the engine itself to work first.
Apple has no intention of fitting within godot’s GTM strategy for VR via OpenXR standard.
Amongst other signals, the PR comment says: “To support creating Immersive experiences by using a new Godot's visionOS VR Plugin.”
Okay? That still doesn’t mitigate the need for this specific PR first though to even get to that discussion point. That line you mention is not part of the contents of this PR.
A good partner discusses startegy and shared interest first, negotiates terms of engagement, tradeoffs, shared roadmaps, etc.
Instead we get a pretty arrogant and presumptive interaction from the Apple crew.
It should be noted that Apple is struggling with visionOS and Pro adoption amongst consumers and developers, so their arrogance is unwarranted and they cannot rely on market power.
> Instead we get a pretty arrogant and presumptive interaction from the Apple crew.
You're being completely ridiculous here. It's a well-written, considered, appropriate for the project PR.
No one is being forced at gun point to accept it.
How is it arrogant? What should they do instead?
It feels like we're reading different discussions. All I see is Apple engineers addressing every raised concern.
Getting angry at companies for contributing to OSS is not the hill to die on. If it is -- I can't even imagine your feelings towards Intel, AMD, Qualcomm, Google, etc. for their contributions to Linux.
That’s what this PR is! It’s a first attempt to start that dialogue. You can even see the employee trying to address notes as they come in, and asking if there are better ways they should align with Godot.
Point to the arrogance involved. From all your comments I can see you have an intense distaste for Apple and I honestly feel it’s colouring your perception of this change.
The only person who seems upset is you. The Godot maintainers are positive, Miguel is positive.
Should contributors never open PRs until they’ve discussed it first? What if they want to get feedback on an idea in code form?
If Godot does nothing and insists that it's on Apple to to support OpenXR, then VR developers who want to support the Vision Pro will have to use Unity or Unreal or some other non-Godot engine. It achieves nothing other than to reduce Godot's relevance. Godot isn't big enough to pressure Apple.
Considering install base, I'd figure the Vision Pro isn't big enough to pressure Godot.
Apple is big enough to sponsor Godot and should if they want to burden their maintainers with extra work long term.
I agree. I'm just saying that the result of responding "no, we won't accept this PR because we won't support visionOS until it supports OpenXR" only results in Godot not support ion visionOS. It doesn't result in visionOS gaining OpenXR support.
Now that doesn't mean it would be the wrong choice for the Godot project, they don't have to support visionOS.
Both users of visionOS are happy about this announcement.
This is sad but true.
I was so excited about the Vision and desperate to get one.
Finally my company has bought one for testing and I’m honestly not sure what to even use it for.
Maybe a big screen Mac? Is that it?
I think Apple has fallen into the same dead end they did with Apple TV: no controller = no games.
Both Apple TV and Vision Pro could have been filled with games from indie devs. But it’s impossible to play most games with a pinch or the worst TV control ever created.
> I was so excited about the Vision and desperate to get one. Finally my company has bought one for testing and I’m honestly not sure what to even use it for.
This is the VR experience, yup :)
> no controller = no games.
Bundling a controller would increase the cost for everyone to satisfy a minority of gamers.
So instead they support all PS5, Xbox, BT etc controllers.
Pretty much:
- big screen mac
- 3d movie viewing (the experience is actually mind-blowing)
It’s nice to see this addition. I’m not sure if Godot would be better off bridging OpenXR to apple’s ar compositer or do as these PRs implement.
It isn’t much work to bridge from a metal renderer to the ar compositor. There are nice, if under documented c apis for Compositor Services in visionOS. I don’t think this will end up being a heavy maintenance burden, but they should donate some headsets as the second vertex amplification doesn’t run in the simulator. The max threads per thread group also differ. So real hardware is needed to measure performance.
https://developer.apple.com/documentation/compositorservices...
Interesting piece from Ben Thomson regarding Apple’s troubles in AI. He says this of Vision Pro:
https://stratechery.com/2025/apple-and-the-ghosts-of-compani...
“We already established above that the next paradigm is wearables. Wearables today, however, are very much in the pre-iPhone era. On one hand you have standalone platforms like Oculus, with its own operating system, app store, etc.; the best analogy is a video game console, which is technically a computer, but is not commonly thought of as such given its singular purpose. On the other hand, you have devices like smart watches, AirPods, and smart glasses, which are extensions of the phone; the analogy here is the iPod, which provided great functionality but was not a general computing device.
Now Apple might dispute this characterization in terms of the Vision Pro specifically, which not only has a PC-class M2 chip, along with its own visionOS operating system and apps, but can also run iPad apps. In truth, though, this makes the Vision Pro akin to Microsoft Mobile: yes, it is a capable device, but it is stuck in the wrong paradigm, i.e. the previous one that Apple dominated. Or, to put it another way, I don’t view “apps” as the bridge between mobile and wearables; apps are just the way we access the Internet on mobile, and the Internet was the old bridge, not the new one.”
This is surprising. From everything I've been hearing in the media, I got the impression Apple had mostly given up on their XR products and will keep them on life-support until the technology is ready for mass consumption.
The media loves to spin Apple things as failures right up until the point when they’re a success. See coverage of iPhone, Apple Pay, iPad, etc. Even “Apple faithful” media like MacRumors.com will be measured but pessimistic about Apple’s new efforts because negativity drives clicks more than positivity across the board.
Only an Apple fanboy would unironically think the media has an anti-Apple bias. And no, the fact that some people thought the iPhone would flop doesn't mean every product people are skeptical about will turn out to be a success.
Actively working on Vision Pro 2:
https://www.macrumors.com/2025/04/13/vision-pro-2-two-rumore...
Until things are officially announced they could change at any moment. Rumor mills are rarely productive.
Insane that Apple put this PR up without at all contributing to the development fund.
Didn't even put up an issue first haha.
If they did the work, what’s wrong with that?
Maintainers have to review the PR, answer Apple's "Open Questions", and support their users who want to build with the new functionality long term.
Laughably, it looks like the PR didn't even compile...[1]
> When you try and bundle, it will fail. The library paths are incorrect.
[1]: https://github.com/godotengine/godot/pull/105628#pullrequest...
Apple really are not sending their finest.
There's more to development than just code. I'm sure the Godot developers value the contribution and will try to make the most of it, but they got zero input into how to implement it and this PR contains a lot of issues (e.g. it does some API breaking changes that can't just be done as-is.) On top of that, they have no idea (from the outset, I mean: obviously they are communicating now) if Apple intends to continue maintaining this code in the long run or if they just want to put the minimum amount of effort into shipping it and then consider that box checked, shifting the maintenance burden to volunteers. I don't think there needs to be intentional malice, even very nice gestures can work out poorly; we almost lost the Linux NTFS3 driver because Paragon initially stopped maintaining it and nobody else stepped up.
I think Apple can do good here but they should definitely communicate better. For open source, early and often is a good idea. (Though also good to follow through... I have been guilty of many licked cookies purely by accident and poor focus.)
Are they going to do the ongoing maintenance if this is merged in?
Looks like it would be in their interest to do so, so yeah I don’t see why not.
There are many things that would be in Apple's interest to do, but they aren't so that's a complete non-argument.
I think it's a very valid question to ask, as many open source projects I've seen in the past that had to interface with Apple on the developer tooling front had to go through constant pain, as Apple isn't willing to e.g. provide references for certain .plist files, forcing many project to try and reverse-engineer what they do. More precisely there are usually people inside Apple willing to do that, but incapable to do that due to internal structures that result in a lack of clearly defined ownership.
So given that, I would say that if/once the original contributor of this PR moves on(/is made to move on) from that project, there is a good chance that this would also mark the end of cooperation from Apple's side.
This question is asked and answered in the linked PR thread.
Reading a lot of comments it sounds like Apple should:
1. Give Godot some money.
2. Implement visionOS support via an extension not directly into core OR conform to industry standard OpenXR.
The people making the latter comments are ignoring the contents of this PR however, and showing a lack of understanding of the engine itself in the process.
You cannot build this as an extension. It’s a different OS and Godot needs it to be done this way, as many people in the PR have commented as well. An extension would not cover it, and people suggesting that are probably used to the PC VR development model where VR is an extension of an existing supported platform, not a platform in and off itself.
Beyond that, even if Apple supported OpenXR, you’d still need this PR first because it’s covering build support first. It doesn’t cover any of the XR/Spatial rendering elements.
>You cannot build this as an extension. It’s a different OS and Godot needs it to be done this way,
How does support for platforms like the nintendo switch work?
> VR development model where VR is an extension of an existing supported platform, not a platform in and off itself
This is the crux of the issue, both for Apple and for Godot.
In Apple’s case, they’re finding that their vision does not resonate with consumers or developers. So they’re searching for ways to expand chances of success but not entering with an equal partnership mentality. Thats their prerogative but I would argue the arrogance blinds them to reality.
From Godot’s perspective, the question is whether all this distraction is worth it for a platform that has for all intents and purposes failed to prove itself. There’s an opportunity cost and likely constraints that would flow from supporting Apple’s divergent and unproven vision.
In my books it seems clear that it would be a mistake for Godot to invest energy in supporting a niche, heretofore unsuccessful product that is not aligned with Godot’s technical and product roadmap.
I still don’t understand why I see people saying Vision is an unsuccessful and failed platform.
Vision Pro is very clearly an early adopter version of a platform that has yet to truly get started. Obviously, a huge $3500 headset on your head is not the actual intended final form of this platform. The actual intended final form is glasses.
And until those glasses are out you can’t say it failed, because it hasn’t even started yet.
Apple should flick Godot a chunk of change to properly get this rolling.
What Apple should do is drive a truckload of money on Valve's doorstep and get a Proton-like system built for M-series Macs.
They have done that.
They gave some cash money to CodeWeavers, the company that created wine. It's called the Game Porting Toolkit: https://developer.apple.com/games/game-porting-toolkit/
As far as I know, CodeWeavers was not involved in that project:
> We did not work with Apple on this tool
https://www.codeweavers.com/blog/mjohnson/2023/6/6/wine-come...
That's the problem I think: porting.
As I understand things, proton allows windows games to just work (pun intended) on Linux. No porting, no rebuild - just download and run.
Who is going to bother doing all the extra work to port their game for Mac?! Time and time again there have been loads of articles on here over the years with developers saying it is simply not worth the hassle to support Linux and Mac.
The downside of relying on translation layers rather than porting from the perspective of Apple is likely that they vey much detest the lack of control that would result from that. Game devs targeting Linux have started viewing Proton/Windows runtime as a target, which has lead to native Linux ports becoming less common. As a person wanting to play the odd game on Linux, this has been a godsend, but for Apple, this would be viewed as an existential threat.
Personally, I'd wish for more extensive Vulkan support, but I have been informed that this is likely not as easily done considering Apples GPUs with TBDR differ somewhat from the industry standard.
At the end though, if Apple truly wanted, they could simply spent money on studios and incentives ports. None-Mobile-Gaming remains no priority for them, simple as that. I haven't seen any indication that the AVP has changed that in any way and I wouldn't be surprised if they view GoDot not as a game engine, but rather another way to create experiences.
The same folks that bother for iOS and iPad games, Nintendo Switch and PlayStation.
Most studios aren't religious about APIs like FOSS developers, they create API agnostic engines with plugabble backends and move on with what is relevant for their game IP.
It has been like this since the dawn of computer games being fully written in Assembly across 8 bit snowflakes.
>Who is going to bother doing all the extra work to port their game for Mac?!
So far at least Ubisoft, CAPCOM, Remedy, Kojima Productions and Hello Games.
And for additional context, when it comes to Vision Pro, Ubisoft has one game that is designed with it in mind (Rabbids: Legends of the Multiverse) and CAPCOM has none.
That should tell us something about the appetite to support visionOS.
Exactly the same thing happened with iPhone, iPad, Apple TV and Apple Watch.
It's Vision Pro 1. Maybe let's see how the next revision goes first.
Most companies don't support visionOS because it is a 3000 euros/dollar device, that really has to sell a lot of games.
Additionally many developers are not porting their games to visionOS as protest to existing store percentages, nothing to do with Metal support.
Looks like Apple might be prioritizing gaming for the next gen Vision devices? Hopefully, as I know many, myself included that passed on the Vision because the gaming support wasn't there. Price was never an issue.
This to me smells of desperation - not so much as "prioritising gaming" and more "prioritising anyone making any kind of content at all please please please someone make something for our device".
It no more smells of desperation than when Apple contributed modern ScreenCaptureKit support to OBS Studio. They want great experiences for their own platforms and sometimes that means reaching out to other projects.
It's true that the Vision Pro hasn't seen the uptake that Apple's other platforms did at launch, like the iPhone, iPad, Apple Watch, etc. — but it's nearsighted to think that Apple can't play a long game. It has the patience (and money) to play it all the way to the eventual release of their glasses; by that time, the platform will already have plenty of fantastic software ported from iOS and, eventually, other platforms through ventures like this.
I think there is "playing the long game" and there is "flogging a dead horse".
I still can't believe that both apple and meta bet the farm on VR and screwed up so spectacularly. It was fairly clear that VR was never going to be mainstream for the same reasons that 3D movies and TVs vanished after all that fanfare and marketing a few years ago: people don't want to wear the glasses, and they don't want to pay extra either. We've been there and tried this - people are happy with 2D screens and don't see any real benefits of 3D glasses/headsets worth paying for (...apart from the nerdfactor).
Sure there might be some sort of market for "smart glasses" and people are continually releasing various iterations of those (and I'd be up for a pair too FWIW), but if the vision pro is any indication of what the tech is capable of today, we're a very very long way away from normal-glasses-style form factor units (i.e. size, weight, battery life, discreetness, price, nausea etc).
Tl;Dr - nice try doing something new, but if I were an apple investor I'd prefer they went back to what they knew and not waste further billions upon billions "playing the long game" on a dead-end because they can't accept they made a mistake.
> flogging a dead horse
It's the first version of their XR device.
I still own the first iPod, iPhone and Apple Watch and remember people saying that each one would be failures.
Does anyone in the industry care about VR gaming right now?
I don't see people buying headsets, I don't see VR features in new major games, it's just not a thing outside of a probably shrinking niche.
Lookup GorillaTag a surprise smash hit that made half $1 billion(!) revenue on the Meta quest!
You’re not looking very hard then because there are loads of new games released both with VR support and also exclusively for devices like the Oculus Quest.
What we’ve seen less of is AAA games bolt on VR support as an afterthought - and the reason for that is because it’s almost always a terrible way to play a game that was originally designed to be played with a keyboard and mouse, or traditional game controller.
It would be strange if they went about it this way, as it gives the godot community some unprecedented control over apple's release schedule
My fear is that they won't treat godot first class and release updates for unity first. That kind of first class support would be required for me to switch from unity.
Back in the day when Microsoft dominated everything, we would have said embrace, extend, extinguish.
VisionOS doesn't dominate anything.
Jeez, some people are just insufferable
I'm glad some people like https://github.com/godotengine/godot/pull/105628#issuecommen... exists
"why this is not an extension" sounds like an awfully naive question. I'm not a Godot expert but I'd bet a very large amount of money that this is not in the realm of a simple extension, as flexible as Godot can be (and a check of the PR seems to confirm this)
Shiny. Unsolicited advice. visionOS is a distraction for the Godot team (whether or not you believe visionOS is a dead end or not). I would recommend focusing on high impact domains while Godot competitors like Unreal and Unity diffuse their attention.
If you officially support visionOS, it now requires all product and engineering innovation to take it into account, slowing down velocity for very little gain, if any.
It looks like Apple put their own people on this one.
If they want to maintain this, the Godot foundation needs to be extremely clear about that. You're talking about an extremely niche platform that will require tons of ongoing maintenance.
I would have hoped Apple also spent time working on the general engine and maybe tackling some bugs. Maybe they did maybe they didn't.
And since Apple is here, please help adding support for Apple TV. Apple and Android TV support sometimes makes the difference when choosing an engine.
Apple TV for games is super niche, with very little market share in the big scheme of things.
Even when it comes to TV, Apple realized they had to create an Apple TV+ app for other platforms to extend the reach of their investment in shows/movies beyond their own hardware.
I think these connected to TV devices are a wasted opportunity for gaming. They are great for family type video games and with some marketing from apple or Google they could sell tons of games. I happily paid for Beach Buggy, a Mario Kart type game, my kids are loving it and I think that the company makes a lot of money from this game alone.
But the support from Google is abysmal. No search functionality, developer hostility when trying to publish something etc.
There are however some games which thrive on apple tv. The virtual cycling game zwift is probably one of the most important apple tv games, it's the recommended system to get the game running on the cheap.
So, if you're making an app that benefits from a big screen and your customers are willing to buy a cheap dedicated device to easily use your app on a big screen, supporting apple tv might be a very sensible choice.
> if you're making an app that benefits from a big screen and your customers are willing to buy a cheap dedicated device to easily use your app on a big screen, supporting apple tv might be a very sensible choice.
Compared to other HDMI-connected devices (e.g. Google Streamer fka ChromeCast, Amazon FireTV, Roku) or major TV platforms like Android TV or Samsung and LG, the market share that Apple TV commands is dwarfed. Apple TV devices are also very expensive.
A startup like Zwift that bets on Apple TV as a key GTM strategy is making an error in judgment. Apple TV is extreme long tail footprint.
AppleTV is much more similar to a game console than the mentioned devices. It has a small set of powerful CPU/GPU/memory combos vs the menagerie of disparate and mostly much lower power hardware under the broad tent of “Google related tv platform” stuff.
Meh, I'd say it's a cheap addition when you already have to support iOS and iPadOS devices. Also market share is secondary if people are willing to buy it as a dedicated device and it is cheap (130$) when talking about people's expenditures for this hobby.
But yeah, I'm not an Insider and I'd love to know why they're supporting the apple tv but don't offer the Android App on the Google tv platform. Maybe something about non universal remote inputs or the wildly varying hw capabilities leading to support nightmares (but that's always an issue on Android).
> cheap addition when you already have to support iOS and iPadOS devices.
Presentation form factor and input modality is different on LRUD compared to touch, 10’ vs handheld.
There’s an opportunity cost: it is better to improve the user experience on the vast majority of TV devices (eg Samsung or Android TV or Fire tv) than it is to support a tiny market share device like Apple TV that you now also need to keep up to date.
arent all apps just expo react webui wrappers nowadays?
We are specifically talking about 3D games here.
> Apple TV for games is super niche
Order(s) of magnitude less niche than Apple Vision.
If they could just let Geforce Now (NVIDIA Cloud gaming platform) ship a native app I would use my Apple TV much more. But no, they prefer to be extremely hostile to users over some app store bs.
You can still use moonlight.
> Apple TV for games is super niche,
Apple TV is just a tale of so many missed opportunities.
They already said they plan to do this in the PR.
One of the comments says another team is working on Apple TV.
Even debating support for a niche platform is a distraction. Noise.
Niche platform from one of the biggest companies on the planet isn’t as niche as others though. If there’s a way to get first party support from the vendor directly it could be beneficial to the other platforms too (iOS).
> it could be beneficial to the other platforms too (iOS).
In what way?
As far as I know, iOS support on Godot is almost entirely community-driven. If true, Godot has nothing to gain. Apple is struggling with adoption so they have most to gain from Godot support for visionOS, but is not obvious that visionOS support would benefit Godot in any strategic manner.
One strategic heuristic is that you don’t want to undertake the work to enable another company’s success on a product line, unless you depend on it or believe you have a strategic advantage against other competitors.
For example, if Godot negotiates for exclusivity or primary status for game engine positioning on visionOS and they believe VR is a material future footprint, that might be interesting. Anything less is in Apple’s favor and not in Godot’s.
>As far as I know, iOS support on Godot is almost entirely community-driven.
Yes, and now it has gotten to the point where it clearly has been noticed by Apple; and they're eager to contribute back to it too.
Is that not... the ideal scenario here? You have community contribute a port for a big platform, the company notices, and starts contributing too.
> Apple; and they're eager to contribute back to it too.
To think Apple is interested in the success of Godot would be a mistake. It might feel like a compliment, but it would be a trap because Apple’s interest stems from increasing the chances of visionOS success and will be happy to externalize the ongoing maintenance tax to Godot.
Unless Godot feels they need visionOS then it isn’t in their interest to entertain Apple’s PR. If anything they should respond saying they already support standard interface in the form of OpenXR.
Did you get burned by a company contributing to an open source project before or what makes you so cynical about this PR? I feel like it's the ideal scenario that a company actually dedicates engineers and time to contribute to an open source project instead of doing their own thing, maybe even behind closed doors.
I’m invested in the success of Godot and fear the visionOS distraction dilutes the urgency that’s needed to compete with Unreal and Unity.
Additionally, if Godot accepts this PR and related ongoing work, it would signal to me poor strategic judgment.
Many an open source project progress slows down under the burden of supporting immaterial platforms.
Have you contributed to Godot yourself or made something of note with it? Multiple developers are actively asking for visionOS support as people on the Godot team have mentioned. Why should your distaste for a platform preclude them from having platform support that would benefit the things they want to build?
Beyond that, have you even looked at the PR here to see what your supposed distraction would be? Most of the PR is shared infrastructure between the Apple embedded platforms.
> Why should your distaste for a platform preclude them from having platform support that would benefit the things they want to build?
They answered this in their initial comment:
> If you officially support visionOS, it now requires all product and engineering innovation to take it into account, slowing down velocity for very little gain, if any.
Yes
I'll leave this decision to the Godot maintainers but as an outside that only read the PR and comments it seems plausible that it's also in Apples favor to fix issues in the shared iOS / visionOS codebase that they are using, especially if they might come from Apple APIs that could be improved on their side too.
exclusivity ?? its an open source project why would they want that, its not a competition :p
Godot is absolutely in competition with other game engines.
That's one of the things they are discussing in the comment chain. Apple hasn't directly addressed it yet. Seems like if they want this to be official, they ought to donate some headsets and money to offset the increased maintenance...
Apple has more to gain than does Godot. Money and headsets cannot faithfully account for additional complexity and coordination tax. Nevermind potential constraints on other platform expressions of the game engine.
What you want to do is first decide whether it is strategically valuable to be on this platform. If it is important, then you want to make sure there’s ROI in approach. Doing things in reverse, I.e. seeing whether there’s a cost-effective path to support another platform before deciding whether to support is is misguided in my opinion.
Just because you can doesn’t mean you should.
TLDR; We hate Epic and Unreal, can we be friends pllleeeeaaassseeee.
[flagged]
Good on Apple.
Are there any apps from this project available in the visionos App Store yet?
The PR to add the basic infrastructure for engine-level support was posted yesterday. There hasn't been enough time for anything to pass through App Store review yet, let alone all the work that has to happen before that, like writing and releasing the rest of the engine support for visionOS, and writing an application to use it.
smh, game devs always with the excuses
where are the mythical 100x engineers when you need them most
Burned by Apple and boycotting this ;)
My guy it's not even merged yet
Godot is open source. I'm sure, at least internally, Apple has tested these changes on one or more 'demo' apps. Any of which could be released as public demos.
Yes, Apple is a company that is famously known for publicly releasing demos and proofs of concepts; especially around games.
If only had some sort of developer conference coming up in a little over a month. A conference where they release a bunch of demo and example projects. Well it's too bad no such thing exists.
It should probably be a plugin of some sort rather than built in the engine. It's a very small use case scenario and the devices are expensive and rare.
Like the comments said there are also concerns about maintaining it in the long term.
Having made games in Godot, I'm quite excited by the prospect of making the games within vision OS and playing them in a virtual 3D space. But Apple has only shown its vision for it and the future prospects are very uncertain due to the economic climate and affordability.
This is discussed in the PR comments - it's a separate OS and will necessitate changes to core.