Quality of Life Improvements

[migueldeicaza]

Here are some ideas that I have to improve the experience for SwiftGodot.

Daily work:

1. The pipeline to use SwiftGodot today is a bit cumbersome, the compilation of the binding, the copying of the executable and so on. I suspect we can do a mint-based command line tool that people could use to compile + copy the resulting binaries + dependencies to the project.
2. The same tool could probably maintain the .gdextension and wire up the entry point, the library name and other requirements in place.
3. I should fix the @rpath and make sure that the libgodot when used with SwiftGodotKit does not require any manual steps to run (like I documented somewhere).
4. SwiftGodotKit's libgodot binary should include iOS binaries as well.

Developer Experience:

1. Bring the macro plan to fruition for registered method, signals, variables that need to be serialized.
2. Today we are conservatively nullable, to follow what the C# API does, but it is sub-optimal, need to start annotating API for non-nullable returns (these are the worst offenders) and parameters (could give a tiny performance boost, but also can clarify to the developer what is mandatory vs what is not).

Editor Experience:

1. I started a branch to attempt to support Swift integration into the Godot Editor, I should try to complete that work.

Areas where I could use help:

1. In the "Daily Work" category, I could use some help on how to plot this workflow for users and what the experience should be like.
2. In the "Editor Experience", what should the backing Swift code be like: do we put all the Swift code for a project into a single Swift package, or do we have one Swift package per node? Ok, writing that kind of answers itself, I think.

[mgrider]

I have actually been planning to post several thoughts related to this.

• I totally agree about the cumbersome nature of the bindings and copying of executables. I was already thinking it would be nice to add some kind of step (I was imagining a post-compile script) that would automate that stuff.
• I could also imagine checking for the existence of the Godot project, and setting one up for you if one doesn't exist in the right place.
• This could include creating a root node of the correct type, but that would probably require indicator of which Swift class should be that type. Maybe an optional configuration struct that defines various Godot project-level options? And then we could make sure they're set in the Godot project, at compile-time.
• Basically, I would love to do the bulk of my work in swift, and only "drop in" to Godot when it's time to preview or run the project in the editor. To that end, (and the reduction of developer friction in general) I could also imagine a post-compile script that would run/play the project (if this is even possible).

Sorry for just kind of spitballing feature requests here! I am interested in helping out with the project, but I haven't carved out any time to do that just yet.

[alicerunsonfedora]

I think a good place to start would be creating a package plugin that can build the extension and copy it over for you, which I have noted in #130.