v0.5.0-preview

[progrium]

MacDriver is becoming DarwinKit!

I think this might now be the best bindings project in existence for Apple APIs. Possibly even the best way to make small utilities on the Mac. And soon even other Apple devices.

This is a preview release for v0.5.0 which is a major rewrite and expansion on these bindings. This release is incompatible with previous releases, however there is an unmaintained legacy branch and all the previous releases for existing code to use. The API in this release is very close to what a 1.0 release would look like, so there shouldn't be significant changes only additions to what's here now, which includes:

• Over 30 frameworks with nearly complete bindings and more are on the way
• Over 2,000 classes with near complete coverage. Previously we had partial coverage of about 80.
• 22,000 methods/properties and nearly 10,000 constants/enums. We had less than 50 constants before.
• Automatic conversion and use of native Go builtin types in APIs like strings, bools, []byte, maps, etc.
• Support for block arguments as Go functions with properly typed arguments (callbacks!)
• Pre-made delegate implementations you can simply set Go functions on
• More 1-to-1 mapping to Objective-C symbol names while also improving Go idiomaticness
• Documentation for all symbols including a link to official Apple docs on that symbol
• Simple model for working with Objective-C memory management
• As the new name implies, we are set up to support more platforms like iOS, tvOS, watchOS, maybe visionOS
• Continued support for both Intel and Apple Silicon
• No more compile warnings, nearly all previous GitHub issues are resolved
• More examples, better docs, and bindings are nearly all generated

However, in this preview release we have a few things left out that with your help we can get into the final v0.5.0 release:

• We are missing generated bindings for framework functions
• We are currently covering APIs up to macOS 12 (which is most tbh), but we can easily cover up to 14 with help
• Our coverage of structs is incomplete, many are empty placeholders
• Several examples are currently broken

Another way you can help is to let me know what kind of examples you want to see. Drop your requests in Discussions.

This preview release is an official reboot of the project with a new name: DarwinKit. Between now and the final release, the repository will remain macdriver while everything else updates to DarwinKit, and when we release v0.5.0 we'll rename the repository as well.

A huge thanks to @mkrautz for his work 10 years ago that I found and started this project on in 2020. Unfortunately most of his code is now gone, replaced by the more recent great work by @hsiafan. The previous code generation was by @mgood, which has also been majorly upgraded. Also thanks to @tmc and @programmingkidx for engaging more recently and motivating me to do this rewrite. But also thanks to all the previous contributors that helped get to this point.

---

This discussion was created from the release v0.5.0-preview.

[TotallyGamerJet]

What an exciting release. Congrats! Do you think that porting the project to be cgo-less would be beneficial? I maintain purego a library designed to call C functions from Go without Cgo. It's used in ebitengine although not entirely yet. I'd be willing to start the work in the generator if this something you'd be interested in.

[progrium]

Actually we do have to do this, and that's the only reason cgo is needed in frameworks. I don't fully understand why, but without this delegates don't work. I'm not sure what the equivalent would be with purego.

[hsiafan]

(Unlike class objects) The compiler creates a protocol object for each protocol declaration it encounters, but only if the protocol is also:

1. Adopted by a class, or
2. Referred to somewhere in source code (using @protocol())

see ocProtocols

The objc package protocol method signatures from protocol objects. If can store/get those metadata in somewhere go code, the protocols.gen.m is no longer need.

[TotallyGamerJet]

You would basically take the place of libffi. What about callbacks?

Yes purego would replace libffi. Purego supports callbacks so that shouldn't be a problem

Also, why would you need to touch any generation, wouldn't you just need to update our objc package to be backed by purego?

Oh I just assumed the generator was creating Cgo wrappers for each class. I was mistaken. Yes updating the objc package to use purego would be most of the work.

As for the protocols I'm not sure. We haven't had any issues with them not working so I think just testing to see if it works would be the easiest thing to do.

[progrium]

Well it sounds like this could be super rad. And I want to understand how purego works, I don't know why it's not more common. I'm pretty exhausted after this release and I have a ton of other projects, but I'd say if you wanted to port our objc package and get tests passing that would be most of the work.

Meanwhile, @tmc, maybe instead of generating C/cgo for functions we try purego. This could be independent of a port of objc and gets us used to purego, which I'd probably use everywhere and in other projects if it works out.

[TotallyGamerJet]

I'll take a look at porting the objc package. I'm currently working on some purego changes so hopefully in a few weeks I'll have a PR

[hsiafan]

You guys did an amazing job, Congratulations! 🎉

[progrium]

While you're around, what were the reasons you started using libffi?

[hsiafan]

I need a way to invoke C functions and generate C callbacks. libffi is easy to use and fully meets my requirements.