[pmoust]

Fixes #286.

ffi_prep_cif stores rtype and the address of argtypes' backing
array inside the CIF for as long as the CIF is used. A closure built
from that CIF (via CreateClosure) can be invoked long after
PrepCIF returns, once an AppKit delegate callback fires, but nothing
kept either value alive past the call itself. runtime.KeepAlive only
extends liveness through the call it's in, not beyond it.

Go 1.25's smarter escape analysis started stack-allocating the
argtypes array at the call sites in call.go, block.go,
protocol.go, and type_convertion.go, instead of heap-allocating it
as earlier Go versions happened to. Once stack-allocated, that memory
gets reused before the closure fires, so cif->arg_types ends up
pointing at garbage. macOS 26's libffi.dylib added a stricter
arg_types[i]->type > 15 check that turns this into a reproducible
SIGABRT on launch, in the very first delegate callback
(applicationDidFinishLaunching:). Full disassembly-level detail is
in the issue thread.

This wraps rtype and argtypes in a cgo.Handle stored alongside
the CIF, so both stay reachable for as long as the CIF itself does,
and deletes that handle once the CIF is garbage collected via
runtime.SetFinalizer. Passing them through a cgo.Handle also forces
them onto the heap, which is what closes off the escape-analysis path
that caused the bug.

I considered copying argtypes into malloc'd C memory instead (an
option floated in the issue), but that would store Go pointers
(including ones from MakeStructType) in memory the Go GC doesn't
scan, which is itself a cgo pointer-passing rule violation. The
cgo.Handle approach avoids that.

Verification:

• go build -gcflags='github.com/progrium/darwinkit/objc=-m' ./objc/...
  shows the flip this fix is meant to produce: before, make([]*ffi...)
  at all five affected call sites reports "does not escape"; after, all
  five report "escapes to heap".
• go test ./objc/... passes, go vet ./objc/... is clean, gofmt -l
  reports no changes needed on the touched files.
• Reproduced the actual crash against a real long-lived AppKit app (a
  status-bar menu app using a closure-based NSApplicationDelegate) on
  Go 1.26.1, macOS 26.5 arm64: it reliably SIGABRTs on launch without
  this fix and without the -gcflags "all=-N" workaround, and launches
  and stays running with this fix applied and that workaround removed.

[progrium]

LGTM, can anybody verify. Will merge with a thumbs up

Also @pmoust thank you for this

[Joaquimmnetto]

I tested this in my project (macOS 15.7.4, Go 1.26.4) and works fine. Before I was having SIGABRT issues coming from libffi.
Bellow is a description of the issue from claude:

darwinkit's objc/ffi.PrepCIF hands a Go-allocated arg-types array to
ffi_prep_cif, which keeps a raw pointer to it inside the ffi_cif for as
long as any closure built from it can still be invoked. Nothing kept
that array reachable past PrepCIF returning, so on Go 1.25+ (whose
smarter escape analysis stack-allocates it instead of heap-allocating
it) the memory gets reused before AppKit ever calls back into Go,
corrupting the CIF and aborting inside ffi_closure_SYSV_inner on the
very first delegate callback (applicationDidFinishLaunching)