I remember hearing you, Allen, say on Handmade after dark that one must use obj-c to make a proper osx app.
Well, look what showed up up!

https://github.com/jimon/osx_app_in_plain_c

That's nasty and it's not supposed to be used this way (because Apple sucks immensely, meh...)

It is supposed to be used exactly like that. You interact with Objective-C runtime with objc_msgSend function & friends.
The same mechanism works fine on iOS: http://stackoverflow.com/a/10290255/675078

I haven't written full apps like this, but I have used this mechanism from C/C++ code before and it works perfectly fine.

You can totally avoid calling any ObjC runtime functions, but then you'll need to parse mountain of Objective-C metadata to find function pointer to call. It won't be pretty. It's like using LoadLibrary+GetProcAddress on Windows to load dll and get function pointer vs loading file manually, and parsing PE headers to find needed function. All possible, but messy.

It's better to write bridging header between pure C and Obj-C/C++ and encapsulate what you want, this solution works, but it's also unmaintainable and ugly. I would not write this code by hand.

A random chime in since we are kind of experiencing this with Ludus. Its a lot easier to do the whole thing in Obj-C as awful of a language it is Apple has there whole ecosystem built around it, and if you want to go around it it's just a lot of useless function wrapping (which is what Unity does). We chose to do the whole Mac platform layer in Obj-C as we would like to add Metal support in the future and the only way to really interface with Metal is through Obj-C.

My understanding of the issue amounts to basically zero bits of information. Since I won't be maintaining or even writing the OSX port, I am not too worried about it... it'll be someone else's problem either way.

Thanks to everyone contributing thoughts on the issue though. It would certainly be nice to have an in depth look into what exactly is going on here just so I, and anyone else, could understand why Objective-C is a thing and how bypassing it is suppose to work.

Mr4thDimention
could understand why Objective-C is a thing

Objective C is what happens when you let Steve Jobs come back to run your company.

Pre-OSX, the Mac used antiquated but still sensible C programming interfaces (the antiquated part was that it was designed prior to Macs having MMUs, so they had a lot of double-indirection nonsense going on). When they brought Steve Jobs back from the dead to run Apple again, he brought a lot of the NeXTStep people with him, and they had gone all-in on Objective C (as far as I know, they were the only ones). I have no idea what they thought was so great about it, but I guess they were SmallTalk fans or something.

So when they replaced the antiquated pre-X Mac OS with X, it was all NeXTStep-styled throughout. Unix at the core, Objective C as the interface layer, etc.

And that's how we ended up with the huge pile that is the Mac OS X interface. The hilarious part is apparently they weren't satisfied with having one ridiculous language that nobody else uses, so they added SWIFT, and now they have two :(

- Casey

exactly, and Apple is good in prohibiting things, but they could not leave C/C++ out because of large-scale projects like Photoshop, it would not be rewritten into some obscure nonsense, that one day will be thrown out off the window in Apple's fashion... yay, schizophrenia!

The easiest "Apple" way is to do UI in Objective-C/Swift and call C(!) API.

Caveat, not an Objective C coder.

From what I know, however, like C++, Objective C is a superset of C. Meaning, you can do the custom OS interface in Objective C, but do all of your coding in C, in the same .mm file. You know, just like Casey does in C++.

I am not saying that having to do it like that is great, but it at least is better than having to use JavaScript or Swift.

The way GLFW solves it is much simpler and robust. They write all the Objective-C in platform-specific `.m` files and expose `_glfwPlatform*` functions that can be called from C code.

https://github.com/glfw/glfw/blob/master/src/cocoa_window.m

They define structs for all the relevant objects: windows, cursor... and depending on the platform these will have platform-specific pointers that are only used by the platform layer.

BillDStrong
From what I know, however, like C++, Objective C is a superset of C. Meaning, you can do the custom OS interface in Objective C, but do all of your coding in C, in the same .mm file. You know, just like Casey does in C++.

Yes, this is correct (or at least was correct, the last time I built an iOS application). You typically want to use Objective C for the OS binding layer because it's much more cumbersome and maintenance-heavy otherwise, but you can then just call your regular platform-independent code from there. You certainly don't need to rewrite your application in Objective C.

- Casey