4 ms·

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 quarantin

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.

WaltPurvis 7y ago
>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.
- galad87 7y ago
  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.
  - WaltPurvis 7y ago
    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.
    - saagarjha 7y ago
      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.
galad87 7y ago
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.
- mistahenry 7y ago
  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
reaperducer 7y ago
early versions beta I think you answered your own question there. People have to stop treating betas like gospel.
- mistahenry 7y ago
  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).

WaltPurvis 7y ago

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

galad87 7y ago
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.
- WaltPurvis 7y ago
  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.
  - saagarjha 7y ago
    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.

galad87 7y ago

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.

mistahenry 7y ago
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

reaperducer 7y ago

early versions beta I think you answered your own question there. People have to stop treating betas like gospel.

mistahenry 7y ago
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).