progrium/macdriver

Native Apple APIs for Golang!

DarwinKit lets you work with supported Apple frameworks and build native applications using Go. With XCode and Go 1.18+ installed, you can write this program in a main.go file:

package main

import (
	"github.com/progrium/macdriver/objc"
	"github.com/progrium/macdriver/macos"
	"github.com/progrium/macdriver/macos/appkit"
	"github.com/progrium/macdriver/macos/foundation"
	"github.com/progrium/macdriver/macos/webkit"
)

func main() {
	// runs macOS application event loop with a callback on success
	macos.RunApp(func(app appkit.Application, delegate *appkit.ApplicationDelegate) {
		app.SetActivationPolicy(appkit.ApplicationActivationPolicyRegular)
		app.ActivateIgnoringOtherApps(true)

		url := foundation.URL_URLWithString("http://progrium.com")
		req := foundation.NewURLRequestWithURL(url)
		frame := foundation.Rect{Size: foundation.Size{1440, 900}}

		config := webkit.NewWebViewConfiguration()
		wv := webkit.NewWebViewWithFrameConfiguration(frame, config)
		wv.LoadRequest(req)

		w := appkit.NewWindowWithContentRectStyleMaskBackingDefer(frame,
			appkit.ClosableWindowMask|appkit.TitledWindowMask,
			appkit.BackingStoreBuffered, false)
		objc.Retain(&w)
		w.SetContentView(wv)
		w.MakeKeyAndOrderFront(w)
		w.Center()

		delegate.SetApplicationShouldTerminateAfterLastWindowClosed(func(appkit.Application) bool {
			return true
		})
	})
}

Then in this directory run:

go mod init helloworld
go get github.com/progrium/macdriver@main
go run main.go

This may take a moment the first time, but once the window pops up you just made a macOS program without using XCode or Objective-C. Run go build to get an executable.

Although currently outside the scope of this project, if you wanted you could put this executable into an Application bundle. You could even add entitlements, then sign and notarize this bundle or executable to let others run it. It could theoretically even be put on the App Store. It could theoretically be put on an iOS, tvOS, or watchOS device, though you would have to use different platform specific frameworks.

Caveats

• You still need to know or learn how Apple frameworks work, so you'll have to use Apple documentation and understand how to translate Objective-C example code to the equivalent Go with DarwinKit.
• Your programs link against the actual Apple frameworks using cgo, so XCode needs to be installed for the framework headers.
• You will be using two memory management systems. Framework objects are managed by Objective-C memory management, so be sure to read our docs on memory management with DarwinKit.
• Exceptions in frameworks will segfault, giving you both an Objective-C stacktrace and a Go panic stacktrace. You will be debugging a hybrid Go and Objective-C program.
• Goroutines that interact with GUI objects need to dispatch operations on the main thread otherwise it will segfault.

This is all tenable for simple programs, but these are the reasons we don't recommend large/complex programs using DarwinKit.

Examples

largetype

A Contacts/Quicksilver-style Large Type utility in under 80 lines:

pomodoro

A menu bar pomodoro timer in under 80 lines:

webshot

A webview PNG capture example in under 100 lines:

See all examples

How it works

At the heart of DarwinKit is a package wrapping the Objective-C runtime using cgo and libffi. This is actually all you need to interact with Objective-C objects and classes, it'll just look like this:

app := objc.Call[objc.Object](objc.GetClass("NSApplication"), objc.Sel("sharedApplication"))
objc.Call[objc.Void](app, objc.Sel("run"))

So we wrap these calls in a Go API that lets us write code like this:

app := appkit.Application_SharedApplication()
app.Run()

These bindings are great, but we need to define them for every API we want to use. Presently, Apple has around 200 frameworks of nearly 5000 classes with 77k combined methods and properties. Not to mention all the constants, functions, structs, unions, and enums we need to work with those objects.

So DarwinKit generates its bindings. This is the hard part. Making sure the generation pipeline accurately produces usable bindings for all possible symbols is quite an arduous, iterative, manual process. Then since we're moving symbols that lived in a single namespace into Go packages, we have to manually decouple dependencies between them enough to avoid circular imports. If you want to help add frameworks, read our documentation on generation.

Objects are passed around as typed pointer values in Objective-C. When we receive an object from a method call in Go, the objc package receives it as a raw pointer, which it first puts into an unsafe.Pointer. The bindings for a class define a struct type that embeds an objc.Object struct, which contains a single field to hold the unsafe.Pointer. So unless working with a primitive type, you're working with an unsafe.Pointer wrapped in an objc.Object wrapped in a struct type that has the methods for the class of the object of the pointer. Be sure to read our documentation on memory management.

If you have questions, feel free to ask in the discussion forums.

Thanks

This project was inspired by and originally based on packages written by Mikkel Krautz. The latest version is based on packages written by Dong Liu.

Notice

This project is not affiliated or supported by Apple.

License

MIT