visionos — Image courtesy Apple

Apple is Adding visionOS Support to Open-source Game Engine to Expand Development Options

By

-

Apr 28, 2025

In a rare move, Apple is directly adding support for its visionOS platform to the Godot open-source game engine. The move expands the range of tools that developers can use to build content for the headset.

Like the popular Unity and Unreal game engines, Godot is a collection of development tools that make it easy for developers to build real-time games and applications. Unlike the other two, Godot is fully open-source, meaning anyone can use the engine and distribute games built with it free of charge. Because it’s open source, developers can also contribute features and fixes to the engine for all to use.

In a rare move for Apple, the company is directly adding visionOS support to Godot, making it possible for developers to build and distribute Vision Pro content with the engine.

Apple software engineer Ricardo Sanchez-Saez recently shared the company’s plans to add visionOS support to Godot as an open-source contribution. He said the feature would come in two major parts, with the first set to allow games built with Godot to run in flat windows on visionOS, and a second to add support for building fully immersive visionOS applications with the engine.

Because of the open-source process, it will take some time for Apple’s contributions to get rolled into the production version of Godot, and there’s no hard timeline for the completion of the project.

'Virtual Skate' to Bring Realistic Multiplayer Skateboarding to Quest 3 & PC VR, Trailer Here

Godot will join the likes of Unity, Unreal Engine, and first-party Apple tools like X-code, and Reality Composer Pro as a way for developers to build applications for Vision Pro.

Godot can also be used to build apps for major VR platforms like Quest and PC VR.

Christian Schildwaechter

TL;DR: This is very good news. Godot development for AVP will be free (Unity requires a Pro license); the Godot editor already runs inside of Quest, making it the sole option to create VR experiences inside the HMD after Meta killed the Horizon Worlds editor; there are still a lot of obstacles, but these changes coming from Apple themselves hint that they are interested in overcoming them.

This is great for a number of reasons. For one Godot itself is a great engine, even though it cannot yet compete regarding 3D performance with Unity or Unreal Engine, and the XR part is also still pretty new. Godot has been mostly used for 2D games in the past, so this is where most of its strength lies, but it is evolving rather quickly.

Godot is mainly programmed in GDScript, a very terse and beginner friendly Python-like scripting language that again adds another performance hit compared to other engines. You can write code in C#, just like in Unity, but IMHO the real benefit of Godot for VR is the fast iteration time for experimentation, not replacing Unity as the engine used for the majority of VR games and experiences. On AVP Godot has a significant advantage though, as developing for AVP requires a Unity Pro license with yearly costs of USD 2200 per seat, while writing apps for Quest etc. works with the free tier.

This may change with future non-pro Vision models. When the Oculus DK1 released, it also required a Unity Pro license (three months of access were bundled with DK1) because it used a plugin to talk to the headset, a feature restricted to Unity 4 Pro. Unity removed this limit in Unity 5, allowing to create VR apps even with the free version, which contributed a lot to Unity becoming the most popular game engine for VR.

But so far anyone wanting to port a Unity project from for example Quest has to pay about 60% of the significant price for AVP itself each year for the privilege to do so with Unity Pro, which won't stop established developers, but hinders a lot of experimentation. And here Godot comes in very handy. What they now announced is similar to existing iOS support in Godot, allowing to create both 2D apps for floating windows (Godot is used for a number of regular apps in addition to games) as well as VR/immersive apps, currently still following the traditional model of developing on a PC/Mac and the building for AVP.

But for some months we now also had a native Quest version of the Godot editor, based on the Android version, that allows to create/modify experiences from within the Quest. This is limited to using GDScript and not a recommended workflow for larger projects, but perfect for tweaking a virtual world while being in it. So far this isn't possible on iOS, because Apple's store policy prohibits any apps that run interpreted code, as the ability to change the function at runtime means these cannot be automatically checked for malware behavior by the store. There is an ongoing attempt to bring the Godot editor to iPad OS just like on Android though, and the fact that the AVP/visionOS additions to Godot come from Apple also indicates that Apple could be interested in getting this to work.

With some/a lot of luck, in addition to build support we'll see the Godot editor getting ported to visionOS like it was to Horizon OS, which would make a later port to Android XR also very likely, as it would be much closer to the Horizon OS version. So we could get a cross-platform, on-headset development environment without the cost and restrictions of commercial game engines, freely modifiable by users. Probably not the best choice for a commercial VR game, but there are many other uses. And since Meta recently killed the in-HMD Horizon World editing capabilities, replaced by the more powerful, but PC-only desktop editor, this would be the pretty much the only option for those wanting to build in-world, not requiring a separate computer. At least until Valve releases an SteamOS/Linux based Deckard that lets you run whatever you want inside the headset, including both the VR and desktop Godot Editor.
- psuedonymous
  
  It's worth noting that whilst Unity locks AVP development behind a steep subscriptionwall, Unreal Engine has the same price as Godot.
  - Christian Schildwaechter
    
    Using Unreal Engine isn't free, you owe Epic 5% of the revenue above USD 1M. Most single developers will never reach this threshold, but a small studio selling 50K copies for USD 30 on Steam already owes 5% of USD 500K.
    
    Let's say these were eight people working on the game for two years, each costing about USD 60K/year for salaries, benefits, office rent, equipment, software licenses etc., adding up to USD 960K production cost. Valve takes 30% of the USD 1.5M revenue from 50K copies @USD 30, so the studio gets 1.05M, which leaves USD 45K in earnings after paying back the production costs. But as the Epic revenue share applies to total revenue above USD 1M, not profit, the studio owes them USD 25K of their USD 45K, leaving USD 20K in profit for the studio itself. Alternatively they could have bought UE5 development seats for USD 1850/year, similar to Unity Pro. But if each team member needed one, this would have been USD 29.6K for the two year development.
    
    And this would be a small team with a short development time without high per person cost, selling a decent amount of copies at medium price. In many cases the numbers will be worse. The Unreal Engine deal is still very fair, as UE5 provides a lot of value, and trying to replicate the function would be much more expensive. But Unreal Engine isn't free/the same prices as Godot for even rather moderate projects.
    
    Godot is actually free (*), and you can build and modify it yourself to match your needs, or fork/reuse/redistribute it as you like/need. Epic provides access to the Unreal Engine source code, but mostly for people to understand how the engine works. You can modify the source, but not combine it with any copyleft FOSS code, and I'm not sure if you are allowed to distribute source code patches. Full source licenses of the Unreal Engine (without revenue share) that large studios might buy cost millions.
    
    And so far Unreal Support for AVP is only experimental, with Epic not exactly rushing to improve it. UE is much more performance hungry than Unity in most cases, which is why the vast majority of game development for mobile, incl. standalone VR HMDs, relies on Unity instead.
    UE is focusing much more on consoles with compute expensive developments like Lumen or Nanite, so even if your revenue was low enough that your AVP project could use UE for free, the current state of AVP support in UE and Epic's general strategy make it a bad choice in most scenarios. The main reason to pick it would be already being familiar with UE development, but only for experiments, as there is no way to tell when UE AVP support will become production ready.
    
    * [Exception: console development on Godot requires a commercial subscription, because PS/Xbox/Switch licenses prohibit direct integration into any open source game engine, as the source would give away their proprietary APIs to people who haven't signed an NDA. So some of the people behind Godot created a company that signs the Sony/Microsoft/Nintendo NDAs, and creates and supports a special version of Godot extended for the console specific interfaces that does not include the platform specific source code documenting the proprietary APIs.]
- xyzs
  
  "Godot is mainly programmed in GDScript".
  
  Hum, completely false information, Godot is almost entirely programmed in C++.
  GDScript is the embedded main scripting language you can use to script functions within the engine.
  - Christian Schildwaechter
    
    Godot is programmed in GDScript/C# (plus a lot of extra language bindings, incl. C++), meaning game developers writing games in Godot use/program in GDScript/C#. Which is most of the code created in connection with Godot.
    
    Godot itself, including the GDScript interpreter, has been largely written in C++ for performance reasons. The Godot Editor itself is a Godot application. Game developers can extend their games written in GDScript/C# with C++ extensions to Godot..
    
    The reason to implement the game engine and performance critical extensions in C++ is that it is very fast due to a low overhead.
    
    The reason why nobody in their right mind programs Godot games in C++ is that the overhead in more modern languages actually serves a purpose.
    
    C++ is an ugly bastard language creating excessively verbose, error prone code with low readability, and for most use cases should be treated like Javascript, with a flame thrower. Just like Javascript being saved from torching by having accidentally become the default/only language running inside web browsers, the fact that C++ was unavoidable in the past due to much slower machines still keeps it alive. Just like Javascript and the dependency hell it created with npm, making proper code reviews impossible, the security nightmare the lacking C++ memory management has caused for decades means the earlier the world gets rid of these two, the better.
    
    Please direct any counter arguments to a forum for Rust developers, who will gladly provide plenty of background on the security mess C++ is, or a forum for Python/AI developers, who will provide plenty of evidence why implementing anything that requires implementing logic is done way more productive in a scripting language or something with proper memory management like Java or C#, and calling optimized libraries written in C++, Fortran or similar languages only for the compute heavy parts.
    
    The Unreal Engine dates back to 1998, so it still uses C++ that was the only valid option back then even for game code, but now also provides the visual Blueprints as a more beginner friendly option. Unity settled for C# (with UnityScript ≈ JavaScript and Boo ≈ Python dropped in Unity 5), Godot went GDScript ≈ Python with the option to use C#. All use C++ in the background to speed up the game engine itself, but all suggest more developer friendly languages for the writing the actual games.
    
    Maybe Godot will one day rip out C++ and replace it with Rust, or Carbon, the backwards compatible C++ replacement suggested by Google that fixes some of C++'s most obnoxious crimes. But they will never replace GDScript with C++.
    - guest
      
      There is no such thing as "one day rip out C++ and replace it with" anything. It sucks the life out of any codebase so bad that even the people that wrote the code cannot even maintain it. It is still lurking underneth many of the other computer languages you mentioned. Even Google and Meta allowed it to pollute their linux codebases below Android. Probably even more so with C# and other non open source languages, and who knows with Apple. If you want to hear a really educated analysis of C++ then read what Linus Torvolds has to say about it.
      - Christian Schildwaechter
        
        Everybody doing very long term software projects is caught between a rock and a hard place. The systems and languages you started on over time change and/or get outdated, so you are forced to adapt and change things that were running just fine, which is usually not a good idea.
        
        If you try to mix new and old, you can leave existing parts as they are, but end up with some hard to maintain mash-up. If you replace the old with the new, you will most likely introduce a lot of new errors and accidentally break a lot of fixes that took much time to come up with in the old code base. If you just stay with the old, you miss all the features of the new and over time have to invest a lot of energy just to replicate functions you'd get for free if you switched.
        
        That's why everybody is very careful about these changes, avoids them if possible. And why projects that still try usually take much longer than expected. And why projects like Carbon or TypeScript exist. Carbon is a C++ superset, TypeScript a JavaScript superset. So instead of replacing existing source completely, you can write parts of it new in the superset and keep the rest just as it is, because the original language is still a fully valid part of the superset. So you can gradually shift over to a more modern (version of a) programming language, and at one point start weeding out the remaining spots still using unsafe methods.
        
        And this has been done successfully. Objective-C (1984) was a superset of C (1972) that added a very slim object messaging layer similar to Smalltalk (1972). It was used for the Mach microkernel (1985) that was at the core of NeXTSTEP (1989) which later became the modern MacOS X (1997/1999). The Mach kernel was working with a BSD Unix (1978) written in C, the API for application development on top used an object oriented approach that was later copied by Java (1995) and Microsoft's .NET (2016)/C# (2000). NeXT/Apple extended the Objective-C compiler to also understand C++ (1985) as another superset of C that takes a very different approach for adding OO. This combination with a lot of historic crud made it from an operating system for mini computers to iPhones, stretching 40 years, with core concepts staying the same for decades, missing out on a lot of progress in programming language design. So Apple decided to introduce Swift (2014) that plays nice with an existing Objective-C codebase, and according to the author borrows concepts "from Objective-C, Rust, Haskell, Ruby, Python, C#, CLU, and far too many others to list". Apple is gradually moving MacOS towards Swift, but you still have a lot of Objective-C, C++ and pure C everywhere, and it will stay that way for a long time/forever.
        
        Similarly there is so much existing code in C++ that without doubt it will still be in use in 50 years. Linus Torvalds some time ago started accepting code contributions in Rust for the Linux kernel, because a lot of people want to switch to Rust, designed to automatically eliminate many of dangerous traps leading to security issues in the current C/C++ code. But the kernel management works kind of like a feudalistic society, with some people having control over specific areas, and some of these mini overlords simply refuse to accept any Rust, even just to allow interfacing with other Rust parts, because they don't want a mixed code base or simply don't want to have to review different languages. All these arguments are in some way valid, because this is one of the above mentioned "between a rock and a hard place" situations.
      - guest
        
        What you say makes in sound like Swift is a lesser evil than the other languages used for VR, but I wonder if you think them using Metal rather than OpenGL is an improvement.
      - Christian Schildwaechter
        
        TL;DR: Yes, using Metal rather than OpenGL is an improvement for VR developers using game engines, even though it makes the life of game engine developers much harder.
        
        [Warning: this got terribly long (again), and the result doesn't change, there is only a lot of background why using Metal makes more sense, and how we got here. Now shortening this infodump would take me hours, and it would still be too long, so sorry for another excessive reply in this discussion. Ultrashort: faster, newer features, future proof, available compatibility workarounds, all trouble delegated to game engine developers.]
        
        To clarify, I'm answering from the perspective of someone that uses game engines to create VR apps. Other scenarios like professional CAD solutions or designing a new cross-platform game engine can lead to very different answers.
        
        There are always several aspects to whether something is a good choice that often contradict each other, like being optimized for one task vs. having a lot of people being familiar with it. You don't get both.
        
        Metal is similar. In general I'd say using Metal on AVP makes a lot more sense than using OpenGL. Metal, Vulkan and DX12 were specifically designed to solve issues with the centralized architecture of OpenGL that made it harder to fully utilize modern massive parallel GPUs. OpenGL is a graphics API that does a lot more than the newer GPU APIs that mostly allow to talk to the GPU and leave any complex concepts like a scene graph to the application. Which means more work for (some) developers, but also more options to optimize, because you no longer depend on the OpenGL architecture.
        
        So a VR developer using Unity that handles all the nasty details will be able to mostly just switch from OpenGL to Metal/Vulkan/DX11 by selecting it in the build options, and often see a (sometimes significant) performance increase. This of course required Unity engineers to rebuild all the parts that OpenGL previously provided, and doing this for several different low level APIs. Unfortunately there are three similar APUs, but fortunately they can be easily translated into the other without losing a lot of performance.
        
        Metal is the oldest, introduced mid 2014 for iPhone 5S and later. DX12 launched with Windows 10 in mid 2015, The Vulkan spec is from 2016, and the first Android 7 phones using it appeared at the end of that year. There were numerous reasons for Apple to go forward with Metal instead of waiting for Khronos to come up with an OpenGL successor, the most important being that it took them ages. And after Apple released Metal, Khronos finally scrapped their projects and adapted AMD's Mantle API as the base for Vulkan, finalized two years after Apple had already switched.
        
        Vulkan is now the official follow-up (not replacement) to OpenGL. OpenGL development stopped in 2017, so new features like raytracing are no longer added and have to be implemented in vendor specific extensions, a situation that will only get worse over time.
        
        So Apple stayed with Metal, which also allowed them more development flexibility for their specific uses, not depending on a design community. Metal is more developer friendly than Vulkan, and although this is mostly irrelevant for someone using it indirectly via Unity or Godot, it means that Metal will offer the best performance and feature set on any Apple device like AVP.
        
        With the newer APIs being faster (when used right) and getting updates and new features, the main reason to even consider OpenGL is widespread backwards compatibility. Less relevant on a large engine like Unity that had enough engineers to cover all new GPU API and optimize for them early on, but a bigger issue for a smaller FOSS engine like Godot that not only needed to replace a lot of the functionality build into OpenGL, but now also has to support several APIs in parallel.
        
        To make it worse, there is also WebGL for web builds of Godot games. Apple supported the 2011 WebGL 1, but shunned the 2017 WebGL 2 until 2021 because it still relied on the "outdated" OpenGL. They instead proposed the much more flexible WebGPU, which was accepted and finalized in 2021, but still not available in all browsers.
        
        As a developer using a game engine I don't have to worry much about this, as long as the features I need are available in the graphics backend. I just want a fast and stable solution with wide support. But Godot now has to target OpenGL, Vulkan, DX12, Metal (since 4.4, before that via Vulkan translation), WebGL 1 for large compatibility, WebGL 2 for the significant improvements it brought to supporting browsers, and WebGPU (some day in the future).
        
        For Apple, who are very willing to break backwards compatibility, have their own development tools and partnered with Unity for AVP, none of that mattered and Metal was the only reasonable choice. visionOS actually (sort of) still supports OpenGL ES that is the base of WebGL 2, supported in the AVPs Safari browser. OpenGL ES is only a subset of OpenGL though, and visionOS didn't inherit the (deprecated and very outdated) full OpenGL 4.1 that hasn't been updated on MacOS since 2011.
        
        By now running OpenGL on top of Metal with the (proprietary) MoltenGL library is probably faster than the native MacOS OpenGL, and even OpenGL -> Vulkan -> Metal and DX8-11/12 translation works fine, so the sole reason to stick with OpenGL is for applications that really use the full feature set of it like a lot of CAD software. But if you are running these, you are also running a professional Nvidia or AMD workstation GPU, because only these get the full OpenGL driver support, while their gaming cards don't.
      - guest
        
        Yes, Apple is very willing to break backwards compatibility. Any idea how long Metal will last before they move on to something else if its older than DX12 and Vulkan? I remember when they replaced Quickdraw with RAVE and then replaced that with OpenGL. They each seemed to last not more than a decade. At least it seems that they change their graphics API less frequently than the game engines break backwards compatibility.
    - xyzs
      
      Pfff.
      Stop spraying false information. Godot is not progammmed in GDScript and C#!
      
      You have obviously not freaking clues about what you are talking about. It shows and it is lame you insist
      
      It’s not because you write infinitely long replies that they are smarter or more legit.
      - Christian Schildwaechter
        
        From the Godot documentation:
        
        Programming languages
        
        Let's talk about the available programming languages.
        
        You can code your games using GDScript, a Godot-specific and tightly integrated language with a lightweight syntax, or C#, which is popular in the games industry. These are the two main scripting languages we support.
        
        With the GDExtension technology, you can also write gameplay or high-performance algorithms in C or C++ without recompiling the engine. You can use this technology to integrate third-party libraries and other Software Development Kits (SDK) in the engine.
        
        docs_godotengine_org/en/stable/getting_started/introduction/introduction_to_godot.html#programming-languages
        
        Which is exactly what I explained above.
        
        I realize that I apparently stepped onto your toes once too often with my replies correcting your sometimes rather blue-eyed claims, like that the a Bigscreen Beyond could be turned into a standalone HMD with only 40g of extra weight ("So, adding a standalone system to a Beyond would make it weigh around 150g") from a few weeks ago. Because you have started replying to my posts, picking up some bizarre side aspect, often taken completely out of context, and declaring me obviously incompetent.
        
        But you really need to up your game here. Just intentionally misinterpreting the ambiguity of the English language to contradict a statement I never made and then drama-queen ("Hum, completely false information", "Stop spraying false information.", "You have obviously not freaking clues".) won't do. Esp. if this is easily rebutted by looking into the OFFICIAL DOCUMENTATION. You are not that daft that you wouldn't perfectly understand that there are multiple programming languages involved here, one to implement the engine, others to use the engine, with the latter the more relevant for Godot users and this article.
        
        It’s not because you write infinitely long replies that they are smarter or more legit.
        
        No, of course not. It's because I do my homework and check the sources before I post things. I consider the length of my posts a weakness, but luckily they at least aren't infinite. That would be horrible.
      - xyzs
        
        I don’t pick any fight.
        You are posting very interesting stuff most of the time but when you comment in my domain which is computer graphics and programming, I can’t let infos I think are not proper or ambiguous in this case, be left like that.
        
        My interest in Godot lays in its cpp implementation, the high level scripting interfaces are more like a end user thing. But sure you can say it programs Godot, but it’s just uncommon.
        
        Anyway I should relax sometime.
TonyVT SkarredGhost

This is good!
Octogod

Godot support from Apple is amazing. Speaks volumes to how their Unity integration went.