> what do you actually want?

Give me the ability to choose what I trust. “You can either trust Apple and nobody else, even yourself, or you can trust literally everybody” is obviously not a good faith implementation of this. Apple excels at steering the narrative with false conflation and false dichotomy, I’d also remind you of the came-and-went secure boot debate, which Apple successfully steered into Apple owns the encryption keys vs no encryption, and people just kind of forgot to ask, wait, why can’t I have the keys to my device?

Rather than just having the options "Done" and "Move to Bin", give me an option to actually run it without having to manually go into System Settings each and every time without disabling security features?

The added friction feels more like a way to force developers to pay Apple an annual fee for distributing rather than for my safety. Not saying it doesn't help with safety, just that it's more weighed to the former.

> what do you actually want?

I want to be able to right-click on an app and choose "Open" to run the program with an authentication dialog. You used to be able to do this, but Apple removed it in favor of an incredibly annoying process of having to go into System Settings every time.

I do not think this is the right way. The right way would be for Apple to allow for a free Developer ID for distribution if the app is free and has no in-app purchases.

This provides IMO all-around goodwill while still adhering to good release practices.

10 seconds or 30 seconds, it's just too much friction to ask end users to do. I actually develop on a Mac, but I've written off Apple as a target system for hobby/open source projects. Between quarantine, code signing, and notarizing (which requires $99 a year), it's just not worth it. Good for Apple users if they like this shit--I'm just not going to bother with distributing to the platform anymore.

macOS is slowly getting like Windows, where, on a fresh install you have to go through and turn off all sorts of unwanted software just to have a sane environment where you, the user, are actually controlling your computer.

> what do you actually want?

To make gatekeeper happy without paying a large amount of money and own Apple hardware (same thing).

> what do you actually want?

A UI option would make sense. That is what most users are comfortable with.

> Any user who does not like Gatekeeper can turn it off on their machine in ten seconds by running this in a Terminal

For now. Enjoy it while it lasts.

> The user decides what code is allowed to run on their machines.

Apparently Apple disagrees, Apple decides. Typical users aren’t going to find their hidden 5 step process to enable non-blessed apps and obviously they know that. Gatekeeper is an appropriate name considering the user themselves are on the outside of the gate. It’s the culimination of everything Stallman and the FSF warned everyone about for decades. By its logic we should install police officers in our living rooms for safety.

> Pick one, you obviously can’t have both!

Obviously you can, and you actually could earlier where you could click a bypass button for a specific app without any of this terminal nonsense

> turn it off on their machine in ten seconds

You forgot to add the time to learn that it's possible and to find the right command

> So maybe it takes 30 seconds instead of ten seconds. That’s mildly more annoying, but still doesn’t really seem like a big deal to me.

That's because you keep ignoring the actual effort/cost even after you've learned your first simplistic estimate was a mistake

> but then, like, what do you actually want?

As an author of some homebrewed Go software in the past and trying to distribute in all 3 big OSes, I completely understand the blog post author's points. The problem is not Gatekeeper per see, it is just the combination of things that makes everything infuriating:

- I could justify going for the whole "Apple Developer Program" even with all the bullshit things you need to do to get certified if this was a one time payment like in Google Play Store. But it is yearly. Like the author, I would probably get 0 (or close to 0) dollars in recurrent revenue for those apps, I could justify a one time payment but a yearly one is ridiculous, it is not like Apple needs this money to be profitable (they probably get a much higher margins on selling things on Apple Store)

- Gatekeeper UX is infuriating. The equivalent on Windows (SmartScreen, as the author also cited) is still basically the same as Gatekeeper as far I understand (e.g., you need to have a valid certificate on your app or SmartScreen will deny the app execution until you clear the safety bit). But SmartScreen, different from Gatekeeper, has an actual good UX, as the error messages are clear and actionable (and also don't require a command line command to bypass)

- The author was still in a more "happy path" than me since their app seems to be a CLI only app. In this case just removing the quarantine bit with `xattr` works fine. In my case I was trying to distribute a desktop app, and I needed some special permissions to show notifications. This means I need to package my app in a proper `.app` bundle, include the required XML requesting the permissions and I am now required to sign the app. And since I am required to sign my app, I either pay the yearly payment fee to Apple to get a certificate to sign my app or I ask the users to resign the app with a self-signed certificate before launching

So really, I don't want that much actually. I can definitely handle all bullshit Apple wants, but I want at least a cheaper way to develop apps in their ecossystem. Maybe a new basic certification program that you have a one time fee and you can sign your apps but not notarize them. That way Gatekeeper would still complain, but at least my app would work without resign.

Or limit notarization to X amount of users (non-stabled notarized apps talks with Apple servers during the app first run, so they could just limit the amount of allowed tickets to X amount of users). If my app ever pass X amount of users, I will gladly pay the Apple tax, but 99USD/year for something that I will never see it back is too much.

Edit: BTW, I know, maybe 99USD/year doesn't seem too much for some. But Apple also doesn't do any regional pricing as far I know, and 99USD/year is crazy expensive in the country where I come from for example.

Edit 2: I am sure things are better nowadays with Claude/ChatGPT, but also trying to understand how to do the correct thing for your app is very difficult, especially if you're not using Xcode, since Apple assumes you're using it so all documentation refers to Xcode.

If you want to take the risk and install some unsigned software on your machine, go ahead, but don't blame Apple, who is gatekeeping for the entire ecosystem for making the decision to keep the restrictions in place so that the other 2.5 billion users don't fall victims to malware defenselessly. Also, as a rule of thumb in cybersecurity, never underestimate human flaws or overestimate your ability to overcome them. Even the most brilliant experts cannot possibly know everything and make zero mistakes, let alone "the users" you are talking about. It is pure illusion that "the users" know exactly what's running on their machine under the hood. We should be thankful that Apple is willing to hold the lines and go this far to tighten security up when nobody forces them to. It is probably one of the best thing coming out of Jobs' relentless push for privacy and security on the iPhone.

[dead]

This is not the developer choosing what software can run on their computer, this is Apple choosing for you and then you having to go disable protections (with what implications?) to then be able to choose what software you run.

This has more to do with putting up a scary dialog for normies than it does protecting anyone. A non-technical user isn't going to go bypass this in the terminal, they're going to run back to the App Store where Apple can collect that sweet 30% and analytics.

> Apple's contempt for backward compatibility

This is absolutely correct. Instead of maintaining any sort of ABI and API stability, Apple offloads a constant burden of maintenance updates across thousands of developers, just to keep existing apps from breaking every year with a new iOS version. This takes time which could be spent in more productive ways such as fixing bugs, adding features, or developing new apps. It seems like the wrong trade-off, since stability would offer huge, multiplicative benefits across the whole ecosystem. Apple does seem to want apps to die to mitigate the glut of shovelware in the app store, but there has to be a better way (human curation still seems like the only reliable approach for app surfacing and discovery.)

Most iOS apps are games, but in contrast to developing for other game platforms, iOS developers have to continuously update each game yearly simply to keep it working. (Not to mention Apple was happy to kill off 32-bit games on both iOS and macOS, and many games were never converted to 64-bit.) Compare to other handheld game platforms such as the Nintendo DS/DSi/3DS where games mostly kept working across major and minor hardware revisions along with dozens of firmware revisions from 2004-2020, or the Switch where games have generally worked from across Switch 1 and 2 from 2017 onward.

fwiw you can ship through Microsoft Store for free and not have to pay for signing.

Honestly, I kind of support this lack of backward compatibility. So many apps I use from big companies are still Intel based and leaving tons of performance on the table. This will finally force them to change when Rosetta is deprecated.

Open source apps are all native.

I have also written some notes. They are a bit out of date, but might still be useful:

https://successfulsoftware.net/2018/11/16/how-to-notarize-yo...

https://successfulsoftware.net/2023/04/28/moving-from-altool...

While I do agree with an overall sentiment, you can't seriously think this is a viable solution for most developers, surely.

To avoid having your application blocked by Windows SmartScreen, you need to pay extra for an extended validation code signing certificate. A normal code signing certificate is not sufficient.

Here's an eight year old Stack Overflow discussion of the issue:

> A guaranteed way to immediately and permanently get rid of the Microsoft SmartScreen warnings is to buy an "Extended Validation" (EV) code signing certificate from one of the Microsoft-approved certificate authorities (CA's), and to sign your app with that EV certificate.

Such an EV certificate will typically cost you somewhere between 300 and 700 USD per year (you better compare prices), and will only be issued to registered businesses. If you're a single developer, you must be a sole proprietor and have an active business license.

https://stackoverflow.com/questions/48946680/how-to-avoid-th...

Don't be fair. I finally signed up for an Apple Developer Account and it took weeks and I think it took weeks because I finally decided the system wasn't accepting my Driver's License uploads on my (Apple) phone because the camera's light was hitting the hologram which was reflecting back so I moved my application process to my (Apple) laptop and tried there and that's where I fell into a gully, as best I can tell: I somehow, in spite of using the same document throughout with my literal government-supplied ID on it that doesn't change, wound up in two competing applications. One of them seemed to succeed, the other one seemed to fail. On the plus side, they took my cash. On the downside, they did not give me what I bought and it took a couple weeks of re-uploading my PII, which in no way will ever bite me in the ass, to sort it out. All so I could get some vibe-coded slop I created onto my phone.

> I genuinely don't understand why so many developers are willing to compromise so much for a thin laptop.

Because many developers never run into these issues? A Mac has been my primary development machine since the G4 PB days. I’ve tried to switch to Linux a few times, and it’s always been a worse experience. Then I see these types of stories on HN, and I’m reminded we all use our computers very differently from each other.

It isn't just thin: they are quiet and fast with the best trackpads, reasonable keyboards that (except for the idiotic move when they released the touch bar and dropped the escape key) have a reasonable layout that doesn't change much, and all of the power states work correctly every single time.

I am the second most stubborn person I know in my friend group on this, and after only using a desktop for a couple years during the pandemic, I avoided having a mac laptop for the subsequent five years and it sucked. I finally caved after I realized the new M5 Macbook Air is actually likely to be faster for web browsing tasks and is somehow also (awkwardly?!) competitive at compiling code to the monster modern Xeon build I had just completed, and it doesn't even have a fan!

As far as I am concerned, it is over: Apple has won on everything except screen quality (I am sadly now addicted to OLED and I fundamentally disagree with the Apple position of not having a touch screen on a laptop, a stance that is only more emboldened now that I spend a lot of time with children).

It's not the thinness, it's the amazing battery life.

I think that's the most important part in the whole article.

This is a Claude Code tool for developers. I'd assume that any potential user for this tool should be perfectly able to run that xattr command (and if they are not, they probably shouldn't be playing around with Claude Code either... yup, some additional "gatekeeping" from my side here).

You could probably even make some curl -sL https://github.com/myrepo/installme.sh | bash script for these users which takes care of the xattr command.

Your typical macOS enduser does not use command line tools. Or they use something like Homebrew.

Btw the proper way to distribute binary would probably be pkg installer.

By default Windows 11 will not run an untrusted .exe/PE file - it's governed by Microsoft Defender SmartScreen that will present a pop-up scaring people away and it actually isn't intuitive to click-through to run the program unless you've done it before.

You can configure it in a way that it won't allow you to run it at all, but out of the box, you will receive a message which forces you through three clicks. Enough to scare off people with no deep knowledge.

And yes, you can turn all of that off.

The main difference is that on Linux you can do it on gui. It's much easier to explain and convice the user to click "allow executing file as program" checkbox than a xatttr obscure cli command.

There are many cases of signed & notarised software that pwned users.

Malicious actors can easily pay a fee - they're either running a business or they work for a state actor.

If that isn't already a violation of the developer account ToS, it would be in short order. The dialog is about keeping normal non-technical users (Apple's primary market) from straying away from the App Store where they can collect 30% and analytics. They're not protecting you, they're herding you.

The risk is that eventually you sign someone's malware and all of your customers have the certs that signed their apps revoked.

I'm totally interested in hearing more about this, please share more details about how you get this working.

I think almost all of Europe. Have you ever tried teaching a room of 30ish teenagers all high on quadrupled RDI of caffeine? It makes distributing software on macOS seem like a walk in the park

I was also taken aback by this, but apparently it's a real trend.

https://en.wikipedia.org/wiki/Age_restrictions_on_energy_dri...

Author is from Latvia (and so am I). You do actually get carded for energy drinks if you look under 30.

However, more relevant to the post, is that when you're ordering groceries online, you need to verify your age at checkout if you're buying stuff like alcohol (or energy drinks). It's trivial, and for a lot of people it uses the same authentication service that they already use to access their bank.

Under 16s can’t buy energy drinks in the UK

Edit: currently a voluntary but widespread scheme by retailers, proposed to be law. TIL

Only if you look 12

another feature of UK dystopia

The most important argument is phishing. People aren’t good at recognizing when a web site is legitimate. One reason that app certification is a shitshow is that recognizing bad players while minimizing false negatives and false positives is a difficult problem. Domain names fundamentally don’t solve that problem.

Because even with HTTPS that script might not do what you expect and then is too late, xz style attack.

> Apple's not making any money on developer subscriptions.

I think we're going to find out in a couple weeks, as Apple will be in court arguing over a reasonable commission to charge developers for using third party payments and their costs and developer subscription revenue are likely to come under a magnifying glass.

> millions of people have no issue with

I think that's a false dichotomy, consumers are not choosing Apple's developer policies and fees, and Apple has gone to great extents to keep consumers ignorant of their fees by banning mention of competing payment options and then burdening them with fees that ensure they can't be cheaper so the fees aren't obvious. This is not a choice consumers have made, it is a choice they have been deprived of.

> They don't want farting-around toys. They want developers to ship serious apps.

What users want to install on their own computer is none of apple's business though.

I don't even track the clicks, at this point the shortener is just an Apache2 container with a long config file and some shell scripts for me adding new links: https://blog.kronis.dev/blog/sometimes-dropbox-is-just-ftp-b...

Previously it was YOURLS but now it's the simpler setup, the whole reason for me adding it in the first place was that Grav (which is otherwise a lovely flat-file CMS) was really bad at handling query strings in Markdown, the actual links kept breaking quite often, even if I like it otherwise: https://getgrav.org/

I did write a bit more about messing around with the CMS and migrating to a more Git-driven setup rather than manually using an Admin UI for writing a while back: https://blog.kronis.dev/blog/my-blog-doesnt-need-quality-it-... (probably should have used "polish" instead of "quality" in the title but ehh who cares)

Not sure if it's been patched since, will probably look into it at some point. Might either migrate from the shortener to direct links at some point, or add an intermediate page: "You are about to go to: <URL>" with some buttons/countdown.

My apologies for the inconvenience until then.

It's only a problem if you want people to use your software

There's some official documentation for this process: https://support.apple.com/en-gb/guide/mac-help/mh40616/mac (and this works ok for terminal stuff too! Though it looks like the process will always fail to run the very first time, meaning you can't obviously pre-approve its first launch)

I believe that at least app-store apps are already ran in some sort of sandbox.

They want to have a way for users to pay them. Itch.io has that, homebrew doesn't.

homebrew voluntarily applies the quarantine flag on casks (ex: apps) so you still need to pay the apple dev tax to distribute your mini app that way, itch.io does not so you don't get the lying scarewall

Making it take some pain for developers is precisely what makes it valuable. If you could automate signing up for a developer account and didn’t have to put up some cash it would lose all value as a trust signal.

Just as a contrapoint to the other commenters, I've had Mac do this on PDFs that I myself scanned many years ago. Pretty sure they were not malware.

I suspect what triggered it was the fact that the files had journeyed through many filesystems in their time - HFS, ext4, NTFS, APFS - and they probably picked up some unholy combination of impossible attributes.

I thought it was pretty egregious to have Apple helpfully try to delete important PDFs that I've been lugging around for years.

In ten years of using Macs, I have never encountered this behaviour. I've never heard this from anyone else either. Is this new in Tahoe? I haven't upgraded yet, but your link seems to be from before Tahoe was released.

Maybe the PDFs were malware?

Sorry to say but your PDFs were malware. In 20+ years I’ve never seen this on my Macs nor the literal thousands I’ve managed with various MDMs.

Theres two different steps, there is signing and there is notarization. You sign with the developer certificate using productsign/codesign, and then there is notarization, which you use notarytool to submit your signed binaray to apple to notarize.

finally you then take their response and staple it to your binary. Its a lot of steps.

You have to distribute a "bundle" in a particular directory layout.

you need to pay the tax, they are doing the 'pay money to reduce spam' solution

https://signpath.org/ is about as close as you can get.

Probably in the minority here but I, too, went to the article hoping for objective quantification of the change in cortisol levels corresponding to the input, i.e. trying to distribute Mac software from scratch.

Doesn't that still require going though all the hoops that they were struggling with, or is this a different verification flow with Apple?

You talk as if the author doesn't know that.

That's literally what this post is about.