Comment by williamcotton
2 years ago
MacOS apps are typically written in either Objective-C or Swift as these are the officially supported languages for the MacOS APIs.
The code in this template is interfacing with the Objective-C runtime but with pure C.
Does this mean that, theoretically, this could lead to the ability to build MacOS apps in higher languages that interoperate well with C such as Python? I know you can build MacOS apps with Python now, but does this potentially improve the experience?
You can already do this in the traditional way by building an ObjC shim which exposes a C API. The solution shown here just skips ObjC and talks directly to the ObjC runtime (which has a C API but is not as convenient to use as doing the same thing in ObjC or Swift).
In a highly simplified way you can think of Objective-C as preprocessor which replaces the ObjC syntax sugar with C function calls into the ObjC runtime (it's not how it works in reality, but how it could work).
That’s essentially what this project does. It creates the C code that the ObjC compiler would generate to “implement methods” or “send messages”.
It’s somewhat doable by hand because Objc is a thin lawyer.
Over 15 years ago I did stuff similar to this project to call some Objc code from a C++ app. Most of it was exposed to normal C APIs but one feature only available in AppKit. It was much simpler to do it this way than figure out how to make GCC or Objc like our C++ or any mess with bridging headers.
I think the move to Swift has made that harder in some ways.
But then again I don’t want to write C or C++ these days if I can avoid it.
In fact, early objective-c was a preprocessor according to Wikipedia!
That is what objC scripting brige is for.
https://developer.apple.com/documentation/scriptingbridge
I believe RubyMotion does basically this:
http://www.rubymotion.com
It was fun building an app in this a few years ago, but was difficult to keep up with updates to MacOS breaking my code.
There’s already PyCocoa and pretty sure *Cocoa exists for a variety of languages.
That has always been possible. Also, under the ObjC layer, is good ol' ANSI C (FreeBSD Unix).
There's a number of apps that run on modern Macs, that were written in C, but it is unusual to see ones that leverage the GUI.
That said, it's possible to walk from Boston to Portland (OR), but I'd rather take a plane.
I knew this was possible, but I had never actually seen it implemented before. And to think, the project is over 10 years old!
When I first started programming Cocoa, I was always kind of miffed that the happy-path was: "Use Objective-C and main() should just hand-off the reigns to NSApplicationMain()". Kind of like the happy-path on Windows is "WinMain plus a bunch of boilerplate crud".
It's always felt somehow vaguely "correct" to have main() be your actual application entry point and have it manage whatever main loop you need yourself. I see that this project doesn't actually quite get there either. It's the same kind of voodoo: boilerplate code, and then cmacs_void_msgSend(NSApp, sel_getUid("run")); hands over the reigns.
I agree. I recall the Windows API and the official Hello World. I'm sure they could have got to the same place in a slightly reorganised way that kept main() as the starting point and interfaced with the event loop and the entire windowing system via some API calls that hid the cruddiest parts of the boilerplate crud (apt phrasing, thank you) away in headers and libraries. Then progressively reveal the details when they're really necessary for more elaborate applications.
It has to hand over the reigns to the Objective-C runtime to allow for all the messages being passed between objects.
I’m not sure you want to spend your time rewriting what NSApp is doing!
1 reply →
Why would you want to manage your own runloop? It's both not interesting and possible to get wrong.
1 reply →
You know i took the train to Boston to PDX, it was really relaxing. Not quite walking but definitely a lot different then a plane...
It has, but there was also Carbon until around the Intel transition.
Full Carbon was there until the 64bit transition officially, but much of it remained and still remains until now. For example, Apple only started using AppKit to draw menus in Sonoma; it was Carbon until now.
5 replies →
> officially supported languages for the MacOS APIs
How often do you need to get support assistance from Apple? Just do what you want. If it means using Obj-C or Swift for ease, do that. If it means integrating another language, do that.