Should we expect bindings to iOS cocoa anytime soon?

I've seen several posts that outline the difficulties creating bindings for the mobile platforms (i.e. android or iOS), some of them claiming that's not even feasible(i.e. you would end-up writing some kind of non-go code) so I'm wondering if frameworks binding is on any roadmap or it's just something that we shouldn't expect. Is it more a technical issue or a kind of grunt work issue? I imagine it should be possible to just "generate" these bindings. The release of Apple Swift as open source could actually help to write a binding generator, right?

I'm aware that Go has mobile support[0] but that seems to be the case only for games(i.e. no cocoa or android API support).

[0] https://github.com/golang/mobile

I'm not sure how Obj-C/Swift bindings work, but I would think they should be similar to C/C++? No idea though...

I'm not sure how you envision autogenerating stuff like that, it's more complex than you'd think. There is stuff like swig to generate C/C++ library wrappers, but even then you still need to do quite some manual preparations to get things working, and I don't think it can do Go->Objective-C...

So it's probably down to some serious grunt work, having someone willing to do this stuff.

Also mind that a blind 1:1 binding might not be what you want, or might even be possible due to differences in concepts in the languages.

Don't expect good Cocoa bindings for Go. It's possible to do but the mismatch between how Cocoa/Objective-C sees the world and how Go sees the world means that bindings will be slow, tedious to write and awkward to use.

Consider calling a simple Cocoa function like [NSButton setTitle:"foo"]. In Go, strings are binary blobs (possibly in utf8, but that's not enforced, so you really don't know the encoding). In Cocoa, strings are UTF 16. In a hypothetical Go binding, if you do button.setTitle("foo"), "foo" has to be converted from byte string to UTF16, which is expensive (compared to function call) and you need to write a wrapper that does this conversion for every function that takes NSString as an arg. That's a lot of wrappers.

This is only one example of Cocoa and Go mismatch. Cocoa is an object-oriented, dynamic runtime. Swift was explicitly designed for Objective-C/Cocoa interop. Go wasn't.