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.
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.
Would it make sense to distribute two separate apps, the main app and an updater app, so that both would have to break in order for users to lose the ability to update? I'm thinking users would download the main app, which would download the updater, which would run in the background and keep the main app updated. Since the updater app would run independently a broken main app wouldn't prevent future updates unless it also broke the updater app somehow.
Absolutely, but building this sort of thing is easier said than done, especially when it comes to security and sandboxing. This is one of the wonderful things about Sparkle—this stuff has been battle tested.
They've done the work of finding which APIs actually work and handling all the edge cases. <rant> macOS's APIs in this area are a woeful mess of "deprecated, but the new APIs don't actually work". Sometimes the only way of reliably doing something is using Applescript... https://mjtsai.com/blog/2020/04/20/privileged-operations-on-... </rant>
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.)
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.
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.
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
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.
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.
> 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.
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.
Was it a subscription service, though? That doesn't seem like a terrible deal if you get a perpetual license - meanwhile forking over $99/year for some basic functionality wrapped in Service Credit seems like a racket to me.
Who says the HS student is buying the hardware themselves? It could have been a gift, a hand-me-down, a school computer, etc. As a HS student I was poor as shit, no allowance and lived in a rural area where getting a part-time job would require a car and all the expense with that.
They didn't say they wanted to sell the app, just sign and distribute it. Maybe they want to put their FOSS project on the App Store, but can't until they get a "real job" first.
Plus I have known many offshore colleagues from African and Asian countries that managed to be successful in selling software, despite the conditions they were raised in.
So painting the Apple story as gate keeping is playing it short, there are many ways to skin a rabbit.
You'll need the App Store if you want it on iPhone, which means you need to pay the subscription.
I'm not going to sit around all day and play pity-party with you about impoverished developers. I've known my fair share too, and I might even be one depending on your definition of poor living conditions. The point is simple: Apple stops people from doing arbitrary stuff for no reason. Perhaps you don't care; I'm not arguing that. Maybe it doesn't stop people from getting rich; obviously, money is still made. Regardless, everyone knows their deal stinks like shit - the cat's out of the bag. Apple bought themselves a couple months with the 15% punch-line, but the laughing stops next year.
This isn't controversial or high-concept stuff. You should be able to freely install stuff on your iPhone even if you don't personally intend to. It seems like by-and-large, the democratic world agrees.
Customers can only validate it if they have a choice. How does an iPhone developer validate or invalidate Apple's behavior? They're basically a hostage on Apple's platform, and the only thing keeping them there is the fact that they get paid. Apple shouldn't have the negotiating power they wield, and regulators are taking action to stop them from abusing it.
App developers are not the "customer" of these curated store platforms any more than cereal manufacturers are the "customer" of a grocery store.
If you try to take your business elsewhere, you have no market, because no one else is able to create a store which targets the same market. This is entirely unlike a grocery store, because if Safeway is unreasonable you can launch an entire store just for your own products and people can shop at both.
However, with these curated store platforms, a user can only use the App Store. They can get a different phone--at ridiculous expense, as there are numerous anticompetitive lock-in mechanisms with respect to licenses that prevent this: I would, for example, lose access to all of the music and books and apps I've ever bought--but then they aren't able to use the App Store anymore.
The problem is that virtually all sane people only carry around a single phone. This is not true of grocery stores or frankly any other form of store unless you map the analogy to geographic regions, where people have to move to a new house in a different community--at great difficulty and expense--to get to another grocery store. Even if you only have a monopoly over one "small" region, that's still a monopoly.
This is not really the case for mass market consumer goods (like the cereal example in your post). Safeway and Kroger are a duopoly not far off of Apple’s app store monopoly and if you don’t like their terms, there aren’t exactly alternative viable channels for your cereal.
I get what you're saying, but I think the fact that convenience stores are anything but a monopoly just further illustrates how disparate Apple's authority is here. The power Apple wields is like if there was one cereal store, and if you didn't like the selection they had then you "just find another breakfast food". It doesn't, and shouldn't have to be a binary choice.
You don't have that choice if you're building a service that relies on having a mobile app. You are required to have presence on iOS if you want any semblance of success.
I'm the one who pushed the discussion onto the tangentially-related Apple mobile platform, guilty as charged.
Do you want to defend Apple's absolute control over the iPhone in front of God, Saurik and everyone, or admit that the world's richest company operates out of greed sometimes?
Greed? No. Profit motivated. Of course. They are a business. Businesses generally exist to make a profit. The more profit they make, the stronger and more resilient they become. Apple, having been very close to bankruptcy a couple of times means that they have a strong motivation to make a profit. Nothing is without reason, whether or not you like the reason. I guess corporate greed is a thing, but then so are the very real costs of operating services. Ranting about a business being successful or being the wealthiest just smacks of petty anti-capitalist jealousy. I get it, Apple were supposed to fail and they didn’t.
Are Apple’s fees worth 15%[1] of the vendors revenue? Possibly not, though as a provider, they are entitled to make a profit.
[1] Yes, yes; 30% if the vendor make > $1,000,000. Let get real, the significant majority of the app that you are arguing about are likely to be grossing less than that. And of course 15% of $0 is $0, so the argument is completely moot for freely distributed apps.
> Possibly not, though as a provider, they are entitled to make a profit.
The big thing people seem to disagree with is Apple forcing themselves to be a provider (and thereby forcing their entitlement to a profit). Apple is certainly entitled to compensation when people use their service, but no computer should force it's services on the user. Regulators seem to really hate that bit, and it will be interesting to see how Apple responds to the Digital Markets act.
Did GP claim to be on Apple Silicon? No? Stop assuming.
That aside, if GP did run an Apple Silicon machine, there's also the market to buy used, and buy lower-spec models like the base-spec Mac Mini or MacBook Air.
Once again, these aren't $3000 machines, and you don't know whether the machine they use was gifted, loaned, used, a work machine, etc. -- although the decided choice by their own admission, and their profile, suggests cost wasn't a factor for them.
Do you have a point, or are you just looking to argue? The response was in your incredulous "Yet you can afford to buy a Mac?" accusation to GP -- which is loaded with baseless assumptions. I reasonably pointed out any ways someone could own a Mac without significant or any cost to themselves. Nobody said anything about it being the most modern or powerful machine, all GP said was that they want to create FOSS apps for Mac, and didn't agree with paying the $99/yr Developer program fee for signing apps as an "authorised developer."
McDonalds pays you in compensation for actual physical labor. You pay Apple to flip an arbitrary bit on your iCloud account that enables features that should be enabled by-default on devices you bought and paid-for.
Bit of a difference there, perhaps something worth being upset about.
That has nothing to do with the fact that $100 is affordable to the average college student working at a fast food company.
But even if I buy your argument, are you saying that selling software also has no value since once you write it, the marginal cost of delivering software is basically $0
Distributing software has zero cost. Apple can bundle services with it (vuln scanning, CI/CD, cloud resources, etc.) but copying data is inherently a free process. You may object to that all you wish, but the entirety of the internet stands as evidence that software distribution is normalized and free.
The problem was never that Apple wanted to offer cloud resources or scan for known exploits. Go wild, Microsoft does that too and it works great for them. People are only mad when Apple conflates completely arbitrary capabilities with their $99 dev service fee. I should not need a recurring subscription to install an App from Github. We're not in 2005 anymore, we're done selling feature phones.
The fee isn't unreasonable. The things they block off is. Until Apple lets me install an IPA file as easily as something from the App Store, I will mercilessly mock them for extorting the very developers that make them rich. The closing noose is why I left MacOS, and the reason why I could never daily-drive iOS. It's dumb, and anti-consumer.
I'll happily answer any further questions, but I'm afraid my opinion isn't as interesting as you think it is.
I'm replying to the parent, who was talking about selling and distributing iPhone apps. Moreover, this discussion started with me highlighting which things should be in the subscription (CI/CD time, VPSes, direct support) versus things that shouldn't be in it (freely managing arbitrary software). Conflating the iPhone's capabilities with the developer program is Apple's fault, not mine.
Most people aren't "mad" about this -- and in this case, GP is complaining that they simply don't want to, not that they can't afford it or anything. There are also fee waivers available for registered non-profits, those in education etc. -- so it's not as binary as you're making out.
You also don't need any subscription to install any macOS app, but without it being signed by a developer, you have to -- le gasp -- control-click or right-click, and accept the warning that the developer is unverified. Hardly a massive tax on end users.
So once software is made, delivering it to the customer is just “delivering data”. Do you think that all software should be free and people shouldn’t charge for software?
All software is free. I have 4 versions of MacOS archived on my disk right now, and you can get your own copies on the internet archive. Want to pirate Mac software? Go get it, nobody will stop you. The only price that everyone pays on the internet, is free.
Every platform that respects the freedom and authority of it's users seems to agree that all software is free. As Apple is an American company, it would make me very happy to see them agree with those values.
It's not that I can't afford $100/year. I simply don't like Apple's security model where they consider themselves an unquestionably trusted party. I also don't want these kinds of dependencies. It's more like an act of protest.
I'm targeting macOS because that's the OS I use. I use it because the two alternatives suck a lot more. Modern Mac hardware is also really nice and a joy to use. The integration of software and hardware is unmatched by any competition.
If you think Apple sucks look at signing binaries on Windows. If you don‘t use the Microsoft App Store it‘s much more expensive and annoying.
It basically requires you to be incorporated and hire a notary so you‘re probably spending $ 1000 or more for the first year. Renewal is cheaper but you will still be paying at least $ 100 a year.
Also if you know a good affordable way for a code signing certificate on Windows answer to this comment. I gave up the last time I tried.
If your ID has your address printed on it, then you are lucky and can just take a photo of the ID and yourself holding the ID. If you don't, then you need to go to a notary and sign a special form provided by Sectigo.
Sectigo doesn't even need to call you anymore, as it was about 5-10 years ago.
The downside of the OV certificate is that Windows Defender will show a blue pop-up saying that your app might put the user's PC at risk. Good thing is that it will eventually go away after some time. For my app it took about a year.
> If your ID has your address printed on it, then you are lucky and can just take a photo of the ID and yourself holding the ID. If you don't, then you need to go to a notary and sign a special form provided by Sectigo.
That's the problem ID's don't have addresses printed on them in most European countries. So you have to get a notary and this is really expensive. There is a system to proof your place of residence here without a notary but these companies don't accept them.
Maybe it’s just me, but I would never go through a random certificate authority like “K Software”. Users are not cryptographically verifying the developer’s signing identity, they are trusting KSoftware’s attestation that the signed binary is authentic.
Last time I looked they had the best pricing I could find at about $70/year. However, you still have to jump through the antiquated hoops for them to validate your business. One of the hoops was something like "have a business address and phone number listed in a commercial directory" which was particularly tricky to do for us since we don't have a company office anywhere and don't have a company phone number. In 2022, it should be reasonable for a software company to exist without a published phone number. I think we got around that by setting up a Twilio or Google Voice number and then adding a business listing in Google to one of our owner's residential addresses. Totally useless but apparently good enough to pass validation.
Uh.... what? Unless something drastically changed in the last couple weeks Windows does not go out of it's way to prevent you from running executables unless they are cryptographically signed by Windows.
There's no reason to do windows code signing unless you're writing a hardware driver(?).
Try downloading and running an unsigned exe using Edge. I'm not a fan of the term "dark pattern" as it gets overused, but the UI design in those flows is pretty much the definition of the term. You can bypass the warnings and run the program but it makes Apple's magic right click look intuitive.
If you use it and want to develop for it, you can't really whine about how they do things and want to do things differently as an "act of protest" -- you either pay the money to do it their way -- which massively reduces the amount of trash apps on the App Store, and helps increase user trust compared to random apps being able to open and do what they want without warning -- or you accept your potential users won't have that simplicity.
If you love the hardware and the integration, and have the money, what exactly is your issue? -- if you were about FLOSS more than anything you wouldn't be pushing the proprietary platform stuff to begin with, and if you don't like the "walled garden" approach you shouldn't be using Apple ¯\_(ツ)_/¯
The same things apply to the Microsoft Store for apps, and similar (but to a much lesser degree) for the likes of the Ubuntu Software Center. It's about trust, ease of use, and having apps and updates all handleable from one location.
If you're distributing the app yourself, outwith the App Store, you don't have any of those "dependencies" -- and if your complaint is paying to have your code signed properly as a dev, that's the same across macOS and Windows, in a similar vein to SSL certs for websites. Sure, you can work without it, but you're going to alienate and scare some users by doing so.
> if you don't like the "walled garden" approach you shouldn't be using Apple
But I use none of Apple's online services. Not even the app store. App store for me is the place to update Apple apps, and that's really it.
> and if your complaint is paying to have your code signed properly as a dev, that's the same across macOS and Windows,
Windows? I know you can sign Windows executables, but why would anyone want to? I have Windows 11 on a VM. It runs unsigned executables just fine and, unlike macOS, doesn't treat them like they're radioactive. You just get a differently-colored confirmation window if you run them as administrator.
> in a similar vein to SSL certs for websites
And before Let's Encrypt and other similar free automatic CAs came along, SSL/TLS was very niche.
See, it's about choice. If you want to throw your money away for some reason, sure you can still pay for an SSL certificate. Or you can use Let's Encrypt for free, set it up once and forget. Your users would see a lock icon either way. No such luck with macOS app signing — Apple is your only option.
I like Android's security model better. You sign your apk with a self-signed certificate. No signing identity is enforced upon initial installation, but if you release an update, the new apk has to be signed with the same certificate. You can install an apk with the same package id but a different signature only after you uninstall the previous one (and delete all its private data). This helps with security and data integrity. I see no reason why Apple couldn't adopt a similar scheme on their platforms, except that they want all control they could get away with.
> Windows? I know you can sign Windows executables, but why would anyone want to? I have Windows 11 on a VM. It runs unsigned executables just fine and, unlike macOS, doesn't treat them like they're radioactive. You just get a differently-colored confirmation window if you run them as administrator.
It ought to! I'd love to see this in Linux and the BSD's too. Signing applications and binaries should be the norm.
> And before Let's Encrypt and other similar free automatic CAs came along, SSL/TLS was very niche.
Let's Encrypt came about to help with security. Happy to hear arguments pro a similar service for application signing, but it will have to follow similar, or tighter restrictions and you'd still be at the whim of third party.
> I like Android's security model better. You sign your apk with a self-signed certificate.
That is most definitely not a security policy. Self-signing is no different to not signing at all. There is no provenance, no chain-of-trust.
We should've probably started with the fact that I despise security policies based on provenance, chains of trust, public key infrastructure, and third parties. This kind of "security" feels extremely fragile and unnecessarily centralized. We somehow live with how SSH identifies servers by their keys, with no third-party verification, and consider that an okay level of security. Why can't we use the same approach for TLS and for executable signatures? What's so fundamentally different that third parties are required in these cases?
SSH doesn’t rely on PKI. Using SSH certificates is a password replacement for accessing remote services. While it is a kind of identity verification, its purpose is not the same an application signing.
Self signing is open to too much abuse. The whole point of signing is that the provenance can be verified (yes, checksums are a thing) and that the signing can be revoked should something bad happen. Notarising code is the process of a third party verifying your identity. So rather than saying, “hey, you can trust me”, you are asking a third party to vet and prove that you are trustworthy. If you can’t see the value in that for all parties - including the most important party, your customers - then that’s up to you. No sane SOC will allow unsigned or self-signed binaries. Consumers with the slightest bit of savvy will not run unsigned or self-signed binaries, and OS vendors need to take care of the rest. Thinking of the Confidentiality, Integrity and Availability triad, your solution is unworkable.
Everyone used to run unsigned binaries all the time for the entire previous history of computing and somehow the hell didn't break loose. What changed?
> Consumers with the slightest bit of savvy will not run unsigned or self-signed binaries
I'm a "consumer with the slightest bit of savvy" and I despise code signing schemes that care about the signing identity, so you're already wrong. I absolutely will run unsigned and self-signed binaries. I trust myself and my own judgement more than I do anyone else in the entire universe.
$100 a year means that no one makes applications for Mac OS on a whim, etc and it ensures that all the applications come from a purely profit-motive driven persons. It commercializes the entire OS and prevents software for people, instead of software for profit, from even existing in the ecosystem.
It can be an "egregious" amount to those in a variety of circumstances -- developing countries, students, those without employment, or living paycheck-to-paycheck as is... not everyone who is or wants to be a dev is making tens/hundreds of thousands of bucks per year.
GP says they're "Ex VKontakte, Telegram" in their profile though, which would imply they've made some money at least... and their comments read as more of an unwillingness to pay the $99, not an inability to do so ¯\_(ツ)_/¯
Sucks for non-commercial work though. Not every app is intended to make money, but as I understand it all have to pay. 100 USD a year is quite an expensive hobby.
Is it? In the grand scheme of things, I would argue not. My partner, for instance, knits. Cheap hobby, right? Nope. Specialist needles, yarn, etc. all adds up. She certainly spends more than $100 per year on it. How about photography? Or fishing? Most arts and craft type hobbies? You get the picture...
You’ll notice I made no argument in defense of Apple. You can definitely develop for their desktop OS without paying that $100 fee. If you don’t want to use all the free languages out there that will run on many platforms (macOS included), and you’d rather use Apple’s tools to build natively, well now you have to spend money on Apple hardware.
If you need an argument in defense of paying $100/yr for a signing certificate: it’s definitely a barrier to entry. It makes high volume scams based on obtaining signing keys too expensive. If it were free for all, it would be a free-for-all for scammers … until the world asked Apple to “do something about it” and that something would be charging for access to those certs.
$100 is cheap. Getting an Extended Validation code signing certificate to accomplish the equivalent goal on Windows (having no scary security dialog box when users download and open your program) costs even more.
A $100 developer account from Apple allows you to sign software so that there will be no scary dialog boxes when a user downloads your software off the internet and opens it.
An ~$100 code signing certificate for use on Windows will allow you to digitally sign your Windows application, but users will still see a scary dialog box from Windows SmartScreen when they download your software unless you spend a good bit more to step up to an Extended Validation certificate.
If you don't want to pay, you'll just have to accept that users are going to see a scary dialog box, and take care to warn them that it will happen on your website.
If you want to distribute FLOSS apps without cost, do so on platforms that support it, or look at how jailbroken iDevices can have apps side loaded.
If you want to distribute Mac apps you don't need a Developer ID. You can literally control-click (or right-click) the app and click Open, and you'll be given a warning asking if you're sure, as it's from an unidentified developer -- simple.
It's not a "problem" -- it's a choice.
If you want to distribute Mac apps without having to have an FAQ about Gatekeeper, suck it up and pay the $99.
I’m in this situation too, having to pay to be able to distribute macOS binaries of VICE. Quite annoying. I wish they’d make exceptions for open source.
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.
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?
In fairness it happened then unhappened due to a mistake. I think people are more worried about the sort of semi-arbitrary decision making associated with the App Store. But, to their credit, the macOS team have never used Gatekeeper that way. It's been >10 years that I've been reading predictions that they will, but they never did. That must count for something.
My app uses private API so it can't be distributed via AppStore due to Apple's policy. So in my case I would pay only for certificate and no other benefits.
I've already spent tens of hours of my life developing the app and I don't want to add $100 payment every year to it.
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.
The shell script is abstracted, and can hide a lot of the ugliness to the average user, whereas “type this into your terminal” goes full arcane black magic to the average user. But any opening of a terminal means we’re not in Kansas any more, and can’t be relied upon for any average user flow.
The average user shouldn't need to delve into the command line -- whether it's macOS, Windows, Ubuntu (for example), whatever -- that's the whole point of a GUI.
System Software (later Mac OS, for Mac OS 7.6 through Mac OS 9) didn't have a command line interface available. That did Apple pretty well from 1984 to 2001.
Mac OS X (and later OS X, then macOS) obviously have the Terminal app, but it is neither a requirement nor in common usage for the average desktop user.
Maybe don't be so classist and reductive? Not everyone hangs out on HN and uses terminal emulators regularly...
I've been hanging out on and enjoying HN daily for many years and I STILL have NO IDEA what a Terminal app or command line is — nor will I ever try to find out.
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) 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.
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.
As far as I have seen, installing UI apps via homebrew still occasionally pops up the usual scare dialogs if the app isn't properly signed and notarized.
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.
I don't know what the average user of your target audience is, but I've interacted with more people that thought their internet was broken because their homepage got a new lick of paint than I've interacted with people who could open up a terminal and copy/paste a command.
Making people follow a step-by-step guide is already a challenge on its own. Manuals are discarded because people consider themselves too good to need to read them, even if they have no idea what they're doing.
If you distribute your code in a way that's harder than clicking on a file and maybe dragging it into a folder, you're going to leave users stranded.
These days almost everyone may have a computer or tablet, but the average computer literacy hasn't gone up since the 90s. Especially on platforms like Apple's, which tries its hardest to hide away difficult concepts like "files" and "directories", you're going to need to babyproof your software for the average audience.
Now, if your target audience has a higher than average technical skill (programmers etc.) then you can get away with curl|bash no problem. Even still, I've had to help full-time developers on Windows open a command prompt several times because it's just not what they'll use in their normal day job, so even curl|bash may be too much to ask for some people in a strictly technical target audience!
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.
Possibly, but you may be underestimating the degree to which the App Store hampers the average user from getting the applications they need. Users think it's easy to use, yes, but they don't know enough to know better.
Homebrew's search is better, and there are more applications available. Many applications aren't on the App Store at all, so one needs to Google and download possibly unnotarized .dmg archives. Surely this is no easier than Homebrew.
It's not hampering though, the "average user" can often get apps from elsewhere. Mainstream companies offer binaries available from their websites (Chrome, Slack, etc.) that don't require the App Store at all -- but most will have a signed Developer ID too (among other reasons) prevent the Gatekeeper bypass being needed.
Homebrew's search isn't better if the average user isn't familiar with or used to the command line.
The "possible unnotarized .dmg archives" is a straw man and distracts from the main point -- GP just doesn't want to spend the $99/year.
You've now got multiple people stating that your understanding of view of the average user seems substantially skewed, maybe it's worth taking a look at that.
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.
I disagree. You will find this hard to believe but I have never used the app launcher or Spotlight. Full disclosure: I bought my first Mac in 1988 (Macintosh SE) for my then 5-year-old daughter and have used Macs ever since.
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.
> 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.
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.
Are you definitely sure about that? I'm not trying to be awkward but the binaries are actually different - they have differently sized text sections, one has an extra undefined symbol, relocations are different and their disassembly is substantially different too.
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?