SwiftGodot Development Themes

[migueldeicaza]

Recently Elijah asked me about what were the missing gaps, and I realized that while we have filed a lot of issues in this repository, they were not quite organized along themes. I am posting my mental dump of what I would like to see in SwiftGodot in the near future here.

Perhaps these themes can be turned into labels for our issues.

Principles

• Correctness before performance
• Track the Godot development cadence
• Allow developers to be effective with Swift and Godot
• Provide good platform reach: While MacOS/iOS are the easiest to use as it comes bundled with the operating system, but we should strike to incorporate features from Swift, advocate and advance the use of Swift on other platforms (Windows, Linux, Android, Wasm, and one day consoles)
• Reduce friction for our users: reduce surprised for users, errors that they can not diagnose, assist users in diagnosis of problems in their code
• Use best coding practices: SwiftGodot grew organically first as a proof of concept, then as a viable too, and now into an actual tool that I use daily. But some of the get-it-working-first code could be improved and modernized. There are various possible quality-of-life improvements for developers and maintainers of SwiftGodot.

The following breaks down the list of bugs in GitHub issues into various buckets, perhaps these could be turned into GitHub labels for tracking:

Features/Capabilities

These are things that are known to be missing:

• Surface Notifications
• Extend support for methods that take pointers to C structures
• Work with other Float/Int configurations
• Type auto-registration
• Mismatch in getter/setters
• Multiple-extensions support with one runtime
• Autoload Singletons
• Improved Callable Support
• Missing GDExtension APIs for Variants
• Callable with async and throwing functions
• @Callable with optional arguments
• New Virtual Methods Support
• Surfacing documentation to Godot
• Import option not working on EditorImportPlugin subclasses

Windows

Windows sadly has a limit of 64k total methods exported from a library, and this breaks with the new and updated Godot API, so we need to start breaking it up:

• Break up SwiftGodot in chunks

Big Features:

• Binding arbitrary GDScript/Extensions as SwiftGodot additional modules

Platform Support

Ports that do not exist, or are not tested:

• Wasm port
• Android port
• 4.3 Tasks
  • Companion: Godot 4.2/4.3 limitations #561
• Swift/Embedded profile - should make Wasm and Consoles easier

Reliability

• Missing PackedScene handling
• Reusing SwiftGodotTestability for User Code
• @Export Properties vanish after hot reload

Hard to Diagnose:

• Runtime crash when calling @Callable function on a resource #435
• On Windows, Godot does not exit correctly #438

Usability

• Efforts that would improve the API of SwiftGodot and follow the Swift guidelines
• Bring support for Strict Concurrency
  • Some complications: Thread affinity for some tasks #471
    [](http://- Bring support for Strict Concurrency)- Codable support
• Hot Reloading of Swift Code: will require Godot Changes
• Simpler Exports
• @Callable method is not found when called from the GDScript extending the Swift type.
• Add support for default parameter values in ClassServices.registerMethod and @Callable macro support
• Wrap GDictionary in a typed collection the same way GArray is
• Receiving editor warning for GArray - Could not find element type from property hint of a typed array
• Improvements, warn when users declare @Callable with invalid types.
  ## Consistency with Swift, but could break API
• GArray Naming Methods
• Dictionary and other collections should adopt the appropriate Swift protocols (no bug)

Optimizations

Size

• Reducing the size of SwiftGodot for deployments: godotFrameworksCtor.
• Reduced surface area binding
• Cluster signals, to avoid repeated code

Performance

• Optimization: Move more vector operations to Swift
• StringName calls

Onboarding

• Improve Onboarding
• Documentation Code Snippets
• Export Swift Documentation to Godot Documentation
• Documentation: Building Test Code
• Document how to get iOS extensions going documentation

Tooling

We have good MacOS/iOS support, but it still requires too much knowledge on dynamic libraries, editing files and plugins.

Command Line Tools

• Tools to easily create, and maintain a plugin for Godot and takes care of the creating the gdextension file, create GitHub Actions, and so on.
  Background: Request: Create package plugin for export #130
  No spec exists
• Tool to find all library dependencies, rather than bulk copying all of swift

Large Project: Godot Plugin Extension to Develop in Godot

• Develop a SwiftGodot extension that can provide Swift as a full language that can be used within Godot, without having to use any external tools.
  • POC: https://github.com/migueldeicaza/SwiftGodot/tree/editor-plugin

Best Practices

• Track ABI changes
• Diff Generated Code for Inspection
• Adopt SwiftLint (slowly, want to first merge my multiple trees)

SwiftGodotKit

SwiftGodotKit was a proof of concept to embed Godot as a library into a Swift application, the current version that we have is very limited. Luckily, Godot 4.4 will come with “libgodot” support that allows proper embedding of Godot into arbitrary host-controlled surfaces.

In the iOS/Mac cases these can be UIView/NSView or SwiftUI Views.

Part of this effort came out of the Godot on iPad effort, and it is being upstreamed, but will be done in the 4.4 timeframe. Given that this is a vastly better stack than what we have now and the changes are deep, there is not much point in investing a lot of time on SwiftGodotKit on 4.3, and this shall be done based on the 4.4 tree in migeran

[migueldeicaza]

Update: slowly making progress on SwiftGodotKit, see thag repository for details. The iOS version is more or less working, the Mac version needs additional work.