11 ms·

Distributing Mac apps outside the App Store, a quick start guide (2021)

151 points by jb1991 4y ago

grishka 4y ago
I'm interested in distributing Mac apps without any Apple involvement whatsoever. How do I bypass the notarization requirement? Can I use a shell script that would remove the quarantine attribute? As in, I'd put the script into my disk image and instruct the user to click it to install the app.
- kybernetyk 4y ago
  https://lapcatsoftware.com/articles/without-notarization.html https://lapcatsoftware.com/articles/without-notarization.htm... I don't know if this still works, but it used to be that when you right-click an app bundle in Finder and select "open" (as opposed to double clicking the bundle) you get an "open anyway" option in the OMG APPLE CORP JUST WANTS YOUR BEST warning dialog.
  - pilif 4y ago
    Using this method requires admin rights though, but that’s probably for the better as running code of unknown provenance is probably a privilege of a machine’s owner
    - temac 4y ago
      Does the code then run with admin rights ?
      - lwkl 4y ago
        No this does the same as going into system settings and approve the binary after trying to open it the first time. This requires elevated privileges. After that you can run the app as a user.
- newaccount74 4y ago
  Shell scripts are affected by quarantine just like any other executable. The easiest solition is, as kybernetyk says, to right-click the app. If you do that, you can bypass most the warnings. Another possibility would be to install the app in a way that doesn't set the quarantine attribute, eg. with curl, rsync or brew cask. But Apple has been tightening seccurity year after year, so it's questionable how long all the workarounds will continue working. My recommendation would be to just notarize the app - Mac users expect notarized software, and if you tell users they need to bypass the security checks, then a lot of people will think you are sketchy.
  - grishka 4y ago
    > My recommendation would be to just notarize the app The problem is that this involves having a developer ID, which costs $100/year — which is the one thing I'd like to avoid. Hence my question. The apps I'm contemplating about would be free and open-source so I won't be making any money on them.
    - jagged-chisel 4y ago
      Rhetorical questions: how much salary do you make on other work? How much have you spent on your hardware? Real question: why is $100/yr such an egregious amount of money? If it’s a matter of principle, perhaps targeting macOS also lies outside those principles.
      - zeta0134 4y ago
        This would have been a completely unattainable amount of money as a high school student. In college, that money was better spent on school supplies and food, and spending cash was short. After college it took me the better part of a decade to get to the point where $100/year felt like something I could feasibly consider spending and not risk missing rent in January. $100/year is a lot of money to people in a wide variety of life situations. Being unable to afford this does not make them any less of a programmer.
        4y ago
- vbezhenar 4y ago
  To remove all attributes, just ask user to run `xattr -c filename`. But I'm not sure if that would remove notarization requirement.
  - 0ct4via 4y ago
    Non-technical end users won't want to be trying to enter Terminal commands they don't know or understand, and they shouldn't have to.
    - vbezhenar 4y ago
      How is it different from running shell scripts they don't understand (or entire applications for that matter)?
      - einherjae 4y ago
        It’s scarier, less ergonomic, and smells hacker-y. There is a significant difference between “just click on this”, and “open the DOS prompt and write these magical runes”
        vbezhenar 4y ago
        It was observed that people get attached to Ikea furniture because they assembled it and it contains tiny bit of their labour. May be it could work with software? Like you've executed some scary command to enable this software to work, now you attached to it.
        0ct4via 4y ago
        That's not a fair comparison though -- if you screwdriver slips or you put the wrong screw in the hole, your sofa doesn't stop working -- but you could do real damage to your OS. IKEA furniture assembly involves very simple tasks and tools, and a guide that's purely pictorial -- and even then, there are an array of services where people will do that assembly for you, even offerings from IKEA themselves. Software neither has the same physical presence, nor the same relative lack of risk. The average person can appreciate something "made with their own hands," but lacks the specialist knowledge to appreciate a script or code deployment. Given how scared and how easily-scammed people can be by having someone open Event Viewer in Windows and claim this means their computer has viruses, opening some script and demanding verbatim typing of commands is more likely to lead to anxiety or unsureness than anything, and certainly not attachment. You're thinking as if the average person is the average HN reader -- they're not. At all.
- ris58h 4y ago
  Right-click, Open, Open should work for ad-hoc signed apps as others mentioned. I've made my very first MacOS app and users didn't complain installing it. It's https://github.com/ris58h/Touch-Tab https://github.com/ris58h/Touch-Tab BTW.
- sbuk 4y ago
  > How do I bypass the notarization requirement? Why? As a software user I want you to notarise your software.
  - ris58h 4y ago
    As a FOSS developer I wish I could notarize it without paying $100/year to Apple.
    - sbuk 4y ago
      You'd need a separate certificate, which at the moment will cost considerably more than $100. Also is your objection the $100 or merely paying Apple?
      - samoit 4y ago
        Having to notarize your own software is giving one company total control over you and your future. It is unacceptable. I do not develop versions for macosx since notarization anymore.
        oleks637 4y ago
        This is probably my biggest fear. One day Apple can revoke my certificate, and suddenly my apps stop working for everyone.
        ryandrake 4y ago
        But this has not happened. You're basing a decision today on something that might or might not happen in the future. "One day," Apple could do anything. One day, they could totally prevent installing things that are not notarized. One day, they could entirely prevent non-AppStore, non-sandboxed applications from running on macOS. They haven't, but they could and indeed all signs point to these being on the very long-term roadmap. Does this mean you stop writing Mac apps today?
- gjsman-1000 4y ago
  You can always have a user right-click the app in Finder and choose “Open Anyway” with admin rights. Otherwise… that is kind of the point of Gatekeeper. If it was any easier, notarization would be pointless and ineffective.
lapcat 4y ago
(2021)
ris58h 4y ago
Why no homebrew though?
- Alifatisk 4y ago
  I think it’s supposed to be for another audience than super users
  - vehemenz 4y ago
    I agree, but in the sense that Mac super users understand the limitations of the App Store and would rather not wade through the crapware, poor search, and lack of selection due to the App Store's sandboxing policy. I don't think typing a few commands in the command line is really that much of an impediment to the average user—it's lack of awareness.
    - dev_tty01 4y ago
      Hmm. I really don't think you have interacted with many "average" users. Once I get out of my engineering circle, the number of people who would be comfortable interacting with the command line is extremely small. To the majority of modern computer users, even the concept of a terminal and typing commands is completely foreign, let alone navigating the file structure via the command line. And oh by the way, on the Mac at least, you also many have to teach them how to give the Terminal app Full Disk Access privileges.
      - smoldesu 4y ago
        Most Mac users I know are familiar with iTerm and it's basics, even if they don't really understand the shell. Makes sense too, it feels like 1-in-5 MacOS quirks I want to fix need a CLI command and a reboot.
        bookofjoe 4y ago
        I have NO IDEA what iTerm is nor do I know what a shell or CLI command are.
interleave 4y ago
> To distribute the app as a zip file, the process is simpler: pick the upload option from Xcode after selecting “Developer ID” and it’ll produce a notarized version of your app, which you can then zip up and distribute directly. While possible, I highly recommend going the extra mile of shipping a .dmg from the start if your app requires any extra permissions (file access, network, etc.) macOS turns out to be very, very hesitant to provide file access to apps that were downloaded as zips and will do so SILENTLY. I spent more than three weeks banging my head against this. Here's the full run-down with all the details: https://forum.obsidian.md/t/streamline-a-stream-of-consciousness-writer-for-obsidian/50108/18 https://forum.obsidian.md/t/streamline-a-stream-of-conscious... if you're interested.
- lapcat 4y ago
  I suspect you were just running into App Translocation AKA Gatekeeper Path Randomization.
  - interleave 4y ago
    Thank you, I appreciate your pointer! Based on your comment and mike_hearn's, Gatekeeper Path Randomization squatted in squarely my blind spot :)
- mike_hearn 4y ago
  Permissions aren't affected by zip vs dmg, they are assigned to bundle id+signing identity pairs I think, but if the user doesn't move the app out of the dmg or Downloads folder then it'll be run from a randomly generated read only mount. That is the main difference.
  - interleave 4y ago
    Thank you for clarifying! In every test, I copied the app to /Applications before starting it. For reproducibility, here are the exact steps I took, with .zip[^1] and .dmg[^2] respectively on a test machine: 1. Download the archive from github 2. Extract/mount the archive 3. Drag the app to /Applications 4. Open the app 5. Configure a specific file-path for indexing And here's the difference I observed: - Zip: Silent failing, no indexing of files, no exceptions, no errors, "app doesn't work" - Dmg: Files are indexed as intended, "app works" Is this what you would have expected as well? [1]: Streamline.zip from https://github.com/akaalias/getstreamline/releases/tag/v3.5.2 https://github.com/akaalias/getstreamline/releases/tag/v3.5.... [2]: Streamline.dmg from https://github.com/akaalias/getstreamline/releases/tag/v3.5.3 https://github.com/akaalias/getstreamline/releases/tag/v3.5....
rpastuszak 4y ago
Do you have any other resources regarding monetising the app outside of the App Store? I don't care too much about piracy and I don't want to handle any user data myself, if possible. --- PS. Thanks for posting this. I got stuck and, frankly, demotivated after spending a few days porting my app (https://enso.sonnet.io https://enso.sonnet.io) just to realise that I couldn't properly sign it for App Store distribution (took another 3 days of painful work with the AppStore Connect API). I know it sounds silly but learning that even someone like Guilherme would consider publishing paid apps without the App Store made me think that I might've lost track of the actual problem: putting the app in front of the users.
mike_hearn 4y ago
A great article! There's a few ways to distribute an app to Macs outside the app store, but if you're writing cross platform software then Conveyor [1] can be a helpful tool especially if you're new to desktop development. It can build, sign and notarize Mac apps from Linux or Windows + it understands Electron and JVM apps natively so if you use those the whole release process can be done from your dev laptop. We're adding Flutter next but Flutter apps require compilation on each target OS so you'd need to use a Mac or have Mac CI access in order to build the executables. A few misc thoughts: 1. Sparkle is a great update engine, Zorg is a very skilled and hard working developer. Conveyor integrates it into your app without needing any code changes so you can use it even if you aren't an Objective-C/Swift dev. 2. Skipping notarization. Conveyor can generate self signed apps along with a download.html page that tells users what to do, if you don't give it signing keys. The page repeats Apple's instructions for bypassing Gatekeeper via the UI (right click+open), and it also supplies a `curl|bash` script that does the same thing. It's free for open source apps and we have some users who use it to distribute self-signed apps via GitHub Releases with updates. You can also distribute CLI apps this way (without homebrew) but that feature isn't quite finished/documented yet, it's sort of pending launch until we understand how much demand there actually is. I personally think notarization is a reasonable balance that works better than the approaches taken by Windows and Linux, but there are cases where it's just getting in the way. One obvious case is internal tools that you're distributing to colleagues - in this situation personal developer ID might not be appropriate but the company may guard its actual signing keys with complex process. In those cases you already know the source of the app and don't need Apple's help staying safe. Self-signing (rather than being entirely unsigned) makes Apple Silicon Macs happy, and allows the OS to remember what permissions the app has across upgrades. 3. You don't need code signing certs for sign web apps (just TLS certs) because of the sandbox. I'm exploring the possibility of a new feature - signing using our keys for people/projects that can live inside an app sandbox. You'd upload the output of your build system and we'd then build, sign and host the resulting packages. If you control the packaging you control the entry point which means you can then drop arbitrary privileges before executing the real code, and it means you can force updates to occur if sandbox holes are found. The problem is that you're competing against the price of just buying keys, so it's a bit unclear how much demand there is from the non-open source users who would ultimately be paying for it. 4. Desktop distribution can be a somewhat mysterious/difficult topic for people new to it, especially all the signing stuff. Conveyor isn't open source for better or worse, but the flip side is that it comes with commercial support. In the past we've been able to help customers even with bugs in third party libraries that only showed up when an app was packaged, and only on macOS. [1] https://hydraulic.software/ https://hydraulic.software/ (disclosure notice: I wrote it and run the company)
iamcalledrob 4y ago
For me, updates for apps distributed outside the store have been a surprising hurdle. On the surface, "just bundle an update framework and be done, right?" Sparkle is great, but very complex--xml AppCasts, delta updates, fancy mukti-party signing etc... Not a workflow you can quickly set up. Squirrel (which Electron uses) is dead simple, but is absolutely ancient and basically unusable outside of Electron at this point. I seem to remember that the Electron project had some custom patches to keep it alive, but these weren't usable elsewhere. And with either of these, because it ships as part of your app you have to be very careful to never push a broken build. If you do, your users get terminally updated to a broken app that you can't update again. And never shipping a crashing build is easier said than done :) Are you really testing on every point release of the OS? Are you confident that you've tested all of the "magic" security behavior of macOS (the OS loves to insta-crash your app for these things) The inevitably of shipping a broken build is why big companies build update agents that run in the background and independently update (or roll back) the app, e.g. Dropbox. But to my knowledge none of these updaters are open source. Is the situation any better on Windows?
- saurik 4y ago
  It is at least somewhat better on Windows because you don't have anywhere near as much "magic security behavior" that "loves to insta-crash your app". That said, the de-facto standard of Sparkle doesn't exist on Windows, so it feels even more like utter chaos. (That said, I frankly have a hard time taking Sparkle seriously since they decided to drop support for old versions of macOS randomly.)
- mike_hearn 4y ago
  Yes it's a pain. I wrote Conveyor to automate it all - makes appcasts, signs, notarizes, uploads to the download site and all that for you (see my other comment for more info). "to my knowledge none of these updaters are open source." It's a bit better on other platforms. Omaha does this on Windows and is open source, but it's also abandoned. Google are rewriting it as Chromium Updater. Also Omaha's complexity makes Sparkle look like hello world. Conveyor makes MSIX packages for Windows and DEBs for Linux. MSIX is a bit like Omaha, there's a local agent that wakes up from time to time and updates apps on their behalf. There are bugs in it for older versions of Windows but Conveyor works around them. I wouldn't recommend trying to use it directly because it'll seem to work on your nice and up to date Windows but fail for people who aren't accepting online updates. However, when you get it stable, it's actually a really nice feature set. Sparkle has the ability to update apps independently, without being invoked by the app itself, via a command line tool. Currently Conveyor does invoke Sparkle from within the packaged app at startup as per usual, but moving to a dedicated background service would be a good improvement.
gumby 4y ago
When I have a choice I always download directly from the developer so that they get to keep the extra 30%. But for my aging parents, my kid when he was young etc I was glad the App Store was the default and that apple normally warns you the first time you run something downloaded. It helps stop drive by downloads.
- semireg 4y ago
  Or 15% if dev revenue is under 1,000,000 USD.
  - newaccount74 4y ago
    Alternatives to the App Store also cost between 6%-9% in fees, so for small devs the savings aren't as big anymore.

151 points by jb1991 4y ago

I'm interested in distributing Mac apps without any Apple involvement whatsoever. How do I bypass the notarization requirement? Can I use a shell script that would remove the quarantine attribute? As in, I'd put the script into my disk image and instruct the user to click it to install the app.

kybernetyk 4y ago
https://lapcatsoftware.com/articles/without-notarization.html https://lapcatsoftware.com/articles/without-notarization.htm... I don't know if this still works, but it used to be that when you right-click an app bundle in Finder and select "open" (as opposed to double clicking the bundle) you get an "open anyway" option in the OMG APPLE CORP JUST WANTS YOUR BEST warning dialog.
- pilif 4y ago
  Using this method requires admin rights though, but that’s probably for the better as running code of unknown provenance is probably a privilege of a machine’s owner
  - temac 4y ago
    Does the code then run with admin rights ?
    - lwkl 4y ago
      No this does the same as going into system settings and approve the binary after trying to open it the first time. This requires elevated privileges. After that you can run the app as a user.
newaccount74 4y ago
Shell scripts are affected by quarantine just like any other executable. The easiest solition is, as kybernetyk says, to right-click the app. If you do that, you can bypass most the warnings. Another possibility would be to install the app in a way that doesn't set the quarantine attribute, eg. with curl, rsync or brew cask. But Apple has been tightening seccurity year after year, so it's questionable how long all the workarounds will continue working. My recommendation would be to just notarize the app - Mac users expect notarized software, and if you tell users they need to bypass the security checks, then a lot of people will think you are sketchy.
- grishka 4y ago
  > My recommendation would be to just notarize the app The problem is that this involves having a developer ID, which costs $100/year — which is the one thing I'd like to avoid. Hence my question. The apps I'm contemplating about would be free and open-source so I won't be making any money on them.
  - jagged-chisel 4y ago
    Rhetorical questions: how much salary do you make on other work? How much have you spent on your hardware? Real question: why is $100/yr such an egregious amount of money? If it’s a matter of principle, perhaps targeting macOS also lies outside those principles.
    - zeta0134 4y ago
      This would have been a completely unattainable amount of money as a high school student. In college, that money was better spent on school supplies and food, and spending cash was short. After college it took me the better part of a decade to get to the point where $100/year felt like something I could feasibly consider spending and not risk missing rent in January. $100/year is a lot of money to people in a wide variety of life situations. Being unable to afford this does not make them any less of a programmer.
      - 4y ago
vbezhenar 4y ago
To remove all attributes, just ask user to run `xattr -c filename`. But I'm not sure if that would remove notarization requirement.
- 0ct4via 4y ago
  Non-technical end users won't want to be trying to enter Terminal commands they don't know or understand, and they shouldn't have to.
  - vbezhenar 4y ago
    How is it different from running shell scripts they don't understand (or entire applications for that matter)?
    - einherjae 4y ago
      It’s scarier, less ergonomic, and smells hacker-y. There is a significant difference between “just click on this”, and “open the DOS prompt and write these magical runes”
      - vbezhenar 4y ago
        It was observed that people get attached to Ikea furniture because they assembled it and it contains tiny bit of their labour. May be it could work with software? Like you've executed some scary command to enable this software to work, now you attached to it.
        0ct4via 4y ago
        That's not a fair comparison though -- if you screwdriver slips or you put the wrong screw in the hole, your sofa doesn't stop working -- but you could do real damage to your OS. IKEA furniture assembly involves very simple tasks and tools, and a guide that's purely pictorial -- and even then, there are an array of services where people will do that assembly for you, even offerings from IKEA themselves. Software neither has the same physical presence, nor the same relative lack of risk. The average person can appreciate something "made with their own hands," but lacks the specialist knowledge to appreciate a script or code deployment. Given how scared and how easily-scammed people can be by having someone open Event Viewer in Windows and claim this means their computer has viruses, opening some script and demanding verbatim typing of commands is more likely to lead to anxiety or unsureness than anything, and certainly not attachment. You're thinking as if the average person is the average HN reader -- they're not. At all.
ris58h 4y ago
Right-click, Open, Open should work for ad-hoc signed apps as others mentioned. I've made my very first MacOS app and users didn't complain installing it. It's https://github.com/ris58h/Touch-Tab https://github.com/ris58h/Touch-Tab BTW.
sbuk 4y ago
> How do I bypass the notarization requirement? Why? As a software user I want you to notarise your software.
- ris58h 4y ago
  As a FOSS developer I wish I could notarize it without paying $100/year to Apple.
  - sbuk 4y ago
    You'd need a separate certificate, which at the moment will cost considerably more than $100. Also is your objection the $100 or merely paying Apple?
    - samoit 4y ago
      Having to notarize your own software is giving one company total control over you and your future. It is unacceptable. I do not develop versions for macosx since notarization anymore.
      - oleks637 4y ago
        This is probably my biggest fear. One day Apple can revoke my certificate, and suddenly my apps stop working for everyone.
        ryandrake 4y ago
        But this has not happened. You're basing a decision today on something that might or might not happen in the future. "One day," Apple could do anything. One day, they could totally prevent installing things that are not notarized. One day, they could entirely prevent non-AppStore, non-sandboxed applications from running on macOS. They haven't, but they could and indeed all signs point to these being on the very long-term roadmap. Does this mean you stop writing Mac apps today?
gjsman-1000 4y ago
You can always have a user right-click the app in Finder and choose “Open Anyway” with admin rights. Otherwise… that is kind of the point of Gatekeeper. If it was any easier, notarization would be pointless and ineffective.

lapcat 4y ago

(2021)

ris58h 4y ago

Why no homebrew though?

Alifatisk 4y ago
I think it’s supposed to be for another audience than super users
- vehemenz 4y ago
  I agree, but in the sense that Mac super users understand the limitations of the App Store and would rather not wade through the crapware, poor search, and lack of selection due to the App Store's sandboxing policy. I don't think typing a few commands in the command line is really that much of an impediment to the average user—it's lack of awareness.
  - dev_tty01 4y ago
    Hmm. I really don't think you have interacted with many "average" users. Once I get out of my engineering circle, the number of people who would be comfortable interacting with the command line is extremely small. To the majority of modern computer users, even the concept of a terminal and typing commands is completely foreign, let alone navigating the file structure via the command line. And oh by the way, on the Mac at least, you also many have to teach them how to give the Terminal app Full Disk Access privileges.
    - smoldesu 4y ago
      Most Mac users I know are familiar with iTerm and it's basics, even if they don't really understand the shell. Makes sense too, it feels like 1-in-5 MacOS quirks I want to fix need a CLI command and a reboot.
      - bookofjoe 4y ago
        I have NO IDEA what iTerm is nor do I know what a shell or CLI command are.

interleave 4y ago

> To distribute the app as a zip file, the process is simpler: pick the upload option from Xcode after selecting “Developer ID” and it’ll produce a notarized version of your app, which you can then zip up and distribute directly. While possible, I highly recommend going the extra mile of shipping a .dmg from the start if your app requires any extra permissions (file access, network, etc.) macOS turns out to be very, very hesitant to provide file access to apps that were downloaded as zips and will do so SILENTLY. I spent more than three weeks banging my head against this. Here's the full run-down with all the details: https://forum.obsidian.md/t/streamline-a-stream-of-consciousness-writer-for-obsidian/50108/18 https://forum.obsidian.md/t/streamline-a-stream-of-conscious... if you're interested.

lapcat 4y ago
I suspect you were just running into App Translocation AKA Gatekeeper Path Randomization.
- interleave 4y ago
  Thank you, I appreciate your pointer! Based on your comment and mike_hearn's, Gatekeeper Path Randomization squatted in squarely my blind spot :)
mike_hearn 4y ago
Permissions aren't affected by zip vs dmg, they are assigned to bundle id+signing identity pairs I think, but if the user doesn't move the app out of the dmg or Downloads folder then it'll be run from a randomly generated read only mount. That is the main difference.
- interleave 4y ago
  Thank you for clarifying! In every test, I copied the app to /Applications before starting it. For reproducibility, here are the exact steps I took, with .zip[^1] and .dmg[^2] respectively on a test machine: 1. Download the archive from github 2. Extract/mount the archive 3. Drag the app to /Applications 4. Open the app 5. Configure a specific file-path for indexing And here's the difference I observed: - Zip: Silent failing, no indexing of files, no exceptions, no errors, "app doesn't work" - Dmg: Files are indexed as intended, "app works" Is this what you would have expected as well? [1]: Streamline.zip from https://github.com/akaalias/getstreamline/releases/tag/v3.5.2 https://github.com/akaalias/getstreamline/releases/tag/v3.5.... [2]: Streamline.dmg from https://github.com/akaalias/getstreamline/releases/tag/v3.5.3 https://github.com/akaalias/getstreamline/releases/tag/v3.5....

rpastuszak 4y ago

Do you have any other resources regarding monetising the app outside of the App Store? I don't care too much about piracy and I don't want to handle any user data myself, if possible. --- PS. Thanks for posting this. I got stuck and, frankly, demotivated after spending a few days porting my app (https://enso.sonnet.io https://enso.sonnet.io) just to realise that I couldn't properly sign it for App Store distribution (took another 3 days of painful work with the AppStore Connect API). I know it sounds silly but learning that even someone like Guilherme would consider publishing paid apps without the App Store made me think that I might've lost track of the actual problem: putting the app in front of the users.

mike_hearn 4y ago

A great article! There's a few ways to distribute an app to Macs outside the app store, but if you're writing cross platform software then Conveyor [1] can be a helpful tool especially if you're new to desktop development. It can build, sign and notarize Mac apps from Linux or Windows + it understands Electron and JVM apps natively so if you use those the whole release process can be done from your dev laptop. We're adding Flutter next but Flutter apps require compilation on each target OS so you'd need to use a Mac or have Mac CI access in order to build the executables. A few misc thoughts: 1. Sparkle is a great update engine, Zorg is a very skilled and hard working developer. Conveyor integrates it into your app without needing any code changes so you can use it even if you aren't an Objective-C/Swift dev. 2. Skipping notarization. Conveyor can generate self signed apps along with a download.html page that tells users what to do, if you don't give it signing keys. The page repeats Apple's instructions for bypassing Gatekeeper via the UI (right click+open), and it also supplies a `curl|bash` script that does the same thing. It's free for open source apps and we have some users who use it to distribute self-signed apps via GitHub Releases with updates. You can also distribute CLI apps this way (without homebrew) but that feature isn't quite finished/documented yet, it's sort of pending launch until we understand how much demand there actually is. I personally think notarization is a reasonable balance that works better than the approaches taken by Windows and Linux, but there are cases where it's just getting in the way. One obvious case is internal tools that you're distributing to colleagues - in this situation personal developer ID might not be appropriate but the company may guard its actual signing keys with complex process. In those cases you already know the source of the app and don't need Apple's help staying safe. Self-signing (rather than being entirely unsigned) makes Apple Silicon Macs happy, and allows the OS to remember what permissions the app has across upgrades. 3. You don't need code signing certs for sign web apps (just TLS certs) because of the sandbox. I'm exploring the possibility of a new feature - signing using our keys for people/projects that can live inside an app sandbox. You'd upload the output of your build system and we'd then build, sign and host the resulting packages. If you control the packaging you control the entry point which means you can then drop arbitrary privileges before executing the real code, and it means you can force updates to occur if sandbox holes are found. The problem is that you're competing against the price of just buying keys, so it's a bit unclear how much demand there is from the non-open source users who would ultimately be paying for it. 4. Desktop distribution can be a somewhat mysterious/difficult topic for people new to it, especially all the signing stuff. Conveyor isn't open source for better or worse, but the flip side is that it comes with commercial support. In the past we've been able to help customers even with bugs in third party libraries that only showed up when an app was packaged, and only on macOS. [1] https://hydraulic.software/ https://hydraulic.software/ (disclosure notice: I wrote it and run the company)

iamcalledrob 4y ago

For me, updates for apps distributed outside the store have been a surprising hurdle. On the surface, "just bundle an update framework and be done, right?" Sparkle is great, but very complex--xml AppCasts, delta updates, fancy mukti-party signing etc... Not a workflow you can quickly set up. Squirrel (which Electron uses) is dead simple, but is absolutely ancient and basically unusable outside of Electron at this point. I seem to remember that the Electron project had some custom patches to keep it alive, but these weren't usable elsewhere. And with either of these, because it ships as part of your app you have to be very careful to never push a broken build. If you do, your users get terminally updated to a broken app that you can't update again. And never shipping a crashing build is easier said than done :) Are you really testing on every point release of the OS? Are you confident that you've tested all of the "magic" security behavior of macOS (the OS loves to insta-crash your app for these things) The inevitably of shipping a broken build is why big companies build update agents that run in the background and independently update (or roll back) the app, e.g. Dropbox. But to my knowledge none of these updaters are open source. Is the situation any better on Windows?

saurik 4y ago
It is at least somewhat better on Windows because you don't have anywhere near as much "magic security behavior" that "loves to insta-crash your app". That said, the de-facto standard of Sparkle doesn't exist on Windows, so it feels even more like utter chaos. (That said, I frankly have a hard time taking Sparkle seriously since they decided to drop support for old versions of macOS randomly.)
mike_hearn 4y ago
Yes it's a pain. I wrote Conveyor to automate it all - makes appcasts, signs, notarizes, uploads to the download site and all that for you (see my other comment for more info). "to my knowledge none of these updaters are open source." It's a bit better on other platforms. Omaha does this on Windows and is open source, but it's also abandoned. Google are rewriting it as Chromium Updater. Also Omaha's complexity makes Sparkle look like hello world. Conveyor makes MSIX packages for Windows and DEBs for Linux. MSIX is a bit like Omaha, there's a local agent that wakes up from time to time and updates apps on their behalf. There are bugs in it for older versions of Windows but Conveyor works around them. I wouldn't recommend trying to use it directly because it'll seem to work on your nice and up to date Windows but fail for people who aren't accepting online updates. However, when you get it stable, it's actually a really nice feature set. Sparkle has the ability to update apps independently, without being invoked by the app itself, via a command line tool. Currently Conveyor does invoke Sparkle from within the packaged app at startup as per usual, but moving to a dedicated background service would be a good improvement.

gumby 4y ago

When I have a choice I always download directly from the developer so that they get to keep the extra 30%. But for my aging parents, my kid when he was young etc I was glad the App Store was the default and that apple normally warns you the first time you run something downloaded. It helps stop drive by downloads.

semireg 4y ago
Or 15% if dev revenue is under 1,000,000 USD.
- newaccount74 4y ago
  Alternatives to the App Store also cost between 6%-9% in fees, so for small devs the savings aren't as big anymore.