# SwiftGodot: Swift bindings for Godot 4.6 through GDExtension

> SwiftGodot lets Swift code run inside Godot 4.6 as a GDExtension, or lets a Swift app embed Godot through SwiftGodotKit. It targets iOS, Linux, macOS and Windows, requires Swift 6.3, and ships a smaller SwiftGodotRuntime target for builds that do not need the full API.

**migueldeicaza/SwiftGodot** — New Godot bindings for Swift. SwiftGodot SwiftGodot provides Swift language bindings for the Godot 4.6 game engine using the new GDExtension system.

- Repository: https://github.com/migueldeicaza/SwiftGodot
- Website: https://migueldeicaza.github.io/SwiftGodot/tutorials/swiftgodot-tutorials/
- Stars: 1,691 · Forks: 114
- Language: Swift
- License: MIT
- Published: 2026-08-08 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/migueldeicaza-swiftgodot

## The problem SwiftGodot solves for Swift developers in Godot

Godot 4.6 exposes GDExtension, an interface for native code that the engine loads at runtime. SwiftGodot generates Swift bindings for that interface, so a Swift developer can write nodes, register them with the engine, and let Godot call into compiled Swift instead of GDScript or C#. The README frames the audience directly: the bindings are for people who want to build an extension added to an existing Godot project, where the Swift code provides services to the engine, or for people who want Godot embedded as a library inside a Swift application through the companion SwiftGodotKit module. The second case is the more unusual one. Rather than opening the Godot editor, you launch the Godot runtime from Swift, which the README says lets you debug your code from Xcode alongside the Godot code on macOS. That is a different workflow from writing a plugin for an existing project, and it changes what you can inspect at runtime.

The stated motivation is memory behaviour. The README argues that driving Godot from Swift avoids the game stutters it attributes to garbage collection in C#, and links a talk titled "Swift Godot: Fixing the Multi-million dollar mistake". Treat that as the project's position rather than a measured result; no benchmark is given in the README. The more concrete claim is about surfacing Swift APIs to Godot, with GodotApplePlugins cited as an example of wrapping iOS and macOS APIs for use in Godot.

## How the bindings work: generated API, registration, and two target sizes

SwiftGodot is not a hand-written wrapper. The repository contains a Generator directory, and the README describes working on the binding generator as a separate activity from using the bindings, including editing an okList variable to trim build times. The generated output is split across two targets. SwiftGodotRuntime contains support for the core variant types, Object, ClassDB and RefCounted. The SwiftGodot target contains the entire Godot API and is a superset of SwiftGodotRuntime. This is a build-size decision more than an API decision: if your extension only needs the core types, the smaller target avoids compiling the full surface. The README points to a discussion for the rationale rather than spelling out the size difference.

On the Godot side, three pieces are required. Your Swift code compiles into a shared library. A .gdextension file tells Godot where to find the library assets. Registration and bootstrap code connects the two. The README shows a setupScene function that checks for the .scene initialization level and calls register(type: SpinningCube.self), plus an exported entry point marked with @_cdecl("swift_entry_point") that receives interface and library pointers. That entry point is the boundary Godot crosses when it loads the extension, and it is the part most likely to need attention when Godot's extension interface changes.

## Installing SwiftGodot and building a first spinning cube

The README's quickest path is to create a Swift library package that depends on SwiftGodot through SwiftPM. The package must declare a dynamic library product, because Godot loads a shared library. This example is copied from the README, including the branch dependency:

```swift
// swift-tools-version: 5.9
import PackageDescription

let package = Package(
    name: "MyFirstGame",
    products: [
        .library(name: "MyFirstGame", type: .dynamic, targets: ["MyFirstGame"]),
    ],
    dependencies: [
        .package(url: "https://github.com/migueldeicaza/SwiftGodot", branch: "main")
    ],
    targets: [
        .target(
            name: "MyFirstGame",
            dependencies: ["SwiftGodot"])]
)
```

That dependency compiles all of SwiftGodot from source. On Apple platforms the README offers an alternative: add the prebuilt SwiftGodotBinary package and select its SwiftGodot product for faster iteration. Client code does not change, so you still write import SwiftGodot and keep using macros such as @Godot and @Export.

The next file declares a node. The README's example is a spinning cube that creates a MeshInstance3D with a BoxMesh in _ready and rotates in _process:

```swift
import SwiftGodot

@Godot(.tool)
class SpinningCube: Node3D {
    public override func _ready () {
        let meshRender = MeshInstance3D()
        meshRender.mesh = BoxMesh()
        addChild(node: meshRender)
    }

    public override func _process(delta: Double) {
        rotateY(angle: delta)
    }
}
```

Finally, glue code registers the type and exports the entry point Godot calls. The README's example registers the class when the initialization level is .scene:

```swift
func setupScene (level: ExtensionInitializationLevel) {
    if level == .scene {
        register(type: SpinningCube.self)
    }
}
```

With those three pieces in place you still need a .gdextension file describing where the compiled library lives, and you must import the extension into your Godot project. If you would rather not assemble that by hand, the README points to SwiftGodotKick for generating a skeleton GDExtension with Swift, and to SwiftGodotCLI for building and running SwiftGodot code without manual Godot project setup. The README also lists a SwiftGodot template project with an editor plugin that recompiles with a single button tap.

## Platform support is narrower than the binding generator suggests

The README names iOS, Linux, macOS and Windows as current targets, then adds that other platforms may be possible but have not been tested and stability cannot be verified. The related searches include SwiftGodot for Android, and the README gives no Android support. If Android is a requirement, this is the wrong tool today, and the absence is stated rather than implied. Windows deserves a second look before you plan around it: the repository carries a WINDOWS_BUILD.md file, which suggests the Windows path has its own instructions rather than being covered by the general package description.

The toolchain requirement is also strict. SwiftGodot currently requires Swift 6.3, according to the README, while the package manifest example uses swift-tools-version 5.9. Those two facts sit together without explanation, and the README does not say which Swift versions below 6.3 fail or how. If your project is pinned to an older toolchain, that is a blocker to confirm before writing any code. Note also that support for older Godot versions lives on branches rather than in the main line, so a project on Godot 4.5 or earlier is not served by the default branch.

## SwiftGodot compared with GDScript, C# and other GDExtension bindings

The most direct alternative is GDScript, which needs no build step, no .gdextension file and no shared library, and which the Godot editor treats as a first-class language. SwiftGodot trades that away for compiled Swift, Xcode debugging on macOS, and the ability to call Swift and Apple platform APIs from Godot. If your project has no Swift code and no Apple platform requirement, GDScript is simpler and the binding adds a compilation step and a packaging problem for no benefit.

C# is the other in-engine option, and it is the comparison the README makes explicitly, arguing that Swift avoids GC-related stutters. That is a design argument about memory management, not a feature checklist, and the README does not quantify it. The GDExtension ecosystem also includes bindings for other languages, and the related searches mention GodotJS, Gdext and a Godot Java extension. The difference between SwiftGodot and those is not the extension mechanism, which is shared, but the generated API surface and the tooling around it. SwiftGodot's distinguishing pieces are the SwiftGodotRuntime split, the SwiftGodotKit embedding path, and the Apple-focused templates such as SwiftGodotAppleTemplate for bridging iOS and macOS APIs. If you are not on an Apple platform and not writing Swift, those pieces do not apply to you.

## Maintenance, releases and what a Swift 6.3 requirement costs you

The repository is not archived, and the last push was on 2026-08-01, the same date as release v0.79.0. Releases v0.78.0 and v0.78 both landed on 2026-07-30, so the recent cadence is a set of small fixes rather than a long quiet period. The version numbers are still in the 0.7x range, which is worth weighing: the API is generated from Godot's own API, and a binding generator that tracks an engine will keep changing as the engine does.

The Makefile shows how the project releases and documents itself. A release target dispatches binary publishing for an existing GitHub release and requires a VERSION variable, and a binary-artifacts target builds binary XCFrameworks locally. Documentation is built with swift package generate-documentation against the SwiftGodot target and pushed to a separate SwiftGodotDocs checkout. The practical consequence for an adopter is that the prebuilt Apple packages come from a publishing process described in BINARY_RELEASES.md, so you should read that file to see which slices are published before assuming a binary path exists for your platform.

Licensing is MIT, which permits commercial use and modification, and the repository carries a LICENSE file at the top level. That is a permissive licence, but it says nothing about the licences of the Godot engine itself or of any third-party code you link into an extension, so check those separately. Nothing here is legal advice.

## Conclusion

Adopt SwiftGodot if you already write Swift and want your game logic compiled into a Godot 4.6 project, or if you want to drive Godot from a Swift application through SwiftGodotKit. Do not adopt it if you need Android, since the README lists iOS, Linux, macOS and Windows only, or if you cannot move to Swift 6.3. Before you commit, verify two things: whether the full SwiftGodot target or the smaller SwiftGodotRuntime target fits your build, and whether the prebuilt SwiftGodotBinary package covers your platform or you need a source build through SwiftPM.

## FAQ

### Does SwiftGodot support Android?

The README lists iOS, Linux, macOS and Windows as supported targets and says testing for other platforms has not been completed, so Android is not a supported target.

### How do I install SwiftGodot in a Swift package?

Add a SwiftPM dependency on the SwiftGodot repository and depend on the SwiftGodot target, as the README's package manifest example does. On Apple platforms you can instead use the prebuilt SwiftGodotBinary package and select its SwiftGodot product.

### What Swift version does SwiftGodot require?

The README states that SwiftGodot currently requires Swift 6.3.

## Sources

- [Official documentation](https://migueldeicaza.github.io/SwiftGodot/tutorials/swiftgodot-tutorials/)
- [Official README](https://github.com/migueldeicaza/SwiftGodot#readme)
- [Project repository](https://github.com/migueldeicaza/SwiftGodot)
- [Release notes](https://github.com/migueldeicaza/SwiftGodot/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/migueldeicaza-swiftgodot