Anecdotally, I find that the people who are loudest about Apple's misdeeds (both real and assumed) are often people who've never even used an Apple product.
There is plenty of legit criticism of Apple to be made, and you certainly don't have to be an Apple customer to make it. But half the time what I see instead is pearl-clutching from people who don't have enough experience with the platform in question to tell what an announced change even does, blowing up what amount to minor inconveniences into the end of all life as we know it.
The other side of this is, when I complain about Apple not allowing sideloading on iOS, I get asked why I use an iPhone if I don't like the policy.
(fwiw, I have no issues with macOS as long as unsigned apps can still be run, and lots of issues with iOS where they cannot be.)
Other companies only require account for using non-OS API such as Firebase / Google Services for example.
Sure that's beyond the reach of most people, but how on earth do you people imagine that people develop and test new apps on iOS devices if you think an app _must_ be published to the App Store to run at all?
I kinda like that requirement because it means that I'm technically capable enough to make a potentially system-breaking change. It's not as nice and friendly about it as macOS but I think it's a fair compromise.
Interesting. The number of people of who I know that they have complained about Apple, and of who I also know that they have never used an Apple product is zero.
If one actually considers the spirit of my comment (people getting caught up in outrage about issues they can't actually judge properly), several of the comments of this very post make it pretty clear that their authors have likely never interacted with a Mac for a day in their lives but are nevertheless very opinionated about how this change will affect macOS users.
My comment was not a particularly long one. Try reading it through the end.
I was agreeing with this person that I responded to and talking about the one that you responded to.
It’s definitely easy to get confused with the HN ui though. I wish they would put vertical lines or something to the parent comment or just think of something better. I thought we had half of the worlds software geniuses here! Can’t we figure this out?
And those who are loudest about animal abuse in factory farming, don't eat meat.
Now, Apple is making that impossible, which hurts developers who can't afford to go all-in on the mac platform.
How do you test your software without the machine you're targeting? Every programmer knows that VMs aren't as good as the real thing.
Not everyone can afford to keep around a lab full of macs running multiple versions of macOS.
Judging my the reaction to my comment, Today I Learned it’s acceptable to release software with only cursory testing on a friend’s computer. Explains a lot about recent software quality actually...
I'm concerned at this point about if anybody that this supposedly effects has actually done any research at all on it.
I was concerned MacPorts would stop working on my computer. I don't plan on publishing apps for Mac, but I depend on apps others publish.
All MacPorts has to do is either avoid setting the quarantine bit in the first place (easy enough) or remove it. The quarantine bit is nothing more than an xattr called “com.apple.quarantine” which you can inspect or remove with the xattr tool.
> The MacPorts installer pkg will need to be submitted, but I don't think much else will change. Using MacPorts-built kernel extensions is already impossible because of signing requirements (we don't have a kext signing certificate and I don't think we qualify for one.)
> For general apps, Gatekeeper doesn't prevent running locally built ones due to them being unsigned, and I gather than notarization is only required in the same circumstances as signing. (It would be incredibly inconvenient for developers to test anything if this were not the case.)
https://lists.macports.org/pipermail/macports-dev/2019-Septe...
> * For 10.14 users: The pkg meets Apple's new requirements for notarization. This includes enabling the hardened runtime for all executables, which has the potential to cause new issues due to denying access to certain system resources and preventing the loading of unsigned plugins. Please let us know about any such problems.
MacPorts .pkg installers are notarized since 2.6.0.
You also couldn't notarize old apps that weren't built with secure timestamp, hardened runtime, etc (a lot of versions of some software I'm supporting back to 10.7 preexisted some of the required criteria) until the beta release that coincided with this announcement in early September.
I think Apple relaxed their stance here because they did not want the average person to think that Catalina was breaking their apps and have subsequently deferred their "hardening" to January 2020.
{
"severity": "error",
"code": null,
"path": "my/app/path",
"message": "The signature does not include a secure timestamp.",
"docUrl": null,
"architecture": "x86_64"
},
{
"severity": "error",
"code": null,
"path": "my/app/path",
"message": "The executable does not have the hardened runtime enabled.",
"docUrl": null,
"architecture": "x86_64"
}
In my opinion, a number of people in these threads are missing the point when they suggest: "You can easily run these programs if you just do these quick tricks like using the command line or removing an xattr from the file or a special click workflow" There are companies out there making software for normal people (ie non technical) who will think your app is broken if double clicking doesn't work. These people will call your support lines and this will cost your company money
Two months? So Catalina will start breaking apps for average users after only two months? It hardly seems worth it for Apple to have that short of a delay.
beta
I think you answered your own question there.
People have to stop treating betas like gospel.
I've always viewed a beta as a way to test that my app has not regressed. If it has, I open issues with Apple (or whomever). If these issues are either cited as not-to-be-fixed or I hear nothing back, I will create a release of my apps that works around whatever issues are there. IMO determining breaking changes in beta versions allows one to develop fixes as well as create and plan the rollout of the new software before the beta goes lives (and therefore avoid any regression/downtime).
Yes. I take offense to you generalizing all complaints as just wanting to "beat a dead horse"
I find this a common problem when it comes to just about anything these days including tech sites where I appreciate that the local community generally is knowledgeable and the likelihood is high that someone(s) has granular knowledge of the topic.
But man when it comes to the big general topics that get a lot of spin in the press it's all "OMG Google" "OMG Apple" "OMG JavaScript" and so forth. But nobody really talks about what the topic means on a functional level.
I was under the impression there's a process involved with Apple to approve these things. From: https://developer.apple.com/documentation/security/notarizin...
"Give users even more confidence in your software by submitting it to Apple for notarization"
So it seems the "key" difference here is that while most Linux package managers seem to use GPG to sign based on the author's verification, here Apple is the trusted source, forcing application authors to bow down and submit to review (even if it's automated).
Whereas for all GPG packages I just sign the same way, here my process is different, and Apple is forcing my hand.
Don't get me wrong, I don't want users getting viruses or generally bad software any more than the next guy, but it seems out of place to rely on some specific Apple protocol to do this. Though, it doesn't surprise me at all that Apple wouldn't try to "play nice" in this space.
Edit: further reading finds the following.
"Notarization requires Xcode 10 or later. Building a new app for notarization requires macOS 10.13.6 or later. Stapling an app requires macOS 10.12 or later."
As a developer of some cross platform applications who happily doesn't know anything about Xcode (and plans to keep things that way) I'm upset by this.
You're under the wrong impression.
Think of it more like Google's certificate-transparency log.
Apple will have a log of all applications distributed outside of the app-store and macs can consult this transparency log during installation and warn the user if (a) Apple has revoked the certificate because Malware has been detected or (b) the developer who made the software being installed doesn't have an email address. Users will still be free to ignore the error messages (just as they are on Linux and Windows).
> As a developer of some cross platform applications who happily doesn't know anything about Xcode (and plans to keep things that way) I'm upset by this.
I generally advise people to not get upset about things they don't understand and don't care to understand. It feels strange to me that I feel have to give that advice, but what else can I do? People might read your (well-written) comment and develop the same fears and hysteria you have about something they don't understand either, but care to, and that makes the world a worse place.
I wouldn't say I don't care to understand. In fact quite the opposite. If someone can explain to me how this process should work for applications that distribute to, let's say, 10 different operating systems I'd be all ears.
But what fears and hysterias are you talking about? I quote Apple's own developer material, and complain about what it says. I don't want to deal with Xcode to package apps for macOS, sorry. And I find it somewhat oppressive to force communication upstream to Apple in order to run applications smoothly on their OS.
Then don't.
> I find it somewhat oppressive to force communication upstream to Apple in order to run applications smoothly on their OS.
Yeah, I know, but that's what packaging and releasing is.
On Debian, you need to contact Debian (or a Debian packager) to make your application easy to install and run on Debian because the Debian expectation is that the user runs apt install myprogram to install it, and navigates to the menu and clicks on myprogram to run it.
On Fedora, same same, but with Fedora (and it's rpm/yum/dnf).
On FreeBSD, same same, but with FreeBSD (and it's ports, etc).
And so on.
About the only operating system where the user-expectation was you don't need to talk to anyone is Microsoft, and building the expectation into users that programs can "come from anywhere" is why we had so much malware and junk on Windows. This wasn't a good thing.
I suggest you just get over this. It's better for macOS users, and it doesn't impact power users at all.
> what fears and hysterias are you talking about?
Look around this thread: It's chock full of fudding about how Apple is taking away their freedoms of some kinds, or there's a slippery slope, or that this somehow isn't 100% better for end-users (the people who buy Apple products).
How is having a lot of people afraid about nothing a good thing?
> If someone can explain to me how this process should work for applications that distribute to, let's say, 10 different operating systems I'd be all ears.
I mean, I'm happy to teach you, but I don't work for free. What do I get out of it?
So you project your frustrations with them onto me?
But given how you'd rather type up a long winded rant about ranters rather than answer my simple question, I suspect you either don't know how to do it, or it's in fact not possible. I'm not trying to get free lessons, I'm trying to get someone to prove to me how this works.
Does this work on your tax preparer? I suspect you either don't know how to do my taxes, or it's in fact not possible.
Does this work on your driving instructor? I suspect you either don't know how to drive a car, or it's in fact not possible.
Does this work on your plumber? I suspect you either don't know how to unclog my toilet, or it's in fact not possible.
No? So why the fuck would you think it would work on me?
> But given how you'd rather type up a long winded rant about ranters rather than answer my simple question: If someone can explain to me how this process [of packaging and signing] should work for applications that distribute to, let's say, 10 different operating systems I'd be all ears.
As short a statement this is, it's not a question, let alone a simple question.
I typically charge companies as much as £30k a week to listen to "questions" like this, and I'm not much interested in doing it for free on the Internet. If you can figure out how to ask a question maybe someone will answer it (heck, maybe it will even be me), but if this is how you want to talk to me it'll have to be at my day rate.
Kind regards.
Gatekeeper really isn't a stringent measure, it just protects people who don't know what they're doing.
Ed: seems there is a more general check now - but limited to checking against known "malware" - not "whitelist" (motorized) https://news.ycombinator.com/item?id=21180317
But just from a security and privacy perspective, why would a non-admin be downloading and installing random software packages?
It's also the default policy of my work, a university. Staff do have local administrator access to their machines, but are not supposed to use it for regular operations for safety.
Once the software is installed, I can use it from my regular account.
> Staff do have local administrator access to their machines, but are not supposed to use it for regular operations for safety.
The point of this exercise is that installing random software from the Internet shouldn't be a regular operation; users should take extra care when doing it.
So...elevate permissions when you need to perform this new administrative task? I don't see how that changes the crux of the matter (you still are the de facto admin, even though you've applied artificial constraints to yourself, because you hold the admin credentials).
Do you use macOS?
> Do you use macOS?
Almost exclusively.
They should be able to download and app and use it without having to call tech support.
Anti-user features like intrusive telemetry are standard fare in commercial software, and running those apps in a sandbox could protect the user without having to rely on Apple's approval system.
It isn't if the user wants to use software that isn't available on the App Store.
Arbitrary programs can be run with the macOS sandbox, there is no need for the App Store for security.
Accounts ought to be granted privileges based on the user's need to get things done.
Most consumer laptops and PCs I've seen (and I've seen a lot) don't even have a non-admin user account setup.
in macOS, even if you run as admin, the only thing that gives you is `sudo` access. Your "admin" user still is a normal user, but it's allowed to gain elevated privileges by supplying their password (or doing biometric auth).
The only difference between running as an admin and not running as an admin is that in the former case you don't have to type in your user name.
>having to elevate to an admin account in order to "download anything" would be a nightmare for any substantial IT department to support
normal users can download all they want. They can't execute it though. That's absolutely what I would like my machine to be configured as.
Who disagrees with that? For most users, by a long shot, installing software is only a tiny fraction of the tasks they perform.
Anybody, including that substantial IT department has to elevate to an admin account to install software, and that is a good thing.
Any halfway smart IT department won’t have to type an admin password on every machine or even visit every machine, though.
> Most consumer laptops and PCs I've seen (and I've seen a lot) don't even have a non-admin user account setup.
Have you ever used macOS or are you basing this on Windows laptops?
If so that's a huge barrier.
I have the chicken and egg problem.
I refuse to develop for Apple due to their anti-developer and anti-consumer policies.
So would I make Apps for Apple is they played nicely? Yes.
But anti-consumer? How is this anything but good for 99% of Mac users? It keeps totally un-savvy users safer, puts savvier users on high alert, and doesn’t affect power users at all (other than the minor inconvenience of right clicking the first time you open a non-notarized app).
This is such a HN comment. On what planet is it Apple's responsibility to maintain their operating system in such a way that third-party apps from developers who don't give a shit about maintaining compatibility can continue running until the heat death of the universe? It's like being angry that Microsoft didn't stick with 8.3 character filenames forever.
On planet Earth.
> who don't give a shit about maintaining compatibility
Or the developer does not exist anymore or has "pivoted" to something else entirely or has discontinued the program or they have no funds to do the conversion or they rely on technologies by others that (do not exist anymore, have "pivoted" to something else entirely, have discontinued the technology, have no funds to do the conversion, rely on technologies by others that (do not exits anymore, ...)), or simply the newer version is undesirable for the user (due to worse UI/UX, lower performance, monetization-driven user-hostile changes, etc).
As a user all i care about my programs keep working.
> It's like being angry that Microsoft didn't stick with 8.3 character filenames forever.
When Microsoft introduced long file names it was implemented in a way that was backwards compatible with existing software in a way that would be possible to both use existing volumes with 8.3 format, add/rename files with long filenames and have those be visible in a 8.3 form for compatibility with older software.
And 8.3 character compatibility still exists on Windows 10. For example if you have any GOG games installed you can type DIR C:\GOGGAM~1 on command prompt to see the contents of C:\GOG Games. You can disable this via the registry, but it is enabled for backwards compatibility.
This is Apple's official line, but no one is going to actually have to do anything different if they don't want to. Some not-so-tech-savvy users might end up with apps they don't understand how to open after downloading them, but those are also the user most susceptible to falling for malicious downloads, so I'd call it a pretty good security feature.
Anyway, were any of you who are complaining in this thread planning on actually publishing an app for macOS, or just here to beat a dead horse?