SwiftGodot: Swift bindings for Godot 4.6 without a garbage collector

What SwiftGodot actually gives you

SwiftGodot is a set of Swift bindings for the Godot 4.6 game engine, built on GDExtension, the official C API for extending Godot. It solves a specific problem: writing game logic in Swift instead of GDScript or C#. The README is direct about the motivation: no garbage collector, unlike C#. That claim matters for frame pacing. A GC pause can stutter a game; Swift's ARC uses reference counting, which is deterministic per operation. The bindings let you do two things. First, build a .gdextension that plugs into an existing Godot project, where your Swift code provides nodes and services to the engine. Second, use SwiftGodotKit to embed Godot inside a Swift application, driving the engine directly from your code. The intended audience is Swift developers who want to stay in Swift for game logic, or who need to bridge Apple platform APIs into Godot, as the GodotApplePlugins example shows.

How the bindings work: GDExtension and the runtime split

The mechanism is a generated API layer over GDExtension. SwiftGodot exposes the full Godot API as Swift classes and methods. You write a class like SpinningCube, mark it with the @Godot macro, and override methods like _ready and _process. The macro handles registration with Godot's ClassDB. The README shows a minimal example: a Node3D subclass that creates a MeshInstance3D and rotates it. Under the hood, your Swift code compiles into a shared library. Godot loads that library through a .gdextension file, which points to the compiled Swift assets. There is also a bootstrap function, exported with @_cdecl("swift_entry_point"), that Godot calls at initialization. The binding is split into two targets. SwiftGodotRuntime is a minimal subset covering core variant types, Object, ClassDB, and RefCounted. The full SwiftGodot target is a superset with the entire API. The rationale, linked in the README, is to reduce compile time and binary size when you only need the core. That split is a practical design choice for a binding layer that would otherwise be enormous.

Getting started: commands and config

The README gives a concrete path to a first project. You create a Swift Package with a dynamic library product. The Package.swift references SwiftGodot from a branch, for example .package(url: "https://github.com/migueldeicaza/SwiftGodot", branch: "main"). The target depends on SwiftGodot. Then you write a source file with the @Godot macro and a class. After that, you need glue code: a function that registers your types at the .scene initialization level, and a @_cdecl("swift_entry_point") function that Godot calls. The README shows the signature: interfacePtr, libraryPtr, and other parameters. You also need a .gdextension file that describes where the Swift library assets are. For faster iteration on Apple platforms, the README points to SwiftGodotBinary, a prebuilt package, and to BINARY_RELEASES.md for the published slices. There are also helper projects: SwiftGodotKick creates a skeleton GDExtension or a SwiftGodotKit standalone project, and SwiftGodotCLI lets you build and run without manual Godot project setup. The requirement is Swift 6.3, which is a specific version, not a range.

The no-GC advantage and its limits

The README's headline claim is the absence of garbage collection, which is a real technical difference from C# in Godot. Swift uses automatic reference counting, so object lifetime is tied to reference counts, not a tracing collector. That can reduce unpredictable pauses during gameplay. But the claim is not a blanket performance guarantee. ARC has its own costs: retain and release operations, and potential retain cycles if you are not careful. The README also mentions that SwiftGodot can be used to surface Swift APIs to Godot, which is a different benefit. The no-GC point is specific to the runtime, not to the quality of your game loop. If your game logic is heavy in Swift, you still have to manage allocations and reference cycles manually. The documentation does not provide benchmarks, so the practical impact on frame times is not quantified in the material. Treat the no-GC claim as a design property, not a measured win.

Platform support and a real limitation

The README lists iOS, Linux, macOS, and Windows as supported platforms. It explicitly says other platforms may be possible but testing has not been completed and stability cannot be verified. That is a genuine boundary. If you target Android, web, or consoles, SwiftGodot is not a safe choice based on the current documentation. Another limitation is the Swift version requirement. Swift 6.3 is a moving target; if your toolchain is older or newer, you may hit compatibility issues. The README also shows that the binding generator is part of the repository, and editing the okList variable is suggested to trim build times when working on the generator. That implies a large generated surface, and rebuilds can be slow. The repository has a branch for older Godot versions, but the main branch is tied to Godot 4.6. That means you cannot use the latest features on a stable Godot 4.2 or 4.3 project without switching branches, which may lag behind.

Alternatives: C# and GDScript, and what changes

The obvious alternative is C#, which is the other main .NET language for Godot. The difference is fundamental: C# uses a garbage collector, Swift does not. If your game has tight frame budgets and you have seen GC spikes, SwiftGodot removes that class of problem. But C# has a longer history in Godot, more tutorials, and a stable toolchain. GDScript is the native scripting language, with the simplest iteration cycle and no build step. SwiftGodot requires a compiled shared library, a .gdextension file, and a Swift toolchain. That is a higher setup cost than GDScript. The README also mentions a C# Udemy tutorial ported to SwiftGodot, which shows that the API surface is comparable to C# in scope. For Apple platform integration, SwiftGodot has an advantage because you can write native Swift code and expose it to Godot, as GodotApplePlugins demonstrates. The choice is not just language preference; it is about whether you need GC-free behavior and how much build infrastructure you are willing to accept.

Maintenance and upgrade cost

The repository is active. The last push and the latest release, v0.79.0, are from August 2026, and there are multiple releases within days of each other, including v0.78.0 and v0.78. That release cadence indicates rapid iteration, which is good for bug fixes but also means you should expect frequent changes. The release notes mention fixes like "use of object_set_instance_binding" and "Fixing recreateFunc," which are low-level binding details. Upgrading SwiftGodot may require regenerating your project or adjusting to API changes, especially if you use the main branch. The README suggests using a branch reference in Package.swift, but for production you should pin to a specific release tag. The license is MIT, which is permissive and allows commercial use without copyleft obligations. The project also offers a binary package for Apple platforms to reduce build time, but you must verify that the binary slices match your deployment targets. There is no documentation in the material about long-term support or deprecation policy, so you are relying on the maintainer's release history.

Who should adopt SwiftGodot now

SwiftGodot is a credible tool for Swift developers who want to build Godot games without leaving their language. The no-GC property is a concrete reason to prefer it over C#. The macOS and iOS story is strong, with Xcode debugging and prebuilt binaries. The embedded mode via SwiftGodotKit opens a different use case: a Swift application that hosts Godot, which is rare among Godot bindings. The limitations are just as clear. If you need stable support for Godot versions below 4.6, or platforms outside the four listed, you are on your own. The Swift 6.3 requirement is a hard gate. The lack of benchmarks means you cannot assume the no-GC claim translates to faster games without measuring. Before adopting, check the BINARY_RELEASES.md for Apple slices, confirm your Swift toolchain is exactly 6.3, and try the SwiftGodotCLI or SwiftGodotKick to validate the build on your OS. The project is moving fast, so pin a release and test each upgrade carefully. That is a concrete, project-specific path.

Editorial conclusion

Adopt SwiftGodot if you write Swift and want a GC-free path into Godot 4.6, especially on macOS or iOS where Xcode debugging and prebuilt binaries help. Avoid it if you need stable support for older Godot versions or platforms beyond iOS, Linux, macOS, and Windows. Verify your Swift toolchain is exactly 6.3, confirm the .gdextension loading works on your target OS, and check the binary package for Apple slices before committing. The project is actively maintained, but the binding generator and frequent releases mean you should pin a version and test each upgrade.

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes