> but you pay for the distribution / tools / OS etc is a common sentiment I see here. No, the yearly fee should pay for that, and the user for the OS. And anyways, what if I don't want to, why cant I distribute it myself?
And if you choose to distribute your apps yourself? Apple still requires you to pay the $100 a year Apple tax, otherwise macOS will treat your app as if it is radioactive[1], leaving users to think that your app is either broken or malicious.
Apple has gone one step further, and now macOS on ARM Macs requires signed binaries, and it will not run unsigned ones[1][2].
> Apple has gone one step further, and now macOS on ARM Macs requires signed binaries, and it will not run unsigned ones.
Apple Silicon Macs will not run unsigned binaries, but the binaries can have any signature, so you can just generate one yourself and add it. There's no need for a developer account, or any other external party. And there are no issues with legacy support either, because ARM Mac binaries didn't exist until now (and the requirement does not apply to Intel apps being run via Rosetta).
This really isn't a big deal.
I was initially worried that mandatory code signing would prevent me from hex editing binaries (which is a thing I do sometimes), but I recently learned that codesign can replace a binary's existing signature. So even that shouldn't be a problem.
> They will not run unsigned binaries, but the binaries can have any signature, so you can just generate one yourself and add it. No need for a developer account, or any other external server or party. And there's no issues with legacy support because ARM Mac binaries didn't exist before now (and the requirement does not apply to Intel apps being run via Rosetta).
Self-signed applications are treated as if they're radioactive by macOS, too.
> This really isn't a big deal.
They've been turning the screws slowly over the last two years. It only takes another turn for them to switch off support for self-signed apps for security reasons. Browsers already do this for self-signed certificates.
It's just not something I'm willing to base my purchasing decisions on, nor the decisions about what desktop platforms I target with my applications.
> Self-signed applications are treated as if they're radioactive by macOS, too.
But not if you turn off Gatekeeper! I can understand how this is annoying if you're creating apps for other people, but in terms of my own personal experience with my computer, the only time I think about Gatekeeper is when I'm talking about it on HN. It gets turned off as part of a bash script I run after installing macOS, at which point it's gone for good.
On my list of annoyances with macOS, Gatekeeper is somewhere below the Library folder being hidden by default. I can't say what Apple will decide to do in the future, but I have a very clear line in the sand, and Apple has absolutely not crossed it.
Gatekeeper-by-default is sensible IMO. I've seen how some people interact with these devices, and how easily malware gets on a computer.
As long as the walled garden can be easily circumvented, advanced users can do what they wish. "Able to learn about Gatekeeper and decide if they should turn it off" is probably an okay heuristic for "can tell a fake Flash installer site apart from a real one" or even "knows that Flash is pretty much abandoned, do everything you can to avoid it".
That said, it absolutely changes the incentive structures, and Apple is also doing it for profit. Will they cross the line in the future, with this goal? I expect they will conclude losing the advanced users would be a net loss.
> As long as the walled garden can be easily circumvented, advanced users can do what they wish. "Able to learn about Gatekeeper and decide if they should turn it off" is probably an okay heuristic for "can tell a fake Flash installer site apart from a real one" or even "knows that Flash is pretty much abandoned, do everything you can to avoid it".
That's exactly how I see it! And this mentality continues throughout the chain, too—if you want to actually install unsigned kernel extensions, or inject code into other processes, you need to boot into recovery mode to disable SIP. This is still not at all onerous if you know what you're doing (and, like Gatekeeper, you only need to do it once), but it's definitely a next-level test for next-level privileges.
IMO, the way Apple designed this process is brilliant! And that's why I'm not personally concerned by the boiling water argument, at least not yet—whatever Apple's incentives, the current setup strikes me as the best way to handle things.
All of that said, where I am starting to get annoyed is with the root snapshot stuff in Big Sur. Having to reboot every time I want to edit a system file is a clear progression from "trivial speed bump" into "consistent pain-in-the-ass" territory. If you want to talk about Apple locking down the Mac, I'd start there!
Can't you still go through the song and dance of disabling SIP and authenticated root and then editing the root snapshot? It's incredibly annoying but should still work, right?
Generally things don’t like it very much when I lie to them about what OS they’re running on; I try to set the version just before opening Xcode and fix it then right after I’m done submitting the app so my computer isn’t confused. More than once that has been long enough for Software Update to get confused and offer me a new build :P
The problem is that it makes it clear that the market for third-party software is completely at Apple's pleasure.
If Apple chooses not to issue me a Developer ID, they have effectively removed 95%+ of my market.
If this is because I distributed malware, that's reasonable. But there are a lot of other reasons why Apple might choose to revoke a Developer ID. (Think pressure from the state, for one.)
I also feel like in the spirit of the OP: it’s like telling customers that they can drive without a seatbelt and it will save them time getting in/out of the car.
Most will look at you like you’ve got three heads, and (I suspect) the majority will simply walk away without purchasing.
Your just assuming it’s a pot and want to persuade me to jump into the freezing river instead. But Apple may have no intention to completely lock down the Mac. It may well be just a hot tub, and right now it’s quite comfortable. If it gets too hot, I’ll just get out.
I understand the analogy. You are asserting that it's a pot, but that's just an opinion. Anyway the analogy just doesn't work. Why can't I get out of the Apple ecosystem if it gets too hot, what's stopping me?
"The boiling frog is a fable describing a frog being slowly boiled alive.
The premise is that if a frog is put suddenly into boiling water, it will jump out, but if the frog is put in tepid water which is then brought to a boil slowly, it will not perceive the danger and will be cooked to death.
The story is often used as a metaphor for the inability or unwillingness of people to react to or be aware of sinister threats that arise gradually rather than suddenly."
In the case of Apple, at some point when they do something you really dislike you might be too invested into the ecosystem and it will be easier to just accept it instead of leaving.
But if you were not on their ecosystem already and were thinking of switching to Apple you would just think "Yeah, I really dislike that new move, I'm not buying into it".
I believe to get the behavior you need a brainless frog - they are shockingly functional due to how much behavior is in bodily reflexes. In that context the brainless frog sort of fits as a metaphor of "cargo culted" or tradition fixed behavior or single strategy. An approach well adapted enough to the expected environment that no thinking is required but is doomed as soon as it has to deal with change.
sorry to be pedantic, but if you believe wikipedia, it is true (just you probably cant reproduce it on your kitchen stove)
--
The New Psychology (1897): "a live frog can actually be boiled without a movement if the water is heated slowly enough; in one experiment the temperature was raised at a rate of 0.002°C per second, and the frog was found dead at the end of 2½ hours without having moved."
> But Apple may have no intention to completely lock down the Mac.
They've been very gradually locking it down for years and show no signs of stopping. Plus they have an obvious financial motivation to lock it down. To give them the benefit of the doubt here is naive to say the least.
There isn't really any - it's just a smaller change than banning unsigned apps completely. Their strategy for forcing people to use the app store is to very gradually make it more and more inconvenient not to. This is one of those gradual changes.
Imagine the next ones:
1. You have to enable an option in settings to allow running self-signed apps.
2. You have to disable SIP to allow running self-signed apps.
3. Apps can only be self-signed via Apple's website.
The second link seems like a massive problem for developers - but the tweet in that link has been deleted. What's actually happening?
If that were true, I couldn't just write some C, Rust, or Go code on my mac, compile it myself, and run the executable file because it's not signed?
There's got to be a way (developer mode?) to disable this, right?
Edit: Found some more info - only binaries that are compiled to run natively on ARM are affected (for now). Still seems like this will introduce some major inconvenience for developers/power-users.
But at some point you'll _only_ be able to run ARM binaries. Rosetta2 will go away. Like how Rosetta went away for non-ARM Mac's, and now they can only run x86 binaries.
I seriously can't overstate how easy it is to sign a binary. You don't need an Apple Developer account, or an internet connection, or anything other than macOS and a working development environment. Just go into the Terminal and type:
> codesign -f -s - [path to binary]
Unless something has changed on Apple Silicon, that's it, you're done, the binary has a signature. It does not have a trusted signature, but you don't need one. I think it was just simpler to write the OS assuming all executables would have a signature.
Do you know whether this applies to everything which executes? If my build scripts create a build script and run it I guess that will be ok, but if my build scripts build a specialised parser (say, from C source) I need to add a step after linking to code sign the generated parser binary before using it? Is that about right?
Have they announced that it’s temporary or is this an assumption? Obviously it goes away eventually, but going away in year 3 of a transition is a different beast than going away in year 10.
My personal thought - there's a hell of a lot more software written for x86 Mac than there ever was for PowerPC Macs. It would make sense to provide the transational layer for a longer amount of time.
That said, Apple has never been shy about aggressive transitions.
Yeah I have the same thought. On the other hand, SaaS and Electron were not really things back then. It's possible that if enough heavy workloads go into the cloud and basic ones just turn into wrapped web apps the actual underlying instruction set becomes irrelevant much faster.
The first link is very interesting. The author talks about the alert in terms of a dark pattern, but the notification directly lies to the user stating "cannot be opened." In fact, the app can be opened by simply command-clicking and selecting open. However Apple lies to users in an effort to prevent them from using these applications. Sounds like a possible tortuous interference claim, or possibly fraud. Surely this "warning" serves to prevent users from using apps where Apple doesn't get a cut, and cases them to use apps that Apple does profit from.
Seems like only binaries compiles to run natively on ARM will require signatures. Still seems like its going to introduce some inconvenience for developers/power-users.
Don't self-signed apps expire after a week? You'd need to distribute a new build every week for people to continue to use your app. That's not a major hassle if you're just using your own code, but if you want to distribute something to other people it quickly becomes very problematic.
I agree - for commercial development its a trivial step. But it's yet another barrier to entry for students and people that just want to hack on their own computer at will.
It's also a potentially dangerous first step towards forcing new versions of MacOS to only run code from verified developers - those that pay Apple. Again, trivial for commericial development, but a major issue for non-commercial use.
And if you choose to distribute your apps yourself? Apple still requires you to pay the $100 a year Apple tax, otherwise macOS will treat your app as if it is radioactive[1], leaving users to think that your app is either broken or malicious.
Apple has gone one step further, and now macOS on ARM Macs requires signed binaries, and it will not run unsigned ones[1][2].
[1] https://lapcatsoftware.com/articles/unsigned.html
[2] https://news.ycombinator.com/item?id=25134352