Any user who does not like Gatekeeper can turn it off on their machine in ten seconds by running this in a Terminal:
sudo spctl —-master-disable
People will say, no, that’s too big a hammer, it’s not safe… but then, like, what do you actually want? Either you keep Gatekeeper because you like the friction it introduces, or you don’t like that friction and you should go turn it off. Pick one, you obviously can’t have both!
Of course, you as the developer can’t make this choice for your users… but isn’t that as it should be? The user decides what code is allowed to run on their machines. And the default setting is restrictive because anyone who knows what they’re doing can easily change it.
P.S. Meanwhile, on iOS there’s no way to install unsigned software at all, and on Android (starting soon) the process takes 24 hours instead of ten seconds. That is actually ridiculous because it’s taking away user choice.
P.P.S. To be clear, modern macOS has plenty of other restrictions which can’t really be turned off and which I find super annoying. Gatekeeper just isn’t one of them.
Edit: I’ve just learned that as of Sequoia, you have to also tick a box in Settings after running the Terminal 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.
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?
Exactly, Apple is making this a black and white choice on purpose. To make it unattractive to bypass them, and introduce legitimate security concerns if you do so. But those don't have to exist if the options were more fine-grained.
The same with SIP (system integrity protection). You can turn it off but then you have to turn it all off.
There's no way to keep secure boot but bless your own changes and sign them in some way, that you have approved. You know, as the owner and admin of your own computer. It's either leave it to Apple or be completely on your own. And to make the choice even more uncomfortable they also disable some features like running iOS apps.
I think you should read up on how secure boot works with macOS and alternate operating systems before speaking this negatively about the implementation. Apple is already giving you exactly what you’re asking for.
It’s not really even that different than a PC motherboard that gives you “Windows UEFI” and “enroll my own keys” as options.
As far as code signing, again, what do you want Apple to do here? They already gave you a master switch to turn it off. You are free to turn it off then implement your own third party code signing solution if you’d rather choose who you trust. It’s not Apple’s fault if nobody else decided to make their own trust repositories and the only alternative on the market is to have no safeguard at all.
And let’s not forget who Apple markets their computers to. These features aren’t for you and me, they’re for the non-technical customers who will absolutely get pwned by unsigned code. Go to the MacBook Neo marketing page and try to find a single image of someone writing code or even being gainfully employed.
> 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?
The Asahi Linux folks are building their own SecureBoot chain[1].
I guess you could argue they shouldn't have to do that. But it feels reasonable to me that that the party you're trusting should be the one who builds the trust chain.
I don’t disagree with your post but I’m still unclear on how you envision gatekeeper should work.
You want the ability to choose a different “authorities” that verify and sign binaries? That makes sense to me but is unlikely to relieve any of the issues in the post.
Also what do you mean by “even yourself?” What would that option look like?
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.
I also have things I want to change in gatekeeper, but that feature is not one of them. Just gut feeling but I would say 110% of all users, would just click ”start” on every unsigned app if it was that easy.
With Gatekeeper turned off, you’ll still get a warning on first launch which you can easily click through. (Unless Apple changed something in the last few versions—let me know if that’s the case—but it would be out of character for them to remove a warning...)
The “security feature” you don’t want to disable is precisely the thing you are complaining about, so I don’t understand why you’d keep it around.
> The added friction feels more like a way to force developers to pay Apple an annual fee for distributing rather than for my safety.
I don’t imagine Apple makes a substantial amount of money from $99/year developer subscriptions. The App Store is another story of course.
Posit it saves a decent number of folks who are unable to follow the scammer’s necessary instructions:
“Press command space, no no hold down the command key - gosh it’s in the bottom left - okay, now type “privacy”, now scroll, no you scrolled too far …”
I remember you used to be able to right-click and then press open instead of double-clicking which would bypass gatekeeper just for that run. Not sure if it still exists though, I don't have any unsigned apps handy to test.
>give me an option to actually run it without having to manually go into System Settings
I've run several PiHoles for several years, primarily on latest versions (up to v5; current is v6.4.x) – recently updating to v6 has been extremely frustrating [0], e.g: realizing that even when you tell the pi's/en0 ("internet") interface to use a specific DNS server (in GUI/network settings), it still uses the DNS-server recommended by your local DHCP server [1].
[0] I am aware that this is a joint-issue between RaspbianOS and Pi-Hole teams
[1] which requires TWO sudo nmcli which newbs have no business configuring – what happened to -simple- ?
----
If you ever want to consider how crazy DNS-capture is getting, realize that Firefox/&c are all dark-patterning the abilities to turn off "secure"-DNS. The latest Raspian/Pi-Hole defaults are terrifying... [2]
[2] another example: why doesn't v6 enable HTTPS localhost web-access, by default (like all previous versions?!)? Do the developers really expect us commoners to know how to generate localhost certificates – this is obviously behavior due to how the pihole useraccount behaves differently then the previously-root-blessed v5-behavior
----
Thankfully, I've kept a local copy of my favorite distro of Pihole v5, and it is readily-cloneable.
When I attempted to pass a --version tag during a freshinstall (requesting v5 from remote installer), it went ahead and installed latest v6 (so why even.?!).
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 guess I just don't understand why this makes such a big difference to you versus having Gatekeeper off? You're asking for a very specific flow, where you can run anything but only if you right click the app instead of double clicking the app.
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.
> People will say, no, that’s too big a hammer, it’s not safe… but then, like, what do you actually want? Either you keep Gatekeeper because you like the friction it introduces, or you don’t like that friction and you should go turn it off. Pick one, you obviously can’t have both!
Refusing to let you open an app isn't friction, it's complete obstruction. How about warning you and letting you run it this one time or allow it to run normally from there on?
You can still open unsigned apps with Gatekeeper on, you have to go into Settings to whitelist it. I find this extremely annoying, but as I said, that's the point of Gatekeeper, if you don't like it then turn Gatekeeper off.
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.
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.
Are there any groups of open-source developers who have gotten together to share a group account and the $100 cost per year? Forming an informal-ish organization, with just enough formality to be a legal organization in whatever jurisdiction they live in, so that they're legit enough to satisfy Apple's requirements? Not trying to hide anything, just trying to pool resources in an open and above-board way.
Or would Apple categorically reject an application like that?
I don't develop on Macs myself so I wouldn't know where to start looking, but I can't help but wonder if that would be a viable answer for many people who don't want to pay $100/year to give software away for free. Get twenty people together and $5/year doesn't feel like too much.
> 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.
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.
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.
I have been developing software for Macs and PCs as an Indie for 20 years now. I sympathize with the author of the post. You get the feeling that Apple thinks you should be grateful that they allow you to develop apps for their platform.
The author didn't mention Apple's contempt for backward compatibility. Apple like to regularly nuke their entire developer system from orbit. Try running an app developed 10 years ago on the latest version of macOS. It probably won't run.
Microsoft are much better at backward compatibility and they don't force you to join a developer program. But you get totally reamed every time you have to update your authenticode digital certificate for Windows. Just the digital certificate will cost you more than $99 per year. It is a total racket.
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.
Maybe it’s worse for games, but I’ve been maintaining non-game apps on both iOS and Android for many years and keeping the iOS halves functional has generally been pretty chill. Updates aren’t required all that often and it’s rare that APIs break entirely on me, especially if targeting older SDKs. Usually the worst post-WWDC fallout is needing to recompile the app in question with minimal changes.
By comparison, Android is much worse. The Play Store kicks you off for not submitting updates much more quickly and the whole ecosystem is in a permanent state of simultaneous flux and obsolescence. Whatever deity help you if you let an Android project collect dust for a year or two… you’re gonna be fighting battles on multiple fronts getting everything up to date. Gradle conflicts, APIs getting deprecated without fully baked replacements, divergence in behavior between OS versions… it’s a real hoot.
> 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.)
I keep trying to explain this to people but it's hard enough to describe the issue, even harder to get people to care, and an impossible battle to change Apple. I don't actually think they're doing this to kill old apps. I think it's a very cynical and calculated plan to require developers to actively maintain their applications, *thereby requiring the use of subscriptions as the only viable business model for developers.* That is Apple's primary revenue stream by far, and they're making far more money now that we have to subscribe to workout apps instead of buying them once and using them for years.
Ios actually is far better than macos for old apps. I have a few ancient maybe 8-10 year old ios apps on my iphone that have not received updates and still work fine. Can’t say the same for macos because they decided to drop 32bit support.
Contempt.
use any apple device 2 updates back or more. you're screwed.
You would accept this in no other place in life, except that apple gives it for free, and puts a 'security' sticker on the box.
It's a racket. Planned obsolescence 2.0 - Users forced to update, update removes features, breaks working apps, breaks paid for ip ( literally removed from phones), apple blames the devs. bullshit.
It's much more expensive on Windows side of things. DigiCert and Sectigo are now in the $700--$1000 range per year for regular OV code signing certificate.
Microsoft has it's own Azure Artifact Signing which is comparable to Apple yearly cost (give or take), but since a month ago installers signed with it often display SmartScreen warnings [1]. Even though Microsoft controls both pieces!
Store option is not free for organizations (although it's a one-time setup fee), but the worse thing is it forces you to its simplified licensing/trial model, typically not compatible with B2B software where paid upgrades, yearly support contracts, controlled updates, extended trials are used.
Would be interested to hear a bit more about selling commercial software through the MS App Store. My Easy Data Transform software has a free trial (7 days, do not have to be consecutive) and is a one-time fee of $99 to buy. How would that work?
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.
The alternative to this was continuing to optimize Rosetta while simultaneously processors improve, soon enough the performance gap wouldn't matter in the slightest. By the end of the decade you'd probably be comfortably running that software on a MacBook Neo w/ A20 Pro.
Rosetta and its underlying tech enable 10,000s of games and applications to run so it's a tremendous loss overall, it doesn't sound like much will be left if this means x86 OSX games:
> "we will keep a subset of Rosetta functionality aimed at supporting older unmaintained gaming titles, that rely on Intel-based frameworks"
Mac used to have a lot of great shareware from indie devs. Some of them have shut down and their apps will eventually stop working. Kinda annoying when I can play the windows port of a game on windows but not the original Mac version
I shared the author's frustration when figuring out how to ship such binaries to end users so I wrote a guide [0] detailing exactly how to do it. Apple's documentation is surprisingly poor and I couldn't find any blog posts so I ended up reverse engineering what works via trial and error as well as popular OSS projects on GitHub.
Author here, just pushed a quick update to the article.
To be fair, compared to the prices of Certum and other providers if you ever want to sign something for Windows, perhaps Apple isn't uniquely overpriced (they all seem to be that way): https://www.certum.eu/en/code-signing-certificates/
Looking more into the Windows side of things, I also found Azure Artifact Signing which is supposedly affordable at 8.54 EUR per month, but unfortunately they don't actually support individual users in the EU (only in US & Canada, meanwhile EU only gets support for organizations). I'd probably have to set up a SIA (equivalent of Ltd.) here first - it was in the plans for later, but this is a bit of a roadblock for using Azure too: https://azure.microsoft.com/en-us/products/artifact-signing
My tone might have been frustrated, but I will absolutely say that the code signing industry needs to have a Let's Encrypt moment of some description - at least commoditize it like Azure Artifact Signing was trying to do, but also for individual developers, across all platforms! Sadly, that doesn't seem to be possible when the platforms are intentionally walled gardens. I don't hate the idea of code signing, though - if done right, it's a good idea, same as TLS for (many) websites.
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.
The only option to avoid a SmartScreen prompt from day 1 on Windows is to distribute through Microsoft Store, end of story.
If you sign it yourself, via Azure or your own $200/year cert, you will get a SmartScreen prompt initially, but the prompt will stop appearing once the file hash has sufficient download history. There is no exact threshold, but it can take several weeks and hundreds of clean installs from a wide audience.
I have an OV cert for Windows, which is expensive enough. I just make sure to do a snapshot release using the new certificate to existing customers (through my newsletter and forum) a while before using it for new customers. That way there is time for the scary warnings to go away before any new customers see them.
Digital certificates providers are basically checking your id (mostly automted) and multiplying 2 prime numbers together. Then charging you several hundred dollars. A 1 year Sectigo certificate EV with USB key is $431.99. Nice work if you can get it.
I don't think this is true. A normal CS signing cert is sufficient for most commercial apps - you will get the SmartScreen warning for a few days but it will go away fairly quickly.
The important part is that SmartScreen reputation is URL-based, you need to make your initial download URL consistent. If you are constantly rewriting it (i.e. with a version #) it will break. It's ok if the original URL hits a 302 to the latest version.
Azure Artifact Signing and Apple's Developer program come out to similar costs. Apple's is probably still cheaper in that you can sign any number of things with it.
But yes, it would be nice to have some free signing options for open source developers.
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).
> I am sadly now addicted to OLED and I fundamentally disagree with the Apple position of not having a touch screen on a laptop
Both of these are reportedly coming to the MBP this year (lately rumoured to be next year), although there's going to be a steep price to pay and rumours say it will still just have the MacBook's normal angular range so no good for drawing or iPad apps.
Apple is so far ahead of everyone it's sad but they're catching up and Apple is so unflinching on so many topics it handicaps them, we could be stuck with touchscreen Macs that aren't useful for iPad apps for many years, and later this decade ARM chips will start nipping at the heels of the Pro and Max chips while build/component quality is rapidly improving too.
The last thing I want is a touchscreen laptop. Wouldn’t that be great adding stupid cost solely for the ipad kids to not feel so alarmed. Nothing like reaching your hand up unsupported to poke at a screen right? Gotta love the fingerprint smudges too and the eventual loss of the concept of an information dense ui entirely as ui elements need to be clicked with the imprecision of your elbow now instead of the mouse.
I use my Macbook for things other than dev work, and that's where Linux tends to fall flat. Weird hardware incompatibilities, jank, huge amounts of time required to maintain the machine rather than just getting work done.
Having to occasionally run xattr -d com.apple.quarantine to download some random low-userbase FOSS app is nothing compared to what Linux users go through.
This was perhaps the biggest reason I moved to Linux full-time about a year ago. I just got sick of not being able to write software and have people use it. The solution might be an "I trust this author" VS Code style dialog and that's it, but even that misses the mark a bit. I've been having a blast building on Linux and miss almost nothing about macOS. And the things I do miss I write programs for [1][2] and give them to people. Who would have guessed that would ever be so hard.
Packaging software for Linux users is a nightmare. Unless
- your program is extraordinarily simple
- you can manage to statically link libc
- you can ship (or statically link) all .so files
- you can ensure your app can run in a sandbox
- you limit the distros you build for
- your app can be built by whatever is on flathub
etc., most solutions to shipping software simply don't work out-of-the-box. Despite the kernel being reasonably stable, userspace APIs are a mess of incompatible.
This is a great point, and you are right. However, using cpack+cmake makes the packaging pretty easy, gets the dependencies right for you. The problem is in dealing with all the package various manager repos.
macOS and Windows both used to allow running arbitrary binaries from a web page. Linux GUI users get away purely because it’s unpopular target for as scammers, once naive grandmas and 12-year olds start using it, I’m sure there will be comparable amount of hurdle to just give another person a binary.
So, Linux gets a free pass for requiring chmod +x to run his tool, but needing to run xattr on MacOS is somehow worthy of an entire blog post to complain about it?
Serious question - Is it really true that Windows 11 will run an untrusted .exe without a warning?
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.
But after enough people run it, that disappears. They implement crowdsourced trust, because it isn't a rent extraction exercise but actual concern about malware.
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 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.
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.
Ugh. I just went through this ID verification process yesterday and I got it to work on /maybe/ the 8th try. Truly horrible design. Now I’m in a paperwork exchange with some random third party to get the account associated with my LLC. It would be awesome to be able to just write and distribute software, but there’s only one iOS monopoly so what are you going to do but play ball.
1 year ago i would have agreed with you. Today, I'm going to take the other side on this. The amount of malicious code embedded in software now is going up exponentially. Yes this is a painful tax imposed on all software, malicious or not, but until they figure out a better system, this system actually will disuade a certain percentage of malicious actors to give up - ESPECIALLY having to pay a fee. As a mac user, i want to know if the developer has paid a significant fee to get this software to me. It a useful signal for me. If they didn't pay and didn't upload their passport, I really want think think hard about the risks involved for myself when I run this thing.
Sure, but the more barriers there are the better because it still reduces the number of threats. That’s why people choose to rent walled gardens. Otherwise, Linux would have higher adoption even among our crowd.
If you really value freedom over everything else, I don’t see value in putting bad bandages over closed platforms. Might as well just switch to an open one.
The $100 isn't the deterrent. It's the having to pay (+ use a new identity/entity) every time you have to sign up for a new Developer account because Apple revoked your cert when it caught you distributing malware.
My favorite is when someone discovers they haven't yet granted Zoom screensharing permission, and that they need to exit the call to re-launch the application with the permission granted.
As a user I actually like Gatekeeper. 95% of the time it's not a problem. the other 5% of the time I have to click a button in my settings to allow unsigned code. But at least it gives me pause to think about the source and if I really trust it (which is mostly offloaded to Apple the other 95% of the time).
Free business idea: get an Apple developer account and then agree to sign code for other people in exchange for a small piece of their income. I'm surprised that doesn't exist yet (or does it?).
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.
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.
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 spent the better part of a week failing to create an Apple account using my studio domain - not even a dev account yet, just any account at all. In large part because of the "I got frozen out and can't talk to anyone" horror stories that pop up here monthly, and the fact that my personal account already needs to go through the "your account is locked" dance on a daily basis. My best guess is constant credential stuffing plus lack of any Apple mobile device.
The main creation flow wouldn't send a verification email, and there are hints around to try through Apple Music, which got me a little farther. At phone verification, I receive the code fine (on both numbers I tried), type it in, and get an inscrutable "error" that prevents finalization.
But it turns out it was final enough that even though I can't log in at all, they felt fine sending me Mother's Day email spam. Thanks. I'll be sure to FaceTime her.
Had an eerily similar experience trying to set up a fresh personal iCloud account for my Mom. Effectively, feels like she's permabanned based on the phone #. Exhausted all possibilities and gave up.
Sometimes I wonder why we don't just treat an installation script like curl https://alx.sh | sh as a universal option for distributing applications. The provenance is there via the HTTPS certificate, and if you're already about to trust an application that can compromise your system, why not trust the installation script as well?
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.
It's interesting that sanctioned Russian banks still find the ways to push their apps into Apple repository by disguising them as a different app. They get removed several months later, but I assume it is done only because someone complains.
Funny how a $20 cert is enough to prove identity and provide security for any domain on the web, but in order to run a calculator Apple hw, Apple HQ is the only entity on the planet capable of such complex security.
It has been like this forever and periodically someone complains, but then they just go out and buy another mac and keep producing software for macOS. If you want this to change, stop providing financial support.
Apple's ID verification failed for me and I am now banned for life. There is no opportunity to appeal this or to ever participate in the Developer Program for me. Which sucks because I am now permanently locked out of developing seriously for any of the Apple ecosystem, ever.
If I am understanding this correctly, the $99/year Apple Developer Program allows you to notarize applications for macOS so users do not receive the warning/damaged binary dialog. I simply had AI generate the signing code, and you can run that script on any CICD or on your machine and push the artifacts to a CDN. Works wonderfully for macOS, and users of my app have had no issues with it.
Let me know by replying here if you want me to share the build+sign code or have any questions.
This is exactly the sort of paternalism which drove me away from the Mac in ~2015, after I'd been using Apple hardware for thirty years. It's just too much hassle for a casual developer; I'm stuck on the belief that it is my computer, not Apple's, and I should be the one deciding what I can do with it.
On a meta note, no one uses link pages like https://links.kronis.dev/NAnEME3Kqt any more. There are better ways of tracking clicks without obfuscating the destination page from the user.
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.
Plenty have dropped mac support even major devs that used to support it well. Paradox interactive no longer develops for mac. Valve also no longer develops for mac.
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 went through this recently. Got as far as verifying my identity, which Apple happily accepted as verified from my UK driving license. Unfortunately, they then automatically set my first and last name from that identity verification step, and some how managed to use a section of my driving license number as my surname - a string of random uppercase letters and numbers - and it's impossible to edit it. So fuck them, that's $99 they've lost.
I don't get the part about Homebrew. If you're using Homebrew, it doesn't make a ton of sense to use Itch.io. Just use Homebrew. Seems like a more appropriate place to distribute a dev tool anyway. You could set up a patreon and print a link to it when appropriate. That's basically what Vim does.
Okay, but then the argument that Apple is charging them to certify their software and that is excluding hobbyists falls away doesn’t it? Now you’re not a hobbyist.
There is no reason to tie the method of payment together with the method of distribution. They could distribute it through brew along with an optional license configuration.
Downloading a cli from a browser is not convenient anyway. You need to copy the downloaded file somewhere that is loaded into the PATH.
And also, software that is downloaded from itch.io app does not require notarization.
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
Apple's not making any money on developer subscriptions. I suspect they just want to have a velvet rope, to encourage folks to be serious about their work. They don't want farting-around toys. They want developers to ship serious apps.
There'$ a rea$on that $o many people want to relea$e Apple app$. A $uperb rea$on.
It's a really lucrative market. People like to have access to customers that are used to paying a lot. One of the reasons those customers want to pay more, is that walled garden that HN members hate so much, but millions of people have no issue with (whether or not that's a good thing, is not for me to ponder. It just is).
99 bucks is peanuts. It does give you access to the entire suite of Apple tools. Anyone interested in shipping serious software, is likely to far exceed that, in the non-Apple (or Apple hardware) tools that they use to develop the software. Heck, your keyboard probably cost more than that. I remember that we used to pay Microsoft over $4,000 a year for their developer program.
Here's what Apple says about it[0]. That's what I usually do. I think someone else has shared the command line method. If it's a developer tool, then it would probably have a difficult time passing Apple's app review process, anyway, and that will really jangle your cortisol pipes.
> 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.
If I had been positing it as a developer issue, then that would be true.
However, I was talking about the customer experience, not the developer one. There's no question at all. People pay a premium, and have no issues with the walled garden.
Just because I don't like something, doesn't mean that everyone else shouldn't like it, either. I may not be wrong in my rancor, and they might not be wrong in their acceptance.
One thing that customers are disliking, though, is the buggy and overcomplicated mess that Apple operating systems have become. I am hoping that they do another across-the-board "Snow Leopard" release. From what I hear, that's likely. It might end up making the developer experience a bit more frustrating, though, as they may be demanding more from us.
I've been shipping Apple-based software since 1986, and have found myself screaming with rage at them, many times, in those 40 years; but I never stopped developing for the platform. I guess I'm a walking exemplar of The Stockholm Syndrome.
I am not entirely against the whole notarization thing.
If it is good for the end-user, it is usually also good for the ecosystem a a whole, trust is valuable.
But ffs, they are rich enough to make this a lot less painful and hostile for developers.
And this is not a new thing, I used to develop games for iOS, from the very beginning, and while the process somewhat simplified over time, it was a huge cortisol inducing process, not to mention the regular forced OS+SDK updates where the procedures changes almost every time and could fail in not-so-evident ways.
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.
The cash part is not even the worst, even if this is obviously ridiculous for free/open source projects.
The bad UX is really what irks me. Enough that I may entirely opt-out of the Apple ecosystem forever, and I don't think I am the only one feeling that way.
distributing for macOS is extremely hostile and Apple continues to extort developers through fees, yearly subscriptions, and of course taking 20-30% in transaction sales.
This made me think of a potential workaround that would have a better UI: create a directory (maybe named 'Trust Zone'), and have it watched by something like automator. As soon as you move a file in there, it reacts and remove the quarantine bit on that file.
The enrollment app on Mac OS feels like a second citizen. I think Apple is slowly giving up on ensuring the experience on its own Mac apps is working as well as on iOS. I hope to be corrected now that the Macbook Neo is more popular, but I won't be holding my breath.
It seems like running with sandbox-exec should remove pretty much all the potential for an app to cause harm… is there a reason why it’s not the default, especially for these certificate-less apps?
Maybe I'm too dumb, but I haven't figured out a good way to sign just a binary (or a tar/zip containing a few binaries). I zipped up the binaries, sent them off to Apple, Apple comes back and says "yup, notarized!", and they still trigger the popup. I'm probably missing a step. I guess I'm not currently stapling the ticket to the binary, but supposedly you don't have to if you are running with a network connection.
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.
> I guess I'm not currently stapling the ticket to the binary, but supposedly you don't have to if you are running with a network connection.
AFAIK, you do in fact have to staple the ticket. The other thing I found is that you have to make sure you're using the right kind of certificate from Apple.
it’s as if apple forgets that some of it’s user base are people who scrap together money over long periods of time just to have a chance at affording a mac only to be told they need $99 to distribute an app. your entire user base isn’t 100% affluent people and apple doesn’t seem to grasp this
I love when my Mac declares random PDFs malware and deletes them when I try to open them.
On two occasions I've been completely dumbstruck when the software I was using was deleted out from under me. I'm not a fan of the overuse of "gaslight", but it sure felt like that when I had to restart Docker and the OS was like "what do you mean, Docker? You've never had Docker installed! What are you talking about? Are you feeling ok?"
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.
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.
I'm really trying to remember the context, I wish I'd written it down somewhere. But now that I'm thinking of it, I'm almost certain it wasn't PDFs, but JSON files that I'd written. For some reason it would allow me to open them in some applications, but in others I'd get a warning and the file would be trashed.
The Docker thing happened as described in my linked post. It happened with something else too, but again I can't remember. I wasn't planning on doing a post mortem so I guess I let the details slip!
In any case, I do like most of the OS' ways of doing things, including security. But it can be overzealous.
Bro i feel you so much! i am developing an app aimed at Intel Macs, but i cannot even publish it, because you need a Silicon mac to use the Apple Developer Program. It's so unbelievable brainless. The market still holds 10-20% intel devices, especially outside the US and in some high-end environments, where 128GB RAM machines cannot easily be replaced with a silicon mac.
Sometimes it feels like Apple has no clue how their users actually work and what the industry needs.
I just went through this with a small paid macOS menu bar app. The hardest part was not the code, it was figuring out which app store rules I had accidentally stepped on- app name wording, accessibility permission assumptions, and even cmd+q behavior.
The review did eventually pass, but the process felt much more fragile than shipping the product itself and i had to remove one key feature of the app as well for the review to pass.
Due to the delays in ID verification the author of the article didn't even get to the point of the super annoying 'notarization' process where you can't just sign with your key anymore (as you could a few versions ago) but you also have to upload a copy of everything to Apple and 'staple' their ok to it.
At least I don't think they got to it, they only mention signing but not notarization.
Honestly painful to read. I tried to distribute a free utility to
some friends last year and bailed somewhere mid-enrollment. Just
wanted maybe ten people to download a thing. The whole flow felt
designed for someone shipping to millions and I just couldn't
justify it for what I was actually doing.
Cortisol spit curve tests are pretty cheap, so I was disappointed to see the title claim not substantiated with real data. Consider biometric testing next time you distribute!
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.
Honestly, for most open-source apps where you don't want to Deal with this, the answer is to just get it into Homebrew. They handle re-signing apps using the local computer's ad-hoc signature and for most apps this is by-far the easiest way to deal with Stupid Apple Bullshit.
Any user who does not like Gatekeeper can turn it off on their machine in ten seconds by running this in a Terminal:
People will say, no, that’s too big a hammer, it’s not safe… but then, like, what do you actually want? Either you keep Gatekeeper because you like the friction it introduces, or you don’t like that friction and you should go turn it off. Pick one, you obviously can’t have both!
Of course, you as the developer can’t make this choice for your users… but isn’t that as it should be? The user decides what code is allowed to run on their machines. And the default setting is restrictive because anyone who knows what they’re doing can easily change it.
P.S. Meanwhile, on iOS there’s no way to install unsigned software at all, and on Android (starting soon) the process takes 24 hours instead of ten seconds. That is actually ridiculous because it’s taking away user choice.
P.P.S. To be clear, modern macOS has plenty of other restrictions which can’t really be turned off and which I find super annoying. Gatekeeper just isn’t one of them.
Edit: I’ve just learned that as of Sequoia, you have to also tick a box in Settings after running the Terminal 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.
> 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?
Exactly, Apple is making this a black and white choice on purpose. To make it unattractive to bypass them, and introduce legitimate security concerns if you do so. But those don't have to exist if the options were more fine-grained.
The same with SIP (system integrity protection). You can turn it off but then you have to turn it all off.
There's no way to keep secure boot but bless your own changes and sign them in some way, that you have approved. You know, as the owner and admin of your own computer. It's either leave it to Apple or be completely on your own. And to make the choice even more uncomfortable they also disable some features like running iOS apps.
I think you should read up on how secure boot works with macOS and alternate operating systems before speaking this negatively about the implementation. Apple is already giving you exactly what you’re asking for.
It’s not really even that different than a PC motherboard that gives you “Windows UEFI” and “enroll my own keys” as options.
https://asahilinux.org/docs/platform/security/
As far as code signing, again, what do you want Apple to do here? They already gave you a master switch to turn it off. You are free to turn it off then implement your own third party code signing solution if you’d rather choose who you trust. It’s not Apple’s fault if nobody else decided to make their own trust repositories and the only alternative on the market is to have no safeguard at all.
And let’s not forget who Apple markets their computers to. These features aren’t for you and me, they’re for the non-technical customers who will absolutely get pwned by unsigned code. Go to the MacBook Neo marketing page and try to find a single image of someone writing code or even being gainfully employed.
19 replies →
> 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?
The Asahi Linux folks are building their own SecureBoot chain[1].
I guess you could argue they shouldn't have to do that. But it feels reasonable to me that that the party you're trusting should be the one who builds the trust chain.
1: https://asahilinux.org/docs/platform/open-os-interop/#m1n1
I don’t disagree with your post but I’m still unclear on how you envision gatekeeper should work.
You want the ability to choose a different “authorities” that verify and sign binaries? That makes sense to me but is unlikely to relieve any of the issues in the post.
Also what do you mean by “even yourself?” What would that option look like?
9 replies →
I want the ability to run any linux distro on my macbook, like I can with any other computer that is not a macbook.
3 replies →
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.
I also have things I want to change in gatekeeper, but that feature is not one of them. Just gut feeling but I would say 110% of all users, would just click ”start” on every unsigned app if it was that easy.
8 replies →
> give me an option to actually run it without having to manually go into System Settings each and every time without disabling security features?
People reflexively hit yes to these things.
4 replies →
> without disabling security features?
With Gatekeeper turned off, you’ll still get a warning on first launch which you can easily click through. (Unless Apple changed something in the last few versions—let me know if that’s the case—but it would be out of character for them to remove a warning...)
The “security feature” you don’t want to disable is precisely the thing you are complaining about, so I don’t understand why you’d keep it around.
> The added friction feels more like a way to force developers to pay Apple an annual fee for distributing rather than for my safety.
I don’t imagine Apple makes a substantial amount of money from $99/year developer subscriptions. The App Store is another story of course.
4 replies →
Posit it saves a decent number of folks who are unable to follow the scammer’s necessary instructions:
“Press command space, no no hold down the command key - gosh it’s in the bottom left - okay, now type “privacy”, now scroll, no you scrolled too far …”
2 replies →
I remember you used to be able to right-click and then press open instead of double-clicking which would bypass gatekeeper just for that run. Not sure if it still exists though, I don't have any unsigned apps handy to test.
1 reply →
adding a button means osascript driven malware could approve itself and you might not even see it happen
1 reply →
>give me an option to actually run it without having to manually go into System Settings
I've run several PiHoles for several years, primarily on latest versions (up to v5; current is v6.4.x) – recently updating to v6 has been extremely frustrating [0], e.g: realizing that even when you tell the pi's/en0 ("internet") interface to use a specific DNS server (in GUI/network settings), it still uses the DNS-server recommended by your local DHCP server [1].
[0] I am aware that this is a joint-issue between RaspbianOS and Pi-Hole teams
[1] which requires TWO sudo nmcli which newbs have no business configuring – what happened to -simple- ?
----
If you ever want to consider how crazy DNS-capture is getting, realize that Firefox/&c are all dark-patterning the abilities to turn off "secure"-DNS. The latest Raspian/Pi-Hole defaults are terrifying... [2]
[2] another example: why doesn't v6 enable HTTPS localhost web-access, by default (like all previous versions?!)? Do the developers really expect us commoners to know how to generate localhost certificates – this is obviously behavior due to how the pihole useraccount behaves differently then the previously-root-blessed v5-behavior
----
Thankfully, I've kept a local copy of my favorite distro of Pihole v5, and it is readily-cloneable.
When I attempted to pass a --version tag during a freshinstall (requesting v5 from remote installer), it went ahead and installed latest v6 (so why even.?!).
> 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 guess I just don't understand why this makes such a big difference to you versus having Gatekeeper off? You're asking for a very specific flow, where you can run anything but only if you right click the app instead of double clicking the app.
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.
Or maybe lower the price to $1.
_Some_ barrier of entry I think is needed (and intended) to stop everyone and their mother from creating developer accounts.
I don’t think Apple needs or cares about the $99
> People will say, no, that’s too big a hammer, it’s not safe… but then, like, what do you actually want? Either you keep Gatekeeper because you like the friction it introduces, or you don’t like that friction and you should go turn it off. Pick one, you obviously can’t have both!
Refusing to let you open an app isn't friction, it's complete obstruction. How about warning you and letting you run it this one time or allow it to run normally from there on?
You can still open unsigned apps with Gatekeeper on, you have to go into Settings to whitelist it. I find this extremely annoying, but as I said, that's the point of Gatekeeper, if you don't like it then turn Gatekeeper off.
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.
> what do you actually want?
To make gatekeeper happy without paying a large amount of money and own Apple hardware (same thing).
I just wish Homebrew was not planning to remove packages because of this.
> $ brew doctor
> Warning: Some installed casks are deprecated or disabled. You should find replacements for the following casks:
> alacritty
> librecad
Is there workaround? Probably. But macos lost benefit of OS X's "it just works". Time to move elsewhere I guess.
Yeah, I think this is a terrible decision on Homebrew's part. Lots of people said that to the Homebrew maintainers and they refused to budge.
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.
Are there any groups of open-source developers who have gotten together to share a group account and the $100 cost per year? Forming an informal-ish organization, with just enough formality to be a legal organization in whatever jurisdiction they live in, so that they're legit enough to satisfy Apple's requirements? Not trying to hide anything, just trying to pool resources in an open and above-board way.
Or would Apple categorically reject an application like that?
I don't develop on Macs myself so I wouldn't know where to start looking, but I can't help but wonder if that would be a viable answer for many people who don't want to pay $100/year to give software away for free. Get twenty people together and $5/year doesn't feel like too much.
1 reply →
Isn't code signing even harder/more expensive on Windows?
13 replies →
> 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.
[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.
I have been developing software for Macs and PCs as an Indie for 20 years now. I sympathize with the author of the post. You get the feeling that Apple thinks you should be grateful that they allow you to develop apps for their platform.
The author didn't mention Apple's contempt for backward compatibility. Apple like to regularly nuke their entire developer system from orbit. Try running an app developed 10 years ago on the latest version of macOS. It probably won't run.
Microsoft are much better at backward compatibility and they don't force you to join a developer program. But you get totally reamed every time you have to update your authenticode digital certificate for Windows. Just the digital certificate will cost you more than $99 per year. It is a total racket.
> 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.
Maybe it’s worse for games, but I’ve been maintaining non-game apps on both iOS and Android for many years and keeping the iOS halves functional has generally been pretty chill. Updates aren’t required all that often and it’s rare that APIs break entirely on me, especially if targeting older SDKs. Usually the worst post-WWDC fallout is needing to recompile the app in question with minimal changes.
By comparison, Android is much worse. The Play Store kicks you off for not submitting updates much more quickly and the whole ecosystem is in a permanent state of simultaneous flux and obsolescence. Whatever deity help you if you let an Android project collect dust for a year or two… you’re gonna be fighting battles on multiple fronts getting everything up to date. Gradle conflicts, APIs getting deprecated without fully baked replacements, divergence in behavior between OS versions… it’s a real hoot.
2 replies →
> 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.)
I keep trying to explain this to people but it's hard enough to describe the issue, even harder to get people to care, and an impossible battle to change Apple. I don't actually think they're doing this to kill old apps. I think it's a very cynical and calculated plan to require developers to actively maintain their applications, *thereby requiring the use of subscriptions as the only viable business model for developers.* That is Apple's primary revenue stream by far, and they're making far more money now that we have to subscribe to workout apps instead of buying them once and using them for years.
5 replies →
well it also made macOS the nicer platform with modern, well maintained apps for the past 2 decades.
3 replies →
> iOS developers have to continuously update each game yearly simply to keep it working
This is usually not the case
Ios actually is far better than macos for old apps. I have a few ancient maybe 8-10 year old ios apps on my iphone that have not received updates and still work fine. Can’t say the same for macos because they decided to drop 32bit support.
Contempt. use any apple device 2 updates back or more. you're screwed.
You would accept this in no other place in life, except that apple gives it for free, and puts a 'security' sticker on the box.
It's a racket. Planned obsolescence 2.0 - Users forced to update, update removes features, breaks working apps, breaks paid for ip ( literally removed from phones), apple blames the devs. bullshit.
3 replies →
[dead]
It's much more expensive on Windows side of things. DigiCert and Sectigo are now in the $700--$1000 range per year for regular OV code signing certificate.
Microsoft has it's own Azure Artifact Signing which is comparable to Apple yearly cost (give or take), but since a month ago installers signed with it often display SmartScreen warnings [1]. Even though Microsoft controls both pieces!
Store option is not free for organizations (although it's a one-time setup fee), but the worse thing is it forces you to its simplified licensing/trial model, typically not compatible with B2B software where paid upgrades, yearly support contracts, controlled updates, extended trials are used.
[1] https://github.com/Azure/artifact-signing-action/issues/128#...
Would be interested to hear a bit more about selling commercial software through the MS App Store. My Easy Data Transform software has a free trial (7 days, do not have to be consecutive) and is a one-time fee of $99 to buy. How would that work?
2 replies →
fwiw you can ship through Microsoft Store for free and not have to pay for signing.
Last time I looked the MS Store was just a sad catalogue of shovelware. Has it improved?
5 replies →
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.
The alternative to this was continuing to optimize Rosetta while simultaneously processors improve, soon enough the performance gap wouldn't matter in the slightest. By the end of the decade you'd probably be comfortably running that software on a MacBook Neo w/ A20 Pro.
Rosetta and its underlying tech enable 10,000s of games and applications to run so it's a tremendous loss overall, it doesn't sound like much will be left if this means x86 OSX games:
> "we will keep a subset of Rosetta functionality aimed at supporting older unmaintained gaming titles, that rely on Intel-based frameworks"
https://developer.apple.com/documentation/apple-silicon/abou...
Mac used to have a lot of great shareware from indie devs. Some of them have shut down and their apps will eventually stop working. Kinda annoying when I can play the windows port of a game on windows but not the original Mac version
2 replies →
I shared the author's frustration when figuring out how to ship such binaries to end users so I wrote a guide [0] detailing exactly how to do it. Apple's documentation is surprisingly poor and I couldn't find any blog posts so I ended up reverse engineering what works via trial and error as well as popular OSS projects on GitHub.
[0]: https://ofek.dev/words/guides/2025-05-13-distributing-comman...
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...
Author here, just pushed a quick update to the article.
To be fair, compared to the prices of Certum and other providers if you ever want to sign something for Windows, perhaps Apple isn't uniquely overpriced (they all seem to be that way): https://www.certum.eu/en/code-signing-certificates/
Looking more into the Windows side of things, I also found Azure Artifact Signing which is supposedly affordable at 8.54 EUR per month, but unfortunately they don't actually support individual users in the EU (only in US & Canada, meanwhile EU only gets support for organizations). I'd probably have to set up a SIA (equivalent of Ltd.) here first - it was in the plans for later, but this is a bit of a roadblock for using Azure too: https://azure.microsoft.com/en-us/products/artifact-signing
My tone might have been frustrated, but I will absolutely say that the code signing industry needs to have a Let's Encrypt moment of some description - at least commoditize it like Azure Artifact Signing was trying to do, but also for individual developers, across all platforms! Sadly, that doesn't seem to be possible when the platforms are intentionally walled gardens. I don't hate the idea of code signing, though - if done right, it's a good idea, same as TLS for (many) websites.
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...
Microsoft say it's no longer true that EV certificates get special treatment:
https://learn.microsoft.com/en-us/windows/apps/package-and-d...
The only option to avoid a SmartScreen prompt from day 1 on Windows is to distribute through Microsoft Store, end of story.
If you sign it yourself, via Azure or your own $200/year cert, you will get a SmartScreen prompt initially, but the prompt will stop appearing once the file hash has sufficient download history. There is no exact threshold, but it can take several weeks and hundreds of clean installs from a wide audience.
This is from https://learn.microsoft.com/en-us/windows/apps/package-and-d...
I have an OV cert for Windows, which is expensive enough. I just make sure to do a snapshot release using the new certificate to existing customers (through my newsletter and forum) a while before using it for new customers. That way there is time for the scary warnings to go away before any new customers see them.
Digital certificates providers are basically checking your id (mostly automted) and multiplying 2 prime numbers together. Then charging you several hundred dollars. A 1 year Sectigo certificate EV with USB key is $431.99. Nice work if you can get it.
I wrote this back in 2008:
https://successfulsoftware.net/2008/02/27/the-great-digital-...
But it has got much worse since then.
I don't think this is true. A normal CS signing cert is sufficient for most commercial apps - you will get the SmartScreen warning for a few days but it will go away fairly quickly.
The important part is that SmartScreen reputation is URL-based, you need to make your initial download URL consistent. If you are constantly rewriting it (i.e. with a version #) it will break. It's ok if the original URL hits a 302 to the latest version.
Azure Artifact Signing and Apple's Developer program come out to similar costs. Apple's is probably still cheaper in that you can sign any number of things with it.
But yes, it would be nice to have some free signing options for open source developers.
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.
How does anyone who cares about open source or even development more generally see this and go "Yeah that's the OS I want to use"?
I genuinely don't understand why so many developers are willing to compromise so much for a thin laptop.
> 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).
> I am sadly now addicted to OLED and I fundamentally disagree with the Apple position of not having a touch screen on a laptop
Both of these are reportedly coming to the MBP this year (lately rumoured to be next year), although there's going to be a steep price to pay and rumours say it will still just have the MacBook's normal angular range so no good for drawing or iPad apps.
Apple is so far ahead of everyone it's sad but they're catching up and Apple is so unflinching on so many topics it handicaps them, we could be stuck with touchscreen Macs that aren't useful for iPad apps for many years, and later this decade ARM chips will start nipping at the heels of the Pro and Max chips while build/component quality is rapidly improving too.
The last thing I want is a touchscreen laptop. Wouldn’t that be great adding stupid cost solely for the ipad kids to not feel so alarmed. Nothing like reaching your hand up unsupported to poke at a screen right? Gotta love the fingerprint smudges too and the eventual loss of the concept of an information dense ui entirely as ui elements need to be clicked with the imprecision of your elbow now instead of the mouse.
It's not the thinness, it's the amazing battery life.
Framework Pro has that now
1 reply →
I use my Macbook for things other than dev work, and that's where Linux tends to fall flat. Weird hardware incompatibilities, jank, huge amounts of time required to maintain the machine rather than just getting work done.
Having to occasionally run xattr -d com.apple.quarantine to download some random low-userbase FOSS app is nothing compared to what Linux users go through.
You won't appear as hip and fashionable amongst your CA/SV peers lugging a "generic" laptop around.
This was perhaps the biggest reason I moved to Linux full-time about a year ago. I just got sick of not being able to write software and have people use it. The solution might be an "I trust this author" VS Code style dialog and that's it, but even that misses the mark a bit. I've been having a blast building on Linux and miss almost nothing about macOS. And the things I do miss I write programs for [1][2] and give them to people. Who would have guessed that would ever be so hard.
1. https://github.com/zackb/tether
2. https://github.com/zackb/hyprwat
Packaging software for Linux users is a nightmare. Unless
- your program is extraordinarily simple
- you can manage to statically link libc
- you can ship (or statically link) all .so files
- you can ensure your app can run in a sandbox
- you limit the distros you build for
- your app can be built by whatever is on flathub
etc., most solutions to shipping software simply don't work out-of-the-box. Despite the kernel being reasonably stable, userspace APIs are a mess of incompatible.
This is a great point, and you are right. However, using cpack+cmake makes the packaging pretty easy, gets the dependencies right for you. The problem is in dealing with all the package various manager repos.
macOS and Windows both used to allow running arbitrary binaries from a web page. Linux GUI users get away purely because it’s unpopular target for as scammers, once naive grandmas and 12-year olds start using it, I’m sure there will be comparable amount of hurdle to just give another person a binary.
So, Linux gets a free pass for requiring chmod +x to run his tool, but needing to run xattr on MacOS is somehow worthy of an entire blog post to complain about it?
Serious question - Is it really true that Windows 11 will run an untrusted .exe without a warning?
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.
But after enough people run it, that disappears. They implement crowdsourced trust, because it isn't a rent extraction exercise but actual concern about malware.
1 reply →
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.
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.
Why isn't the author getting that warning then? Is it because he's only testing the tool on the same machine that it was built on?
1 reply →
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.
Which is fine. If you don't know what that obscure xattri cli command is doing, you shouldn't be running it.
macOS makes it easy to run software which meets some requirements by Apple.
macOS makes it possible to run other software if you (the user) know what you're doing.
It wont.
Ugh. I just went through this ID verification process yesterday and I got it to work on /maybe/ the 8th try. Truly horrible design. Now I’m in a paperwork exchange with some random third party to get the account associated with my LLC. It would be awesome to be able to just write and distribute software, but there’s only one iOS monopoly so what are you going to do but play ball.
1 year ago i would have agreed with you. Today, I'm going to take the other side on this. The amount of malicious code embedded in software now is going up exponentially. Yes this is a painful tax imposed on all software, malicious or not, but until they figure out a better system, this system actually will disuade a certain percentage of malicious actors to give up - ESPECIALLY having to pay a fee. As a mac user, i want to know if the developer has paid a significant fee to get this software to me. It a useful signal for me. If they didn't pay and didn't upload their passport, I really want think think hard about the risks involved for myself when I run this thing.
There are many cases of signed & notarised software that pwned users.
Sure, but the more barriers there are the better because it still reduces the number of threats. That’s why people choose to rent walled gardens. Otherwise, Linux would have higher adoption even among our crowd.
If you really value freedom over everything else, I don’t see value in putting bad bandages over closed platforms. Might as well just switch to an open one.
3 replies →
Malicious actors can easily pay a fee - they're either running a business or they work for a state actor.
The $100 isn't the deterrent. It's the having to pay (+ use a new identity/entity) every time you have to sign up for a new Developer account because Apple revoked your cert when it caught you distributing malware.
My favorite is when someone discovers they haven't yet granted Zoom screensharing permission, and that they need to exit the call to re-launch the application with the permission granted.
As a user I actually like Gatekeeper. 95% of the time it's not a problem. the other 5% of the time I have to click a button in my settings to allow unsigned code. But at least it gives me pause to think about the source and if I really trust it (which is mostly offloaded to Apple the other 95% of the time).
Free business idea: get an Apple developer account and then agree to sign code for other people in exchange for a small piece of their income. I'm surprised that doesn't exist yet (or does it?).
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 can use SmartID to verify my ID (and age) in about 20 seconds when buying an energy drink at the local grocery store
Where do you have to show ID for that??
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.
I was also taken aback by this, but apparently it's a real trend.
https://en.wikipedia.org/wiki/Age_restrictions_on_energy_dri...
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
Under 16s can’t buy energy drinks in the UK
Edit: currently a voluntary but widespread scheme by retailers, proposed to be law. TIL
can they also not buy tea, coffee or coca cola then? oh no, they might drink the caffeination amount of... 2 cans of pepsi!
1 reply →
another feature of UK dystopia
You and I have very different ideas of dystopia.
4 replies →
Only if you look 12
I spent the better part of a week failing to create an Apple account using my studio domain - not even a dev account yet, just any account at all. In large part because of the "I got frozen out and can't talk to anyone" horror stories that pop up here monthly, and the fact that my personal account already needs to go through the "your account is locked" dance on a daily basis. My best guess is constant credential stuffing plus lack of any Apple mobile device.
The main creation flow wouldn't send a verification email, and there are hints around to try through Apple Music, which got me a little farther. At phone verification, I receive the code fine (on both numbers I tried), type it in, and get an inscrutable "error" that prevents finalization.
But it turns out it was final enough that even though I can't log in at all, they felt fine sending me Mother's Day email spam. Thanks. I'll be sure to FaceTime her.
Had an eerily similar experience trying to set up a fresh personal iCloud account for my Mom. Effectively, feels like she's permabanned based on the phone #. Exhausted all possibilities and gave up.
Tangential but this made me appreciate how Gatekeeper is perhaps a notorious example of a great naming choice for a piece of software.
Sometimes I wonder why we don't just treat an installation script like curl https://alx.sh | sh as a universal option for distributing applications. The provenance is there via the HTTPS certificate, and if you're already about to trust an application that can compromise your system, why not trust the installation script as well?
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.
> Domain names fundamentally don’t solve that problem.
App certification doesn't solve that problem either.
Because even with HTTPS that script might not do what you expect and then is too late, xz style attack.
You're already installing a binary, the script is not the weak link here.
1 reply →
It's interesting that sanctioned Russian banks still find the ways to push their apps into Apple repository by disguising them as a different app. They get removed several months later, but I assume it is done only because someone complains.
Funny how a $20 cert is enough to prove identity and provide security for any domain on the web, but in order to run a calculator Apple hw, Apple HQ is the only entity on the planet capable of such complex security.
It has been like this forever and periodically someone complains, but then they just go out and buy another mac and keep producing software for macOS. If you want this to change, stop providing financial support.
Apple's ID verification failed for me and I am now banned for life. There is no opportunity to appeal this or to ever participate in the Developer Program for me. Which sucks because I am now permanently locked out of developing seriously for any of the Apple ecosystem, ever.
If I am understanding this correctly, the $99/year Apple Developer Program allows you to notarize applications for macOS so users do not receive the warning/damaged binary dialog. I simply had AI generate the signing code, and you can run that script on any CICD or on your machine and push the artifacts to a CDN. Works wonderfully for macOS, and users of my app have had no issues with it.
Let me know by replying here if you want me to share the build+sign code or have any questions.
I'm totally interested in hearing more about this, please share more details about how you get this working.
This is exactly the sort of paternalism which drove me away from the Mac in ~2015, after I'd been using Apple hardware for thirty years. It's just too much hassle for a casual developer; I'm stuck on the belief that it is my computer, not Apple's, and I should be the one deciding what I can do with it.
On a meta note, no one uses link pages like https://links.kronis.dev/NAnEME3Kqt any more. There are better ways of tracking clicks without obfuscating the destination page from the user.
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.
Never upload your ID. If that means not developing for a platform, don't develop for that platform.
While I do agree with an overall sentiment, you can't seriously think this is a viable solution for most developers, surely.
Plenty have dropped mac support even major devs that used to support it well. Paradox interactive no longer develops for mac. Valve also no longer develops for mac.
Try to open the file, say ok to the ‘can’t check for malware’ prompt, go to settings, security, approve running the software.
Annoying, but if you’re delivering your app to semi-technical users, not really a problem.
It's only a problem if you want people to use your software
it's really cool when i can fall a sleep in peace knowing this keeps my folks from getting rooted
1 reply →
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 went through this recently. Got as far as verifying my identity, which Apple happily accepted as verified from my UK driving license. Unfortunately, they then automatically set my first and last name from that identity verification step, and some how managed to use a section of my driving license number as my surname - a string of random uppercase letters and numbers - and it's impossible to edit it. So fuck them, that's $99 they've lost.
I don't get the part about Homebrew. If you're using Homebrew, it doesn't make a ton of sense to use Itch.io. Just use Homebrew. Seems like a more appropriate place to distribute a dev tool anyway. You could set up a patreon and print a link to it when appropriate. That's basically what Vim does.
I agree that Apple is dumb of course.
They want to have a way for users to pay them. Itch.io has that, homebrew doesn't.
Okay, but then the argument that Apple is charging them to certify their software and that is excluding hobbyists falls away doesn’t it? Now you’re not a hobbyist.
2 replies →
There is no reason to tie the method of payment together with the method of distribution. They could distribute it through brew along with an optional license configuration. Downloading a cli from a browser is not convenient anyway. You need to copy the downloaded file somewhere that is loaded into the PATH.
And also, software that is downloaded from itch.io app does not require notarization.
You could set up a patreon and print a link to it when appropriate. That's basically what Vim does.
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
Apple's not making any money on developer subscriptions. I suspect they just want to have a velvet rope, to encourage folks to be serious about their work. They don't want farting-around toys. They want developers to ship serious apps.
There'$ a rea$on that $o many people want to relea$e Apple app$. A $uperb rea$on.
It's a really lucrative market. People like to have access to customers that are used to paying a lot. One of the reasons those customers want to pay more, is that walled garden that HN members hate so much, but millions of people have no issue with (whether or not that's a good thing, is not for me to ponder. It just is).
99 bucks is peanuts. It does give you access to the entire suite of Apple tools. Anyone interested in shipping serious software, is likely to far exceed that, in the non-Apple (or Apple hardware) tools that they use to develop the software. Heck, your keyboard probably cost more than that. I remember that we used to pay Microsoft over $4,000 a year for their developer program.
Here's what Apple says about it[0]. That's what I usually do. I think someone else has shared the command line method. If it's a developer tool, then it would probably have a difficult time passing Apple's app review process, anyway, and that will really jangle your cortisol pipes.
[0] https://support.apple.com/guide/mac-help/open-a-mac-app-from...
> 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.
> I think that's a false dichotomy
If I had been positing it as a developer issue, then that would be true.
However, I was talking about the customer experience, not the developer one. There's no question at all. People pay a premium, and have no issues with the walled garden.
Just because I don't like something, doesn't mean that everyone else shouldn't like it, either. I may not be wrong in my rancor, and they might not be wrong in their acceptance.
One thing that customers are disliking, though, is the buggy and overcomplicated mess that Apple operating systems have become. I am hoping that they do another across-the-board "Snow Leopard" release. From what I hear, that's likely. It might end up making the developer experience a bit more frustrating, though, as they may be demanding more from us.
I've been shipping Apple-based software since 1986, and have found myself screaming with rage at them, many times, in those 40 years; but I never stopped developing for the platform. I guess I'm a walking exemplar of The Stockholm Syndrome.
2 replies →
> 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.
That's entirely against Apple's whole philosophy. You are after all, holding it wrong.
I am not entirely against the whole notarization thing.
If it is good for the end-user, it is usually also good for the ecosystem a a whole, trust is valuable.
But ffs, they are rich enough to make this a lot less painful and hostile for developers.
And this is not a new thing, I used to develop games for iOS, from the very beginning, and while the process somewhat simplified over time, it was a huge cortisol inducing process, not to mention the regular forced OS+SDK updates where the procedures changes almost every time and could fail in not-so-evident ways.
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.
The cash part is not even the worst, even if this is obviously ridiculous for free/open source projects.
The bad UX is really what irks me. Enough that I may entirely opt-out of the Apple ecosystem forever, and I don't think I am the only one feeling that way.
1 reply →
distributing for macOS is extremely hostile and Apple continues to extort developers through fees, yearly subscriptions, and of course taking 20-30% in transaction sales.
This made me think of a potential workaround that would have a better UI: create a directory (maybe named 'Trust Zone'), and have it watched by something like automator. As soon as you move a file in there, it reacts and remove the quarantine bit on that file.
The enrollment app on Mac OS feels like a second citizen. I think Apple is slowly giving up on ensuring the experience on its own Mac apps is working as well as on iOS. I hope to be corrected now that the Macbook Neo is more popular, but I won't be holding my breath.
All that, and not a single one here is surprised at zero days or trojans or malware that come right out of this process every week.
If it works, then why aren't we surprise when it doesn't?
Because we know it doesn't work.
It seems like running with sandbox-exec should remove pretty much all the potential for an app to cause harm… is there a reason why it’s not the default, especially for these certificate-less apps?
I believe that at least app-store apps are already ran in some sort of sandbox.
Maybe I'm too dumb, but I haven't figured out a good way to sign just a binary (or a tar/zip containing a few binaries). I zipped up the binaries, sent them off to Apple, Apple comes back and says "yup, notarized!", and they still trigger the popup. I'm probably missing a step. I guess I'm not currently stapling the ticket to the binary, but supposedly you don't have to if you are running with a network connection.
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.
Yup I do the first two - https://github.com/zig-for/snfm/blob/main/.github/workflows/...
The documentation implies the last step is optional https://developer.apple.com/documentation/security/customizi... but it might be inaccurate
> I guess I'm not currently stapling the ticket to the binary, but supposedly you don't have to if you are running with a network connection.
AFAIK, you do in fact have to staple the ticket. The other thing I found is that you have to make sure you're using the right kind of certificate from Apple.
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
This was with payment to Apple
> I'm sure that other countries also have plenty of similar services for ID and age verification
laughs in Bundesdruckerei
desktop & mobile software is run by a cartel.
they can charge you $99/yr cz they know you ain't got choices.
which is why web software is a blessing. web software runs without permissions from the gatekeeper.
Yes, but doesn't run locally.
That’s nothing, Google charges $900-2600 / year if you want to write an app that calls the google apis for user data
it’s as if apple forgets that some of it’s user base are people who scrap together money over long periods of time just to have a chance at affording a mac only to be told they need $99 to distribute an app. your entire user base isn’t 100% affluent people and apple doesn’t seem to grasp this
Pains me to say this but as a developer, microsoft is a whole order of magnitude better than apple
Is there no open source collective one can join which will share signing keys and handle signing?
https://signpath.org/ is about as close as you can get.
That's actually awesome. I'm working on a project right now that could use this!
I love when my Mac declares random PDFs malware and deletes them when I try to open them.
On two occasions I've been completely dumbstruck when the software I was using was deleted out from under me. I'm not a fan of the overuse of "gaslight", but it sure felt like that when I had to restart Docker and the OS was like "what do you mean, Docker? You've never had Docker installed! What are you talking about? Are you feeling ok?"
https://news.ycombinator.com/item?id=42649790
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.
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.
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.
I'm really trying to remember the context, I wish I'd written it down somewhere. But now that I'm thinking of it, I'm almost certain it wasn't PDFs, but JSON files that I'd written. For some reason it would allow me to open them in some applications, but in others I'd get a warning and the file would be trashed.
The Docker thing happened as described in my linked post. It happened with something else too, but again I can't remember. I wasn't planning on doing a post mortem so I guess I let the details slip!
In any case, I do like most of the OS' ways of doing things, including security. But it can be overzealous.
P.S. I'm not crazy! I'm not crazy!!!
Bro i feel you so much! i am developing an app aimed at Intel Macs, but i cannot even publish it, because you need a Silicon mac to use the Apple Developer Program. It's so unbelievable brainless. The market still holds 10-20% intel devices, especially outside the US and in some high-end environments, where 128GB RAM machines cannot easily be replaced with a silicon mac.
Sometimes it feels like Apple has no clue how their users actually work and what the industry needs.
I just went through this with a small paid macOS menu bar app. The hardest part was not the code, it was figuring out which app store rules I had accidentally stepped on- app name wording, accessibility permission assumptions, and even cmd+q behavior.
The review did eventually pass, but the process felt much more fragile than shipping the product itself and i had to remove one key feature of the app as well for the review to pass.
Due to the delays in ID verification the author of the article didn't even get to the point of the super annoying 'notarization' process where you can't just sign with your key anymore (as you could a few versions ago) but you also have to upload a copy of everything to Apple and 'staple' their ok to it.
At least I don't think they got to it, they only mention signing but not notarization.
Siri has the same effect.
So don’t target mac
Honestly painful to read. I tried to distribute a free utility to some friends last year and bailed somewhere mid-enrollment. Just wanted maybe ten people to download a thing. The whole flow felt designed for someone shipping to millions and I just couldn't justify it for what I was actually doing.
Hope this finds its audience on Itch.
Cortisol spit curve tests are pretty cheap, so I was disappointed to see the title claim not substantiated with real data. Consider biometric testing next time you distribute!
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.
checkout fastlane.tools, you can automate signing/distribution
It's a backwards walled garden which I mostly avoid to avoid problems like this
Looks like a skill issue.
Honestly, for most open-source apps where you don't want to Deal with this, the answer is to just get it into Homebrew. They handle re-signing apps using the local computer's ad-hoc signature and for most apps this is by-far the easiest way to deal with Stupid Apple Bullshit.
[flagged]
[dead]
[dead]
[dead]
Notarize the application and staple the receipt to your app bundle. It won’t trigger the Gatekeeper warning.
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.
Sorry, it was meant to be a reply to a comment.