> 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.
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.
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.
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.
> 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.
I have quite a few gripes about the app structure while developing https://github.com/PeaceFounder/AppBundler.jl. The requirement (recommendation) to distribute shared libraries within the Frameworks folder, where each directory follows a strict structure, looks nice, but it’s a hassle to bundle the application that way. I am now using a Libraries folder to bypass this requirement, which appears during code signing.
My biggest issue, though, is Apple code signing. It’s already enough that a signature is attached to every binary, which seems wasteful. Why would anyone consider it better than keeping hashes of each file in one place and attaching the signature to them? Then there are entitlements, which are attached to the launcher binary when signed. Why couldn’t these just be stored in `Info.plist` or a separate file, instead of requiring this process?
And then there is notarisation, where at any point in the future, you might discover that your application bundle no longer passes, as requirements have become more stringent.
I've joined the Apple Developer program to be able to sign/notarize my Tauri app. And it's been three weeks that I'm failing to get the app notarized. I don't own a Mac so I'm using GitHub actions. Apparently the fact that notarization takes ages is very common the first time(s) an app is sent. I've spent nearly $100 on GitHub and my app still isn't notarized.
I contacted support and they don't want to help because I'm not using a Mac and using a third party framework (Tauri), even though it's just using xcrun, Apple's tool...
Also I've been unable to even use the notarization API to retrieve the submission logs and Apple didn't help for that either so far (they just disregarded my ticket).
I feel powerless and abused. This is the worst DX/CX I've had in years.
As a side note, authenticating against the notarization API is a nightmare. You get a PKCS8 that you have to use to create/sign a JWT and you're basically on your own... I had to build a little node program just to craft the JWT...
12 comments
[ 3.5 ms ] story [ 31.7 ms ] threadThis 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.
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.
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.
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.
My biggest issue, though, is Apple code signing. It’s already enough that a signature is attached to every binary, which seems wasteful. Why would anyone consider it better than keeping hashes of each file in one place and attaching the signature to them? Then there are entitlements, which are attached to the launcher binary when signed. Why couldn’t these just be stored in `Info.plist` or a separate file, instead of requiring this process?
And then there is notarisation, where at any point in the future, you might discover that your application bundle no longer passes, as requirements have become more stringent.
I contacted support and they don't want to help because I'm not using a Mac and using a third party framework (Tauri), even though it's just using xcrun, Apple's tool...
Also I've been unable to even use the notarization API to retrieve the submission logs and Apple didn't help for that either so far (they just disregarded my ticket).
I feel powerless and abused. This is the worst DX/CX I've had in years.
As a side note, authenticating against the notarization API is a nightmare. You get a PKCS8 that you have to use to create/sign a JWT and you're basically on your own... I had to build a little node program just to craft the JWT...