I hope they will at least prompt the user to let them know what’s going on. I’ve run into this before on macOS, where an app wouldn’t launch, and on a hunch I went into the security settings and saw a section there were it was blocked and I could allow it. There was not even a hint of this in the error message when trying to launch the app. It was a very poor experience.
I’ll also be curious if placing the app in ~/Applications avoids the restriction. This has long been my way to get around some of the restrictions at work. /Applications requires admin rights, ~/Applications does not. Apps still show up in LaunchPad and work as normal (as far as I’ve seen), they are just only available to the user, instead of all users, which is fine for my situation. I used to have to request admin rights every time VS Code wanted to update on my work laptop, but since I put it in my user folder instead, it’s been smooth sailing.
Yes, make macOS more and more like iPadOS so their users can do less and less other than buying apps from the app store and scrolling through the slop on Safari.
Apple kinda reminds me of Intel in the 2010's ( not 1-1 comparison ), hollowed and rotting inside but in a constant party because $$ coming in and line going up..
They wrongly think because they control the dials when things start to go south they can just step on the gas and change course, it's a fools illusion because the people who actually can make a difference will not be there and the whole organization already is tuned for the wrong incentives, so when Tim Apple's minions step of the gas... nothing will happen other than pumping out more "beautiful, amazing, thinner" but useless slop.
> Yes, make macOS more and more like iPadOS so their users can do less and less other than buying apps from the app store and scrolling through the slop on Safari.
This doesn't seem at all a fair characterization of what happened here - you can still run these applications, they just added a (seemingly pretty reasonable) step to do so. I don't see this as allowing users to do less, and I struggle to find a strong argument against this when the typical user is not a l33t hacker type and most typical users find it extremely easy to download and run malware.
> you can still run these applications, they just added a (seemingly pretty reasonable) step to do so.
Every version of macOS makes it harder and harder to run unsigned code. They keep pushing the bypass deeper and making it less convenient. It’s super super annoying and stupid.
Protecting users against malware should be the job of XProtect. If a naive user can run malware via right-clicking, they can do it nearly as easily through the Privacy & Security page. All this change does is bring unsigned software closer to outright deprecation, at which point Apple can backdoor app review through notarization just like they do on iOS in the EU.
You don't need to distribute via the app store for your app to be notarized, you just need to have an apple developer account ($99/year) and go through the notarization flow, which is automated and typically takes less than a minute.
You're free to distribute (and sell) your notarized app however you want.
~$100/year is not nothing outside the first world. Esp when you need to balance it with other subscription costs. The hardware is owned by other people. Why should one have to pay Apple for running a binary outside their premises ? Its just plain tyranny.
It also adds a new permission prompt for screenshot and screen recording apps that doesn’t allow a user to permanently grant permission, but requires a weekly re-authorization.
I hate the periodic location permission prompts on iOS. Big tech companies are increasingly paternalistic with this stuff, like their users are all idiots who need to be managed like little children. Some other examples I've recently encountered:
- 1Password requires supplying a password hint when changing the master password.
- Unifi OS enforcing password quality requirements even when locally/self hosted.
- "Set up later" (instead of "No") as the negative option for various "helpful" feature prompts in iOS.
It’s worth keeping in mind that in the case of Apple platforms, a lot of this has roots in the revelation a decade and change ago that third party software on mobile platforms can and will exploit every affordance the operating system offers to extract data, often silently. It’s no different on desktop OSes, but users have been more acclimated to it there since full blown access to everything has been the norm there longer than it hasn’t.
That said I can certainly see the argument that Apple isn’t going about handling this set of problems correctly, but ignoring it or pretending it doesn’t exist isn’t right either.
>like their users are all idiots who need to be managed like little children
Most are.
But the OSes could be designed way better for this stuff too.
Give the user security but also total visibility. A central place to grant/revoke app permissions, and to check what all apps ask for, click to see their "privacy policy" or lack thereof, has an easy way to filter to see e.g. "which apps use the camera, when they last used it", etc.
When some app is blocked and you wonder why it doesn't work, it should be easy to see a list of "blocked apps" and sort them by "when they were blocked" and other such things.
I've spend literally days attempting to get a Python-based GUI application "signed", using every available packaging option and dozens of different approaches recommended by a multitude of different sources.
Absolute failure -- and no usable error messages indicating what might be wrong. Just basically "no, you can't upload that.".
I think that's the biggest issue with code signing, Xcode should come with a "Sign and Notarize.app" that allows you to sign anything you point it at with a single click.
Admittedly, I've done 99% of my development to target Linux, and just happen to use a Mac for its simpler and less time-consuming day-to-day GUI management.
This is the first time I've tried to develop something to target a macOS installation -- and it was a train-wreck.
This will mostly affect advanced users. Hopefully, my next update will be Asahi, once its hardware support (especially HDMI output) has advanced enough.
I tried Asahi on my older M1 macbook and the battery life is still very bad. I am pretty experienced trying to dive into CPU schedulers and kernel settings, etc. to try and fix it, but I was unable to squeeze more than about 3 hours of battery out of the laptop WHILE CLOSED! In contrast just booting up mac os the battery lasts about 36 hours+ while closed.
When did you try it? There were some big improvements recently:
> Putting EAS and utilisation clamping together, we took a 15" M2 MacBook Air from about 6 hours of useable battery life just sitting at the desktop to about 8-10 hours of 1080p30 YouTube, 12-15 hours of desktop use, and an enormous 25-28 hours of screen-off idle time. We still have many more tricks up our sleeves to eke out more battery life, and a deep dive on EAS utilisation clamping is in the works. Watch this space!
I bought a used M1 Max MBP recently, in part because the Asahi features table is starting to look pretty good.
But with the remaining outstanding hardware issues and the battery life gap in mind, I will probably get an overall better experience sooner if I just pony up for the upcoming Snapdragon X Elite laptop from Tuxedo Computers¹. :-\
On the other hand, the whole Linux desktop stack has benefited from work that Asahi devs have done, so I think that project is still undeniably valuable even for users on other aarch64 hardware.
Apple seems to like to coerce their users onto their preferred track little by little, release after release, instead of hamfistedly forcing it on day one. Instead, each release is a small drip of inconvenience and nudging.
Long time ago, you could run any executable you wanted. Then, you got a little nag, but whatever. Then (I think) you had to right click and take an extra step to run them, with a scary warning. Then, you got an even scarier warning and had to navigate into Settings to select "Allow applications downloaded from" -> Anywhere. Then, they removed the "Anywhere" option, but you could re-enable it with the command line.
It's also directionally clear: They surely intend to fully boil the frog one day and remove the ability to do this.
Se also: The UX you have to navigate in order to fill your own password into web pages on Safari.
> In macOS Sequoia, users will no longer be able to Control-click to override Gatekeeper when opening software that isn’t signed correctly or notarized.
Will Right Click > Open still work? That is how I currently bypass this issue with unsigned applications.
As well as `sudo spctl --master-disable`, except it now gets reset sometimes because you know, computers are so unreliable, they forget things all the time.
I've had some apps refuse to run until I acknowledged their signer in the Security & Privacy section of System Preferences even though the quarantine bit was not set, unfortunately.
Sorry Apple, but I have no intention to pay 100€ per year for the privilege to notarise an application I have up for free on a GitHub repo no matter how shitty you make the process.
At the moment I'm just linking to https://disable-gatekeeper.github.io/ and hoping that if anyone ever comes across my repo, that they know how to read and won't bother me about it. Maybe in the future the optimal solution would be to just not provide any pre-built binaries.
Yeah, this is exactly the problem. Apple doesn't want hobbyist programmers either on iOS or MacOS. They see inconveniencing open source programmers who aren't selling a product (and therefore not going to pay Apple for the right of being an "official developer") as a good thing.
The usual arguments I hear for this is grandma or kid following these specific instructions and installing a malware. But how many attacks make use of these?
It's a cancer in the sense that it is a growing and spreading idea in Apple's ecosystem, and is strangling the usability of its products. It doesn't really resemble a genocide metaphorically.
I hope they will at least prompt the user to let them know what’s going on. I’ve run into this before on macOS, where an app wouldn’t launch, and on a hunch I went into the security settings and saw a section there were it was blocked and I could allow it. There was not even a hint of this in the error message when trying to launch the app. It was a very poor experience.
I’ll also be curious if placing the app in ~/Applications avoids the restriction. This has long been my way to get around some of the restrictions at work. /Applications requires admin rights, ~/Applications does not. Apps still show up in LaunchPad and work as normal (as far as I’ve seen), they are just only available to the user, instead of all users, which is fine for my situation. I used to have to request admin rights every time VS Code wanted to update on my work laptop, but since I put it in my user folder instead, it’s been smooth sailing.
> I hope they will at least prompt the user to let them know what’s going on.
They don't.
> I’ll also be curious if placing the app in ~/Applications avoids the restriction.
It doesn't.
Yes, make macOS more and more like iPadOS so their users can do less and less other than buying apps from the app store and scrolling through the slop on Safari.
Apple kinda reminds me of Intel in the 2010's ( not 1-1 comparison ), hollowed and rotting inside but in a constant party because $$ coming in and line going up..
They wrongly think because they control the dials when things start to go south they can just step on the gas and change course, it's a fools illusion because the people who actually can make a difference will not be there and the whole organization already is tuned for the wrong incentives, so when Tim Apple's minions step of the gas... nothing will happen other than pumping out more "beautiful, amazing, thinner" but useless slop.
> Yes, make macOS more and more like iPadOS so their users can do less and less other than buying apps from the app store and scrolling through the slop on Safari.
This doesn't seem at all a fair characterization of what happened here - you can still run these applications, they just added a (seemingly pretty reasonable) step to do so. I don't see this as allowing users to do less, and I struggle to find a strong argument against this when the typical user is not a l33t hacker type and most typical users find it extremely easy to download and run malware.
> you can still run these applications, they just added a (seemingly pretty reasonable) step to do so.
Every version of macOS makes it harder and harder to run unsigned code. They keep pushing the bypass deeper and making it less convenient. It’s super super annoying and stupid.
Protecting users against malware should be the job of XProtect. If a naive user can run malware via right-clicking, they can do it nearly as easily through the Privacy & Security page. All this change does is bring unsigned software closer to outright deprecation, at which point Apple can backdoor app review through notarization just like they do on iOS in the EU.
3 replies →
You don't need to distribute via the app store for your app to be notarized, you just need to have an apple developer account ($99/year) and go through the notarization flow, which is automated and typically takes less than a minute.
You're free to distribute (and sell) your notarized app however you want.
> You're free to distribute (and sell) your notarized app however you want.
Provided you’re continuing paying every year.
1 reply →
~$100/year is not nothing outside the first world. Esp when you need to balance it with other subscription costs. The hardware is owned by other people. Why should one have to pay Apple for running a binary outside their premises ? Its just plain tyranny.
> automated and typically takes less than a minute
I have no problem with the fee, but getting that frickin signing process just right took me days to get working right the first time.
I wonder if they will foresee a “free” tier of the developer program so open source maintainers can consider this as even remotely viable?
There is also the quetion of privacy, for FOSS creators who are not a company, to have their real name shipped with the binary.
Or is all of this theatrics to try and resuscitate the probably-dead Mac App Store?
This already exists. Mozilla is on the free tier. I would like to see a non-profit organization step up to do this for other projects.
2 replies →
It also adds a new permission prompt for screenshot and screen recording apps that doesn’t allow a user to permanently grant permission, but requires a weekly re-authorization.
https://9to5mac.com/2024/08/06/macos-sequoia-screen-recordin...
I hate the periodic location permission prompts on iOS. Big tech companies are increasingly paternalistic with this stuff, like their users are all idiots who need to be managed like little children. Some other examples I've recently encountered:
It’s worth keeping in mind that in the case of Apple platforms, a lot of this has roots in the revelation a decade and change ago that third party software on mobile platforms can and will exploit every affordance the operating system offers to extract data, often silently. It’s no different on desktop OSes, but users have been more acclimated to it there since full blown access to everything has been the norm there longer than it hasn’t.
That said I can certainly see the argument that Apple isn’t going about handling this set of problems correctly, but ignoring it or pretending it doesn’t exist isn’t right either.
3 replies →
>like their users are all idiots who need to be managed like little children
Most are.
But the OSes could be designed way better for this stuff too.
Give the user security but also total visibility. A central place to grant/revoke app permissions, and to check what all apps ask for, click to see their "privacy policy" or lack thereof, has an easy way to filter to see e.g. "which apps use the camera, when they last used it", etc.
When some app is blocked and you wonder why it doesn't work, it should be easy to see a list of "blocked apps" and sort them by "when they were blocked" and other such things.
> "Set up later" (instead of "No") as the negative option for various "helpful" feature prompts in iOS.
I'm OK with this. When the prompt appears, you're very much trying to do something else, and ya don't need the detour. "Bug me l8r plz."
2 replies →
They have a similar prompt for accessibility (I believe) API in the beta, and it completely breaks Chrome Remote Desktop.
Apple needs more antitrust scrutiny if for no other reason than to make them reconsider the direction they're headed on third party software.
Apple are not a monopoly. Not the way Google is and Microsoft was.
The multinational antitrust scrutiny is purely coincidental.
2 replies →
This is not good.
I've spend literally days attempting to get a Python-based GUI application "signed", using every available packaging option and dozens of different approaches recommended by a multitude of different sources.
Absolute failure -- and no usable error messages indicating what might be wrong. Just basically "no, you can't upload that.".
This does not bode well...
Sounds like it's working as Apple has intended.
I think that's the biggest issue with code signing, Xcode should come with a "Sign and Notarize.app" that allows you to sign anything you point it at with a single click.
> This does not bode well...
What, in the past 10 years of MacOS development trends, suggested to you that anything was headed in the remote direction of "boding well"?
Admittedly, I've done 99% of my development to target Linux, and just happen to use a Mac for its simpler and less time-consuming day-to-day GUI management.
This is the first time I've tried to develop something to target a macOS installation -- and it was a train-wreck.
Edit: referencing this article: https://9to5mac.com/2024/08/06/macos-sequoia-screen-recordin...
This is going to make running a DisplayLink (not DisplayPort) display very onerous if not impossible.
I guess I only get to use 2 external screens if I'm forced to upgrade my work mac.
I presume this annoyance is just something you will go through when running the app the first time.
Ack, I didn't reply to the right comment. I was referring to the new weekly and every reboot prompt about screen recording: https://9to5mac.com/2024/08/06/macos-sequoia-screen-recordin...
1 reply →
As a maintainer of an open source app with 30K downloads per version, this will definitely make inconvenience my macos users
This will mostly affect advanced users. Hopefully, my next update will be Asahi, once its hardware support (especially HDMI output) has advanced enough.
I tried Asahi on my older M1 macbook and the battery life is still very bad. I am pretty experienced trying to dive into CPU schedulers and kernel settings, etc. to try and fix it, but I was unable to squeeze more than about 3 hours of battery out of the laptop WHILE CLOSED! In contrast just booting up mac os the battery lasts about 36 hours+ while closed.
When did you try it? There were some big improvements recently:
> Putting EAS and utilisation clamping together, we took a 15" M2 MacBook Air from about 6 hours of useable battery life just sitting at the desktop to about 8-10 hours of 1080p30 YouTube, 12-15 hours of desktop use, and an enormous 25-28 hours of screen-off idle time. We still have many more tricks up our sleeves to eke out more battery life, and a deep dive on EAS utilisation clamping is in the works. Watch this space!
https://www.notebookcheck.net/Asahi-Linux-improves-battery-l...
I bought a used M1 Max MBP recently, in part because the Asahi features table is starting to look pretty good.
But with the remaining outstanding hardware issues and the battery life gap in mind, I will probably get an overall better experience sooner if I just pony up for the upcoming Snapdragon X Elite laptop from Tuxedo Computers¹. :-\
On the other hand, the whole Linux desktop stack has benefited from work that Asahi devs have done, so I think that project is still undeniably valuable even for users on other aarch64 hardware.
--
1: https://www.tuxedocomputers.com/en/TUXEDO-on-ARM-is-coming.t...
Apple seems to like to coerce their users onto their preferred track little by little, release after release, instead of hamfistedly forcing it on day one. Instead, each release is a small drip of inconvenience and nudging.
Long time ago, you could run any executable you wanted. Then, you got a little nag, but whatever. Then (I think) you had to right click and take an extra step to run them, with a scary warning. Then, you got an even scarier warning and had to navigate into Settings to select "Allow applications downloaded from" -> Anywhere. Then, they removed the "Anywhere" option, but you could re-enable it with the command line.
It's also directionally clear: They surely intend to fully boil the frog one day and remove the ability to do this.
Se also: The UX you have to navigate in order to fill your own password into web pages on Safari.
> In macOS Sequoia, users will no longer be able to Control-click to override Gatekeeper when opening software that isn’t signed correctly or notarized.
Will Right Click > Open still work? That is how I currently bypass this issue with unsigned applications.
Right-click and control-click are the same thing.
hopefully
xattr -d com.apple.quarantine
will keep working.
As well as `sudo spctl --master-disable`, except it now gets reset sometimes because you know, computers are so unreliable, they forget things all the time.
I've had some apps refuse to run until I acknowledged their signer in the Security & Privacy section of System Preferences even though the quarantine bit was not set, unfortunately.
2 replies →
No because Control+Left-click = Right-click.
Sorry Apple, but I have no intention to pay 100€ per year for the privilege to notarise an application I have up for free on a GitHub repo no matter how shitty you make the process.
At the moment I'm just linking to https://disable-gatekeeper.github.io/ and hoping that if anyone ever comes across my repo, that they know how to read and won't bother me about it. Maybe in the future the optimal solution would be to just not provide any pre-built binaries.
Yeah, this is exactly the problem. Apple doesn't want hobbyist programmers either on iOS or MacOS. They see inconveniencing open source programmers who aren't selling a product (and therefore not going to pay Apple for the right of being an "official developer") as a good thing.
The usual arguments I hear for this is grandma or kid following these specific instructions and installing a malware. But how many attacks make use of these?
The kind of mob “protection” that no one needs
The amount of Mac development has cratered in recent years. No money to be made compared to iOS.
Every day we march closer and closer to a neutered IOS walled garden on OSX and it makes me sad because I otherwise love OSX.
They should go the OTHER way, relaxing iOS.
They are (when forced by the EU).
[flagged]
[flagged]
It's a cancer in the sense that it is a growing and spreading idea in Apple's ecosystem, and is strangling the usability of its products. It doesn't really resemble a genocide metaphorically.
2 replies →
[flagged]
>The only people who knew about the Control-click shortcut were ones who probably understood the risks they were taking.
Or users who were told to "control click" by malicious sites peddling trojan horses and other stuff, so that they never see a warning
> so that they never see a warning
Untrue. You always see a warning: https://lapcatsoftware.com/articles/unsigned.html