9 ms·

As someone with no experience in native application development, could someone explain to me why this is significant? I have a rough idea, but I would like to u

by 9dev 2y ago

As someone with no experience in native application development, could someone explain to me why this is significant? I have a rough idea, but I would like to understand it properly.

jojobas 2y ago
I guess it's normally impossible to write a GUI application for mac os without objective-c libraries doing the talking to the OS, but what do I know.
- swatcoder 2y ago
  It is not. This was just a new wave of people finally looking under the hood. (Where they would have found many many dusty but detailed man pages and docs waiting for them)
- astrange 2y ago
  You can write one in X11 if you like, if you make people install Xquartz.
  - ngcc_hk 2y ago
    Is there example how to do that on mac. Just happy to have an old emu ibm 5100 sun x program. Wonder I need to boot up a vm or can try squartz …
    - jmb99 2y ago
      brew install --cask xquartz Or install from the project homepage [1]. Then just launch the X11 app. Note that it does require the application to be built for Mac - it’s not an emulator, just an implementation of the X11 APIs. [1] https://www.xquartz.org/ https://www.xquartz.org/
- steve1977 2y ago
  Beneath Cocoa are Core Foundation and things like Core Graphics for example, which both are C.
williamcotton 2y 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.
- rankam 2y ago
  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?
  - detourdog 2y ago
    That is what objC scripting brige is for. https://developer.apple.com/documentation/scriptingbridge https://developer.apple.com/documentation/scriptingbridge
  - jimbokun 2y ago
    I believe RubyMotion does basically this: http://www.rubymotion.com 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.
  - CodeWriter23 2y ago
    There’s already PyCocoa and pretty sure *Cocoa exists for a variety of languages.
  - flohofwoe 2y ago
    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).
swatcoder 2y ago
> why this is significant? Ultimately, because new people keep being born and missed the years where this was pretty common and haven't yet bumped into the corners where it still is. The repo and the SO discussion it was inspired by are themselves 11 years old and seem to be rooted in a new generation of iOS app developers starting to get more deeply curious about the system they're running on and how else it might be approached, which this person then ran with on MacOS. Apple invites people to get started in making software for their platforms using (what's meant to be) more accessible tooling like Objective-C, Interface Builder, Swift, SwiftUI, etc but there's of course a whole BSD-rooted operating system sitting there once those those developers start digging. It's no secret, but it's a discovery that some people need to make on their own.
- LeoNatan25 2y ago
  This isn’t an example of that. Have you looked at the code? This uses ObjC and Cocoa implementations in an unintuitive method. Nice exercise to learn about the ObjC runtime, but has zero practicality or use.
- johnnyjeans 2y ago
  The funny thing is, Apple themselves seems to have forgotten about the whole BSD-rooted operating system. Anybody who ventures off the beaten path of developing software for a modern Mac will inevitably encounter a lot of cobwebs. One of my favorites: When Apple implemented app bundles, they never updated dyld's search paths to be aware of the app bundle directory structure, meaning you have to manually patch your rpaths. Not a huge deal, and one that's hidden from you if you only ever know xcode, but it's one of many very sloppy things I noticed coming from a strong Unix background to Mac. There's a lot of really weird incongruence where the deeper you go into the system, the more everything feels covered in dust and neglected. I was always sold on Macs having really great top-to-bottom integration and have all the polish and attention to detail you can expect out of a corporate Unix-like, but that's not what I found. It's more like a really shiny superstructure bolted on top of an ancient, rust-eaten BSD. Don't get me started on how a lot of the "newer" stuff at that low level tends to be some of the absolute worst takes on a concept. The "App Sandbox" might be the most disgusting, slap-dash design for process isolation I've ever seen bolted onto a kernel. I get Apple's target market is quite literally the opposite kind of user that I am. That being said, I always find it curious that people still tout Mac as this kind of "Super Polished Desktop/Workstation Unix" and often cite the Unix certification. It feels like the more you try to use a Mac like you would any other Unix machine, the more you have to fight it. Often it doesn't feel any different to trying to wrangle Windows with WSL. I had less hiccups and trip-ups learning Plan 9 than I did coming to terms with macOS.
lsllc 2y ago
It's an exercise in recreating how an Objective-C app works in C from first-principles. For example, the creation of the AppDelegate (see CreateAppDelegate() in AppDelegate.c) is interesting because it shows how to create a class from NSObject and attach the applicationDidFinishLaunching: method along with it's implementation in C. I've used objc_msgSend() before from C (to access the pasteboard from a CLI app), but never implemented any ObjC classes using C! It's similar how you might attempt to build a C++ class from only C components by creating a vtable.

by 9dev 2y ago

As someone with no experience in native application development, could someone explain to me why this is significant? I have a rough idea, but I would like to understand it properly.

jojobas 2y ago

I guess it's normally impossible to write a GUI application for mac os without objective-c libraries doing the talking to the OS, but what do I know.

swatcoder 2y ago
It is not. This was just a new wave of people finally looking under the hood. (Where they would have found many many dusty but detailed man pages and docs waiting for them)
astrange 2y ago
You can write one in X11 if you like, if you make people install Xquartz.
- ngcc_hk 2y ago
  Is there example how to do that on mac. Just happy to have an old emu ibm 5100 sun x program. Wonder I need to boot up a vm or can try squartz …
  - jmb99 2y ago
    brew install --cask xquartz Or install from the project homepage [1]. Then just launch the X11 app. Note that it does require the application to be built for Mac - it’s not an emulator, just an implementation of the X11 APIs. [1] https://www.xquartz.org/ https://www.xquartz.org/
steve1977 2y ago
Beneath Cocoa are Core Foundation and things like Core Graphics for example, which both are C.

williamcotton 2y 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.

rankam 2y ago
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?
- detourdog 2y ago
  That is what objC scripting brige is for. https://developer.apple.com/documentation/scriptingbridge https://developer.apple.com/documentation/scriptingbridge
- jimbokun 2y ago
  I believe RubyMotion does basically this: http://www.rubymotion.com 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.
- CodeWriter23 2y ago
  There’s already PyCocoa and pretty sure *Cocoa exists for a variety of languages.
- flohofwoe 2y ago
  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).

swatcoder 2y ago

> why this is significant? Ultimately, because new people keep being born and missed the years where this was pretty common and haven't yet bumped into the corners where it still is. The repo and the SO discussion it was inspired by are themselves 11 years old and seem to be rooted in a new generation of iOS app developers starting to get more deeply curious about the system they're running on and how else it might be approached, which this person then ran with on MacOS. Apple invites people to get started in making software for their platforms using (what's meant to be) more accessible tooling like Objective-C, Interface Builder, Swift, SwiftUI, etc but there's of course a whole BSD-rooted operating system sitting there once those those developers start digging. It's no secret, but it's a discovery that some people need to make on their own.

LeoNatan25 2y ago
This isn’t an example of that. Have you looked at the code? This uses ObjC and Cocoa implementations in an unintuitive method. Nice exercise to learn about the ObjC runtime, but has zero practicality or use.
johnnyjeans 2y ago
The funny thing is, Apple themselves seems to have forgotten about the whole BSD-rooted operating system. Anybody who ventures off the beaten path of developing software for a modern Mac will inevitably encounter a lot of cobwebs. One of my favorites: When Apple implemented app bundles, they never updated dyld's search paths to be aware of the app bundle directory structure, meaning you have to manually patch your rpaths. Not a huge deal, and one that's hidden from you if you only ever know xcode, but it's one of many very sloppy things I noticed coming from a strong Unix background to Mac. There's a lot of really weird incongruence where the deeper you go into the system, the more everything feels covered in dust and neglected. I was always sold on Macs having really great top-to-bottom integration and have all the polish and attention to detail you can expect out of a corporate Unix-like, but that's not what I found. It's more like a really shiny superstructure bolted on top of an ancient, rust-eaten BSD. Don't get me started on how a lot of the "newer" stuff at that low level tends to be some of the absolute worst takes on a concept. The "App Sandbox" might be the most disgusting, slap-dash design for process isolation I've ever seen bolted onto a kernel. I get Apple's target market is quite literally the opposite kind of user that I am. That being said, I always find it curious that people still tout Mac as this kind of "Super Polished Desktop/Workstation Unix" and often cite the Unix certification. It feels like the more you try to use a Mac like you would any other Unix machine, the more you have to fight it. Often it doesn't feel any different to trying to wrangle Windows with WSL. I had less hiccups and trip-ups learning Plan 9 than I did coming to terms with macOS.

lsllc 2y ago

It's an exercise in recreating how an Objective-C app works in C from first-principles. For example, the creation of the AppDelegate (see CreateAppDelegate() in AppDelegate.c) is interesting because it shows how to create a class from NSObject and attach the applicationDidFinishLaunching: method along with it's implementation in C. I've used objc_msgSend() before from C (to access the pasteboard from a CLI app), but never implemented any ObjC classes using C! It's similar how you might attempt to build a C++ class from only C components by creating a vtable.