The Anatomy of a macOS App

> while that shown in blue is the stapled notarisation ticket (optional)

This is correct, but practically speaking non-notarized apps are pretty terrible to use for a user enough so that this isn't optional and you're going to pay your $99/yr Apple tax.

(This only applies to distributed software, if you are only building and running apps for your own personal use, its not bad because macOS lets you do that without the scary warnings)

For users who aren't aware of notarization, your app looks straight up broken. See screenshots in the Apple support site here: https://support.apple.com/en-us/102445

For users who are aware, you used to be able to right click and "run" apps and nowadays you need to actually go all the way into system settings to allow it: https://developer.apple.com/news/?id=saqachfa

I'm generally a fan of what Apple does for security but I think notarization specifically for apps outside the App Store has been a net negative for all parties involved. I'd love to hear a refutation to that because I've tried to find concrete evidence that notarization has helped prevent real issues and haven't been able to yet.

> When running a command tool in macOS, its Mach-O executable is launched by launchd, whose purpose is to run code.

That’s not what launchd’s main goal is and also not the path command line tools go through. They’re forked or spawned from your shell like any other UNIX system.

As side note, NeXTSTEP bundle system was the inspiration for Java's JAR files.

That first os screenshot made my heart sink; a reminder of how far we've fallen.

How I wish our operating systems still looked like this. Utilitarian, useful. No rounded corners and bubbly icons, reducing the useful space more and more each year.

The incredible quality of Mac hardware is the only thing keeping me from jumping to a thinkpad / omarchy setup.

A bit of a sharpshoot here, but Power Mac applications for classic Mac OS, including fat binaries, put the PPC executable code in the data fork. This was also true for CFM-68K binaries. Only old school 68K code went in CODE resources.

The old macos classic was a lot of fun, i remember using resedit on some apps at school.

Seeing bureaucracy explode like with the last diagram is rarely a good sign. As if I needed even more reasons to not "upgrade" to macOS 26.

While this is the "standard" macOS App structure, it is not the only one that works.

IIRC, you can put stuff in arbitrary subfolders as long as you configure the RPATHs correctly. This works and passes notarization. I came across libname.dylib in the nonstandard location AppName.App/Contents/Libraries . Not to be confused with /Library or the recommended /Frameworks location. However, there are basically no benefits compared to using the recommended directory structure, and none of the 100+ macOS apps installed in my system have a /Libraries directory.

No wonder everyone is building web apps. Operating systems are doing their best to make themselves obsolete.