4 ms·

This article mixes up a lot of issues and is not very coherent. Here are some important clarifications: 1. You can run any unsigned or unnotarized software fro

This article mixes up a lot of issues and is not very coherent. Here are some important clarifications: 1. You can run any unsigned or unnotarized software from any developer by right-clicking the app, selecting "Open", and then click the "open" button in the scary warning. It's really simple. I wish people would stop pretending like it was really hard to run unsigned software. 2. Apple does not "curate" or "review" software distributed outside the Mac app store. The notarisation process runs some automated malware checks, and that's it. The goal is to block malware, not to limit the content you put on your computer. 3. Notarisation takes less than ten minutes. It's easy to automate it, and you can also do it manually if you want. You can staple the notarisation ticket to the app, but you don't have to. MacOS will look up the ticket via a webservice if you don't staple it. The documentation sucks, but that's the only bad thing you can say about it. 4. Apple does review stuff you submit to the Mac app store, but fortunately it's entirely optional to submit stuff to the Mac app store, there's nothing stopping you from releasing software outside the app store without any review. 5. Apple did end support for 32bit apps, which sucks, and I don't have anything good to say about that.

pvg 7y ago
The article addresses your first item directly and doesn't actually say what what your second one claims it says. It's not clear to me how three and four are responsive to the article. You might be able to clarify your clarifications if you give it a closer re-read.
- jakobegger 7y ago
  While the article may technically address these points, it's not very effective, judging by what people post here. At the time I posted my comment, all the top comments here on HN were complaining how Apple is limiting artistic expression or how hardware makers decide which software we can run. That's why I wanted to post my clarifications. I don't think that the article is technically wrong, but it seems that people have not read it closely and just came to weird conclusions.
  - pvg 7y ago
    Maybe you should have responded to those comments? Your 'clarifications' of the article are really inaccurate and end up misrepresenting it. You can still edit your comment to correct that.
dkonofalski 7y ago
I would also argue that the "quirkiness" of what the OP is attempting to do that makes it such a difficult edge case is unnecessary too. For example, their simplest example of two executables that generate files that the user has to manually share between two folders is still completely do-able if the author just simplified the execution. If it's really just a game, and nothing more, then they should be able to just make it 1 executable that opens its own sandbox where there are 2 fake executables inside of it that do whatever they need to do to make the game work. There's literally no reason, other than the gimmick and novelty, for this game to have to run as 2 separate executables that actually play and have access to your documents folder (or whatever folder on the drive the "game" happens under). It reminds me a lot of the uproar on Windows when shortcuts were indistinguishable to an application from the actual folder. When MS changed this so that the end result was the same but the applications were also aware of whether they followed a shortcut or not, there was a bit of outcry because it broke a few apps that relied on the file system not knowing the difference. In other words, these apps built their entire functionality around an unintended bug and then cried foul when that bug was fixed. In this case, at least, the author just seems upset because they can't continue to create things that are immediately abandoned afterwards. They've become reliant on being able to constantly create new work.
- crooked-v 7y ago
  Also, even keeping the 'separate folders with generated files' gimmick, it could do exactly that without permissions checks by putting the stuff in `$HOME/Library/Application Support/AppNameGoesHere` and opening the folders under there for the user.
  - dkonofalski 7y ago
    Exactly. The complaint sounds too much like someone building a sand castle on the beach and then complaining when the tide has washed it away.
sloopy543 7y ago
Regarding the 32-bit thing, wouldn't it be in any game developers interest to create additional x-bit options to rebuild the game in higher bit systems? I would want my game to be amenable to historical preservation, which is the reason I do my own engines in lower level languages.
- TophWells 7y ago
  If they can, certainly. Assuming the developer still exists, and they still have the source code, some idea of the build environment, and they want their game to still be accessible. And even then: https://mightyvision.blogspot.com/2017/04/868-hack-update.html https://mightyvision.blogspot.com/2017/04/868-hack-update.ht... > Isn't this just a matter of opening up the project, changing one line and recompiling? Should take five minutes, it's not really a big deal? Yes and no. The 64-bit change itself is small but they change enough other things every few months that recompiling against new versions of the libraries doesn't simply work. You get a few linker errors and have to look up the new names for a couple of functions. Or there's a new element in one of the libraries with the same name as one of my variables so I have to find+replace to change its name. And then you run it and find that it's in portrait mode, squished into half of the screen, so you have to look up what changes they've made to how screen orientation works and change a few more lines. [...] It adds up. Sure, you can work around it, but from the developer's perspective their game has just been designated obsolete for no reason that Apple couldn't have fixed themselves.
jsgo 7y ago
All good responses, if I had to add one gripe about Apple's direction (re: 32-bit kill off), I'd add the Metal Only drivers post-High Sierra. I bought my MacBook Pro specifically for eGPU and my preferred GPUs are from Nvidia (using a GTX 1080). There was some degree of finagling to get it to work, but it could be done. And then the update after High Sierra happened and killed it outright. And as much as I'd rather boot into macOS for non-gaming items, because my monitor hooks into the eGPU, I boot into Windows for anything asides Xcode which is pretty heavy. Could stick to High Sierra, but that isn't exactly an option. It truly is a shame that we couldn't just be allowed to change a flag or confirm a prompt to maintain business as usual. As such, this may be my last Apple branded PC and will just use it as a build machine in the future whenever I inevitably upgrade. Maybe Nvidia and Apple will work together on metal drivers, but quite frankly, it is the edgiest of edge cases so I imagine the chances of that are minuscule. That isn't to say I don't somewhat understand their reasoning: they basically appear to be scaling back numbers of areas they can't safeguard or require support (non-metal drivers and 32-bit respectively). But at that point it seems like provide something that users can do to bypass it.
tinus_hn 7y ago
You do need to get a paid developer account though and Apple has announced that in the next version of MacOS bypassing notarization is going to get more difficult.
- pfranz 7y ago
  Where was this said?
- jakobegger 7y ago
  You only need a paid account if you want to sign and notarize your app. You can build apps and distribute them without a developer account. But macOS will show a scary warning to your users.
Grue3 7y ago
>You can run any unsigned or unnotarized software from any developer by right-clicking the app, selecting "Open", and then click the "open" button in the scary warning. It's really simple. If I had to do this every time to run an app, I'd throw my PC out of the window. How are you people OK with that?
- jakobegger 7y ago
  You only need to do that the first time you launch an app.

pvg 7y ago

The article addresses your first item directly and doesn't actually say what what your second one claims it says. It's not clear to me how three and four are responsive to the article. You might be able to clarify your clarifications if you give it a closer re-read.

jakobegger 7y ago
While the article may technically address these points, it's not very effective, judging by what people post here. At the time I posted my comment, all the top comments here on HN were complaining how Apple is limiting artistic expression or how hardware makers decide which software we can run. That's why I wanted to post my clarifications. I don't think that the article is technically wrong, but it seems that people have not read it closely and just came to weird conclusions.
- pvg 7y ago
  Maybe you should have responded to those comments? Your 'clarifications' of the article are really inaccurate and end up misrepresenting it. You can still edit your comment to correct that.

dkonofalski 7y ago

I would also argue that the "quirkiness" of what the OP is attempting to do that makes it such a difficult edge case is unnecessary too. For example, their simplest example of two executables that generate files that the user has to manually share between two folders is still completely do-able if the author just simplified the execution. If it's really just a game, and nothing more, then they should be able to just make it 1 executable that opens its own sandbox where there are 2 fake executables inside of it that do whatever they need to do to make the game work. There's literally no reason, other than the gimmick and novelty, for this game to have to run as 2 separate executables that actually play and have access to your documents folder (or whatever folder on the drive the "game" happens under). It reminds me a lot of the uproar on Windows when shortcuts were indistinguishable to an application from the actual folder. When MS changed this so that the end result was the same but the applications were also aware of whether they followed a shortcut or not, there was a bit of outcry because it broke a few apps that relied on the file system not knowing the difference. In other words, these apps built their entire functionality around an unintended bug and then cried foul when that bug was fixed. In this case, at least, the author just seems upset because they can't continue to create things that are immediately abandoned afterwards. They've become reliant on being able to constantly create new work.

crooked-v 7y ago
Also, even keeping the 'separate folders with generated files' gimmick, it could do exactly that without permissions checks by putting the stuff in `$HOME/Library/Application Support/AppNameGoesHere` and opening the folders under there for the user.
- dkonofalski 7y ago
  Exactly. The complaint sounds too much like someone building a sand castle on the beach and then complaining when the tide has washed it away.

sloopy543 7y ago

Regarding the 32-bit thing, wouldn't it be in any game developers interest to create additional x-bit options to rebuild the game in higher bit systems? I would want my game to be amenable to historical preservation, which is the reason I do my own engines in lower level languages.

TophWells 7y ago
If they can, certainly. Assuming the developer still exists, and they still have the source code, some idea of the build environment, and they want their game to still be accessible. And even then: https://mightyvision.blogspot.com/2017/04/868-hack-update.html https://mightyvision.blogspot.com/2017/04/868-hack-update.ht... > Isn't this just a matter of opening up the project, changing one line and recompiling? Should take five minutes, it's not really a big deal? Yes and no. The 64-bit change itself is small but they change enough other things every few months that recompiling against new versions of the libraries doesn't simply work. You get a few linker errors and have to look up the new names for a couple of functions. Or there's a new element in one of the libraries with the same name as one of my variables so I have to find+replace to change its name. And then you run it and find that it's in portrait mode, squished into half of the screen, so you have to look up what changes they've made to how screen orientation works and change a few more lines. [...] It adds up. Sure, you can work around it, but from the developer's perspective their game has just been designated obsolete for no reason that Apple couldn't have fixed themselves.

jsgo 7y ago

All good responses, if I had to add one gripe about Apple's direction (re: 32-bit kill off), I'd add the Metal Only drivers post-High Sierra. I bought my MacBook Pro specifically for eGPU and my preferred GPUs are from Nvidia (using a GTX 1080). There was some degree of finagling to get it to work, but it could be done. And then the update after High Sierra happened and killed it outright. And as much as I'd rather boot into macOS for non-gaming items, because my monitor hooks into the eGPU, I boot into Windows for anything asides Xcode which is pretty heavy. Could stick to High Sierra, but that isn't exactly an option. It truly is a shame that we couldn't just be allowed to change a flag or confirm a prompt to maintain business as usual. As such, this may be my last Apple branded PC and will just use it as a build machine in the future whenever I inevitably upgrade. Maybe Nvidia and Apple will work together on metal drivers, but quite frankly, it is the edgiest of edge cases so I imagine the chances of that are minuscule. That isn't to say I don't somewhat understand their reasoning: they basically appear to be scaling back numbers of areas they can't safeguard or require support (non-metal drivers and 32-bit respectively). But at that point it seems like provide something that users can do to bypass it.

tinus_hn 7y ago

You do need to get a paid developer account though and Apple has announced that in the next version of MacOS bypassing notarization is going to get more difficult.

pfranz 7y ago
Where was this said?
jakobegger 7y ago
You only need a paid account if you want to sign and notarize your app. You can build apps and distribute them without a developer account. But macOS will show a scary warning to your users.

Grue3 7y ago

>You can run any unsigned or unnotarized software from any developer by right-clicking the app, selecting "Open", and then click the "open" button in the scary warning. It's really simple. If I had to do this every time to run an app, I'd throw my PC out of the window. How are you people OK with that?

jakobegger 7y ago
You only need to do that the first time you launch an app.