If that's not working, raise a GitHub issue w/@szeng. I haven't done any FFI tests on a mac, but much more significant demos are working on Linux/Windows, e.g. %gtk.r
Early on I was anti-FFI just because it had a lot of hooks into the GC and memory model, and having yet-another-function-type (ROUTINE!) was introducing a lot of complexity. Over time, I managed to accomplish a couple of things in the "OneFunction" design which made having new function dispatchers introduce less complexity...and also factored out the FFI entities to use stock OBJECT!s and BINARY! for their data/etc.
So now it's not going anywhere. It's gone from being scary to being a reasonably sophisticated test case for a user-defined type. If you find FFI useful, then don't let me stop you...and if you find bugs or have problems, you can try reporting them.
But my own point of view is that it's a bit of a red herring to say that the way to address a lack of C programming expertise is to use a shaky implementation method. Because if you asked me to use FFI to do things like SQLite, I wouldn't have the tools in hand to do it correctly..and would have to plaster it with usage warnings.
If you take a simple thing like passing the memory backing a STRING! to a C function, you already had problems in the old code of the string maybe being one byte per character or maybe being two bytes per character, as an implementation detail. So there are places in the GTK demo where your widget labels would be messed up with a string that was of the two byte form (a circumstance that could arise even if all your characters were ascii, e.g. if there ever was a wide character and then removed). UTF-8 Everywhere might fix that one, but sometimes things will hold onto pointers you pass them...and any mutating string operation can invalidate the memory and reallocate it at a new pointer. (I'd argue that the GC might want to just clean up and compact things, so even if you don't change things it could move.)
Perhaps it will suffice for your own careful usage--but if you're packaging a library for others to use, odds are you're taking what was a relatively safe high-level language and making it brittle and crashy.
We might be able to enhance the interface language to build a smarter/better FFI, that lets you achieve the kind of level of control that breaking off into C and building Rebol abstractions would give you. I don't know if it's worth it in an era where protocols are using more web-servicey type languages to exchange data.