Hacker News Reader

Comment by chadlavi | Hacker News Reader

Apple doesn't require a paid developer account to do this, and it's also not actually required. A user can still click "Open" from the right-click menu on a newly downloaded app to open it for the first time, and then double click the app to open it subsequent times like normal.

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?

View on HN

> 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?

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.

> 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.

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.)

And that's a legitimate complaint, and one I have as well (though my issue is less with not allowing sideloading and more with the pretty high barrier to entry to the only official distribution method. I'd be pretty much okay with being unable to sideload apps on iOS, but having a free and more lax tier of the App Store for hobbyists (somewhat akin to Youtube's unlisted videos or Qt's licensing).

But you can sideload an application, you just need to use as computer to do it.

there’s no way to publish apps to iOS except paid Apple Developer account. That’s different than all other platforms where we can get any binary to run.

Other companies only require account for using non-OS API such as Firebase / Google Services for example.

You very much can build and sideload an IPA on iOS if you have (access to) a computer running macOS.

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 feel like I have this discussion every week. It’s technically possible but—by design—practically unworkable for apps you actually want to use rather than just test. They expire after seven days, at which point you need to reconnect to a computer and reinstall them.

You don't actually need the latter.

It only works for a short amount of time which makes this rather impractical.

Have you heard/of looked at AltStore?

Yes. It’s interesting approach. Still your apps will be timebombed for 7 days. Imagine making a app for private use by my family and going on vacation longer than 7 days. I must have access to my computer...

I'm not sure that I follow. You can sideload apps on iOS. Is the issue that you have to use a computer to do it?

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.

No, its the fact that you need to re-upload that app every 7 days..

I have to use so Apple products, although mainly mobile devices. I don't have any deeper prejudice against the users but think the devices are mostly useless.

Should people be required to own a Mac to release desktop software for the Mac? It is - or at least was - quite possible to make an application in Electron or Java or some other tool and release it cross-platform, having beta testers handle platforms specific testing.

Now, Apple is making that impossible, which hurts developers who can't afford to go all-in on the mac platform.

I don't quite see how that at all follows, considering that notarization is something you can do from e.g. a CI server.

I'm concerned at this point about if anybody that this supposedly effects has actually done any research at all on it.

The last place I worked at, it was socially forbidden to automate the digital signing process, such as in a CD pipeline. Now I'm curious to hear if we were being paranoid.

Should people be required to own a Mac to release desktop software for the Mac?

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.

You send it to a friend of yours that has a mac, but isn't a developer.

I hope you are being sarcastic! That’s a low quality assurance bar, even by a hobbyist’s standards. “My friend with one Mac running one OS version says it works, therefore I’m ready to release?”

I'm not. When you're a high school student releasing your first computer game on a well-tested engine, that's a perfectly valid level of quality assurance.

Not everyone can afford to keep around a lab full of macs running multiple versions of macOS.

No one says you need a bunch of Macs. People are saying that you need one, which is one more than the OP wanted to use.

I’d think any developer would want at a bare minimum two test machines: one representing the minimum system required by your application including minimum targeted OS version, and a higher end machine running the latest.

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...

And that's why Electron is popular. People don't have to deal with these issues.

More specifically, developers don't have to deal with these issues. They simply create more issues for their users.

> 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.

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.

And the number of people I know who complain about Apple and who have never used an Apple product is non-zero. _Interestingly_, that's kind of what the word "anecdotally" implies.

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.

> 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.

And those who are loudest about animal abuse in factory farming, don't eat meat.

Interestingly, I find the same to be true about people who complain about Android here on HN. And I feel it is for the same reason as you've mentioned. I cannot count the number of times I've had to laugh in pain at the shocking ignorance displayed by a large number of users when talking about Android and other associated Google products.

> 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?

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.

No, from what I understand this only affects binaries through Gatekeeper. Gatekeeper is “opt-in”—sort of. The way it works is that your web browser has an option “LSFileQuarantineEnabled” set in the bundle, and this makes it so files it creates have the “com.apple.quarantine” extended attribute on them by default. This attribute is propagated when you extract archives. When you open a program with the quarantine bit, you get the Gatekeeper warning.

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 .pkg installer is probably the only thing affected, and they should be able to get that signed. (Plus, anyone using MacPorts should be capable of the right-click+open workaround.)

Actually an interesting question: will Apple be happy to sign third party app stores and package managers? Including those that, say, sell apps and take a percentage?

They sign literally everything. There is no human review process involved in notarization.

They sign malware?

Pretty sure they do. Part of the point is that they can revoke the signature once it’s found to be malware, and likely the signatures for everything associated with that developer account.

They've probably got enough info from your signup for the developer program to send the FBI to your door afterwards.

They try not to, but it certainly seems like Notarization is more to be able to disable malware after it's detected than preventing it from being signed at all.

So is this similar to Windows "this file was downloaded from the Internet" warning?

Yes, but slightly more difficult to override - it's not presented as an option in the warning itself.

Basically.

https://lists.macports.org/pipermail/macports-dev/2019-April...

> 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.

In early versions of the MacOS beta, the right-click open did not work, nor did starting the app from the command line. I never tried checking for the quarantine attribute and subsequently altering so I cannot comment there.

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.

>and have subsequently deferred their "hardening" to January 2020

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.

Nothing will break. Apps signed before will continue to work like before, apps signed now will required to be notarized. Unsigned apps will work like before.

I was just going by what the person I was replying to (who wasn't you) was saying. If, as that person said, apps will break (or appear to break to average users) once "hardening" kicks in, then delaying it by a mere two months seems almost pointless. On the other hand, if as you say nothing will break, then a two-month delay in hardening seems equally pointless.

Apps that you currently have will not break, as they will not be quarantined. The requirement helps developers of apps that will be downloaded in the future.

10.15 requires signed apps that were signed after 1 July (or June, I don't remember exactly) to be notarized. If you were running a signed after 1 July app but not notarized, that explains it. Even though you can run unsigned app easily, you can easily apps with a broken signature.

I was trying to run versions of our app built between 2011 - 2016. None of them would open in the MacOS 10.15 beta. Before this September 3rd announcement, any attempt to notarize the app would be rejected for not having hardened runtime. I can still use `xcrun altool --notarization-info` to view old notarization reports and reasons for rejections. One such app from 2014, which I attempted to notarize on 2019-08-23 was rejected for reasons such as:

    {
      "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"
    }

I saw this announcement on September 3rd and upgraded the beta. My apps would not open still. So I went and notarized my old apps and this time all of them succeeded in notarization. As soon as the app was notarized, I could open the app in the beta.

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

early versions

beta

I think you answered your own question there.

People have to stop treating betas like gospel.

If my app completely stops working during a beta, are you suggesting that I should just wait until the actual release to find out that my app is in fact really broken should that be the case? And only then develop a new release for my app and release it as soon as possible, all the while having a deficient product for however long this may take?

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).

> Anyway, were any of you who are complaining in this thread planning on actually publishing an app for macOS

Yes. I take offense to you generalizing all complaints as just wanting to "beat a dead horse"

Yea for real. Just google "macOS signing issues on GitHub" and you can see a whole swarm of real example complaints.

>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?

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.

Ok, imagine if EVERY OS out there had their own signing system like this. Can you imagine how hard it would be to publish multi-platform software!? Sure macOS and Windows are the largest consumer OSes, and I'd be very shocked to hear Linux OSes doing this, but does that really make it OK?

Every OS does have their own signing system like this! That's how all the Linux package managers work.

I must be misunderstanding this then... if all I need to do is sign the binary with my GPG key (or comparable) then I don't see what all the fuss is about either!

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.

> I was under the impression there's a process involved with Apple to approve these things

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 generally advise people to not get upset about things they don't understand and don't care to understand.

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.

> I don't want to deal with Xcode to package apps for macOS, sorry.

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?

> Look around this thread: It's chock full of fudding about how Apple is taking away their freedoms...

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.

> 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.

Isn't the "right click > open" trick only valid for user accounts who are Administrators?

In defense of Apple, if the account someone is using is not an administrator, they probably shouldn’t be downloading things in the first place.

Huh?! Explain your position here, please.

Not the OP but: Some sysadmins and devs work in institutions where this wouldn’t be allowed or be practical to support (e.g. schools, some healthcare, etc.). It’s not universally applicable to every environment but it’s easy to get in the mindset that it is after you’ve seen what a determined idiot can do.

Oh, I agree there are plenty of scenarios where you want to restrict a user's ability to do something. But to draw that line at the admin level seems a bit overkill to me (and de-values the idea of having varying levels of privilege, which is more or less exactly what's going to happen for organizational users anyway). I'm not super familiar with Apple's business features but in a Microsoft shop this would (to an extent) be managed through group policy on the domain controller anyway.

I'm curious about _your_ position, actually. If a user doesn't have admin privileges and doesn't have the credentials to gain admin privileges, that's a clear indication that they both do not own the device _and_ haven't been trusted by the owner of the device to do whatever they want with it. Why exactly should they then be able to install and run random untrusted software on it?

My position is nobody ought to probably be running as admin for the vast majority of tasks, and having to elevate to an admin account in order to "download anything" would be a nightmare for any substantial IT department to support.

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.

I don't quite see how an IT nightmare follows. Where do you work that people are downloading and installing software on work computers every day?

> 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?

I work on both, have friends and family and coworkers and acquaintances who use both. If they really didn’t want grandma running as admin they would make it harder to find.

>My position is nobody ought to probably be running as admin for the vast majority of tasks

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.

”My position is nobody ought to probably be running as admin for the vast majority of tasks”

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.

I'm the owner of my device and use a non-admin account day-to-day. Is it really that unusual?

The account you choose to use does not change the fact that you are the de facto admin.

This response seems very pedantic. If you are the owner of the device and know the admin password, you are the admin regardless of what user account you're using.

No, it’s not pedantic in my opinion. Using the least privileged account you can get away with is the best practice I was referring to in OP. I’d hate to have to login into my domain admin account for something my daily job required, for instance. Reduce your own ability to shoot your self (and your employer) in the foot.

That's an odd position to take. I purposefully make my primary account a non-administrator and elevate permissions with my administrator account when I need to perform administrative tasks. This prevents scripts or programs from misusing permissions without my knowledge.

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.

Me too, and when I need to install non-Apple-approved software, I log into my admin account, do it, then log out of it again.

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.

Just out of curiosity, why don't you just put in your admin credentials when the prompt displays? Logging completely out of the current account and logging in to another account just to install software seems way more convoluted than necessary.

That's what I do if it's an option, but I think I've run into some software where that didn't work and I had to actually log into my admin account to install it. (But not log out of my regular one; more than one account can be logged in at once.) I can't recall what software that was, though.

> I purposefully make my primary account a non-administrator and elevate permissions with my administrator account when I need to perform administrative tasks

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).

Arbitrary programs cannot use de facto credentials.

...yes, they can? You're prompted to provide credentials (in some cases biometrics is fine, in others you must enter the password) if you/an application is trying to do something that requires escalated privileges.

Do you use macOS?

Right, but now you have explicit consent required to elevate to that level, whereas if you’re running as root already you can just silently do things without the user knowing.

> Do you use macOS?

Almost exclusively.

This is fairly standard best practice: your day-to-day account should not have admin-level privileges. It's the rough equivalent of running as root all the time (hand-waving a bit here).

Admin accounts on MacOS have to provide the admin password again (essentially sudo) to make any significant change to the system config. That includes installing applications, changing security, privacy and accessibility changes, etc.

In defense of users, when my parents want to use an app, I'm not going to send them documents on the Unix security model or explain how macOS security diverges from it.

They should be able to download and app and use it without having to call tech support.

Also in defense of users, they should be able to use any app they install without worrying whether or not it's malware.

Agreed. This is why a robust sandbox/containerization system is preferred to an arbitrary approval system.

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.

Yup, that's why Mac App Store apps are sandboxed. The Mac App Store is the experience we're describing: install an app and use it without having to call tech support or worry about malware.

> The Mac App Store is the experience we're describing

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.

Very few applications opt in to the macOS sandbox outside of the App Store.

We're talking about an optimal security platform. Apple could very well build macOS security around sandboxd without the App Store, but chose not to.

You’re free to use the sandbox outside of the App Store, but the problem is that there is little incentive to do so unless Apple forces you to through App Store review.

I'm thinking of something like QubesOS. Apple could enable the sandbox by default for all applications. There's no need for an App Store.

>"right click > open" brings up an admin challenge/authentication if executed by a non-admin user.

Don't know if it still works, but I used to get around this on school computers by loading the app binary (SomeApp.app/Contents/macOS/SomeApp) in the Terminal.

Gatekeeper really isn't a stringent measure, it just protects people who don't know what they're doing.

I still use this trick sometimes, because it's a way to get stdout logging output you might not otherwise see. Sometimes it leads to a quick pinpoint of your issue.

Oh, I do that too. Completely different purpose though.

Interesting. So it's not implemented as a check on fork()/exec() for example? (checking an xattr shouldn't be too onerous to do practically. Not sure I think it's a good idea. Then again, we've had the "exec" bit for many decades...).

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

No dog in the fight here.

But just from a security and privacy perspective, why would a non-admin be downloading and installing random software packages?

I have published apps for iOS and Mac. It was a horrible experience. Apples ecosystem is dogshit and they make you jump through far too many hoops, all just to target a small minority of overall smartphone/computer users. Most of the time it's just not worth it.

How does one actually notarize an app without paying? I believe it requires Developer ID, which does actually cost $99/year I’m unclear on this.

I too am curious.

You only need an apple id to notarize apps for macOS.

https://appleid.apple.com/account#!&page=create

Nope, you need to have a Developer account.

Isn't the experience for a notarized app the same as the current experience for an unsigned app? (i.e., right-click or go into the settings and allow.) If so, I really feel all this freak-out is unwarranted, because any moderately technical user will know how to do that.

How does one get something notarized without a paid developer account? Is apple now letting people submit their apps for notarization without paying?

You don't. But even before you couldn't sign an app without paying Apple, because the only valid certificates (Developer ID) are distributed by Apple (with the $99 Developer program).

What is the default user setting? Do you have to go to the setting and change it to be able to launch apps not downloaded from the app store or unsigned apps?

If so that's a huge barrier.

I for one welcome it, and would like to see sandboxes everywhere, given that it doesn't seem to be any other way to force people to actually care about security.

I'm just here to complain because it's annoying to incorporate yet another step in a CI flow.

"were any of you who are complaining in this thread planning on actually publishing an app for macOS"

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.

Anti-developer? Sure.

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 particular policy isn't anti-consumer, but other policies they have are anti-consumer - like breaking functionality that applications you bought are depending on in newer versions of the OS (which you need to update to because other applications and/or hardware will require it very soon).

I can see anti-consumer and pro-consumer at the same time. Over the recent years I've perceived Apple as being more and more anti-consumer, for consumers that are developers or graphic artists, and pro-consumer if you are a non-developer/non-graphic artist. This is regrettable, especially since devs and graphic artists were among their original consumer base that helped get them where they are today.

I'm not sure how that dichotomy applies, especially when you are -say- a graphics artist who wants to stick with an older pre-subscription model version of -say- Photoshop that you bought in a box, instead of being forced to pay a rent for the latest version.

>other policies they have are anti-consumer - like breaking functionality that applications you bought are depending on in newer versions of the OS

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 what planet is it Apple's responsibility to maintain their operating system in such a way that third-party apps

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.

Reply on news.ycombinator.com