Mac has always been different from its close cousin iOS, especially in terms of what the user can and cannot run on their system. Even after the advent of Apple Silicon, Apple made it clear that the Mac is still a Mac and can still be hacked , even when running on a new architecture.
For programmers, this means that when developing for the Mac platform, we have a choice: we can distribute applications independently, outside the Mac App Store, only through the Mac App Store, or a combination of both.
This article is the result of my thoughts on this topic. It was intended to be a guide to the things to know when distributing Mac apps outside of the App Store, rather than a detailed description of specific steps. I hope that the information presented here will help newbies take the mystery out of this process, and that my own process description will be helpful as a reference point.
App Store and direct distribution: pros and cons
All of these options have their own advantages and disadvantages. To begin with, some Mac applications simply cannot be distributed through the Mac App Store. An example of this is my AirBuddy app , which needs to run a system agent and use private APIs to enable deep integration with Apple wireless devices, which is prohibited in the App Store. The same is true for many other kinds of applications that simply cannot work under the constraints of the Mac's sandbox.
For those with a choice, I've compiled a list of the pros and cons of releasing on the Mac App Store or independent distribution.
Pros of the Mac App Store
- Apple distributes, sells, and licenses for you.
- .
- Apple .
- , Apple, , Mac App Store
Mac App Store
- ,
- macOS , , «», API .
- .
- -, App Store
- , Apple App Store
- , ( , )
- (consumable) (non-consumable) ( StoreKit)
- Apple, , Apple ( , , CloudKit, )
Catalyst SwiftUI
Catalyst has brought a slew of new Mac apps because it's much easier to take an off-the-shelf iPad app and port it to the Mac. Applications ported to macOS via Catalyst do not need to be released on the App Store, even if the original for iOS is there.
In addition, there is currently no TestFlight for macOS (one of my wishes for 2021), so if you want to distribute beta builds of an app created by Catalyst, then this must be done outside the Mac App Store, and this is not much different from distribution of the application in production.
Much of what is described in this article applies to Catalyst applications - after all, these are Mac applications, but some applications will require additional hacking - Apple prevents all AppKit features from being used directly from a Catalyst application. However, with a little work, you can get the Catalyst application to use many of the Mac's features, including AppleScript support and other features.
When developing SwiftUI applications for Mac, there should be no major differences in the distribution process, because in a SwiftUI application, we can use all the macOS API functions without the hacks required for Catalyst applications.
Spread
Distribution of an application has two aspects: downloading, saving and downloading the application binary and its updates, and creating a package that will work for your users.
Hosting
The first big step in getting your Mac app into the hands of non-App Store users is choosing how to distribute its binary. The lack of an App Store means you'll have to host the app binaries and updates somewhere on the Internet, giving users a download link.
This can be accomplished in many different ways. For an open source application, you can use releases on Github and even host an update feed of the application in a Github repository. This is how I distribute the WWDC app for macOS .
For commercial apps, I used Backblaze B2 to store app binaries, delta updates and update feed, proxying all requests through Cloudflareso that I have my own domain for download / updates, and also add filtering, caching and logic to the server if necessary.
B2 is an extremely affordable provider (I rarely pay more than $ 1 a month). Most Mac apps are small, so even if your app is heavily downloaded, it's unlikely that you will have to pay a lot for storage / bandwidth. Amazon S3 buckets are another popular option, but its dashboard terrifies me, so I prefer B2, which is much simpler (and cheaper).
So far I have not automated the stage of publishing the releases of my applications, so I just use Transmit to download a new release. as a client for my B2 buckets. By the way, before we get to uploading the release to the server, there is one more important step: getting the required file to upload.
Advertising
If you need a server in Russia for debugging or hosting projects, then our epic servers are perfect for you . Creation of your own configuration in a couple of clicks, daily billing of servers, anti-DDoS in the box, a convenient control panel. Better to try it once!
Confirmation and packing
When exporting a zipped app from Xcode, we have two main distribution options: App Store Connect and Developer ID. To distribute apps without an App Store, we'll use a Developer ID.
The same developer account you use to distribute apps through the Mac App Store can also be used to sign apps when you distribute apps using a Developer ID. The certificate itself is different, but Xcode will automatically generate and install it if you haven't already done so during the exporting process.
Since the release of macOS Catalina, all applications that are distributed directly to users must be validated by Apple, otherwise they will not launch by default. The verification process involves handing the application over to Apple, which performs automated malware inspection and “stamp” your binary with a special signature that allows it to run. This is not an App Review procedure, but an automated check that prevents malware from spreading in this way. It also allows Apple to flag a single binary file as malware, rather than the entire developer account, in case it is ever compromised.
The ability to validate the binary directly in the Xcode organizer depends on the packaging method you choose to distribute the application. You can't just upload a folder
.app
to a server and let users download it, it needs to be turned into an unstructured file. The easiest way to do this is by zip packaging the application and distributing it as a zip file, however, in my experience distributing the application as a DMG file significantly reduces the number of requests for help from users.
You've probably already seen DMG when downloading Mac files. These are disk images that macOS mounts when you double-click in Finder. They may also contain graphical instructions on how to drag and drop the application into the Applications folder. This makes life easier for the user and reduces the likelihood that that user will launch the application from the Downloads folder or some other arbitrary location.
If you are going to distribute your application as a DMG, then you just need to export it by selecting the Developer ID option in Xcode without notarization, and then validate the DMG itself. Xcode doesn't have an export to DMG option, so you'll have to use a third party tool. I like working with create-dmg... In addition, I have created and open source the dmgdist tool that automates the process of creating, downloading and stamping a DMG so that you can get a distribution-ready image with a single command.
To distribute your application as a zip file, the provisioning process is simpler: after selecting the Xcode Developer ID, select the upload option. A verified version of the application will be generated, which can then be zipped and distributed.
App updates
Another aspect of the App Store is that it deals with app updates. When we upload a new version to App Store Connect and it is validated, an update is available to users in the App Store. We need to somehow recreate this process for directly redistributable applications.
The best (and most popular) way is to use Sparkle . It has been around for many years and has become almost the official way of distributing updates to Mac apps sold outside the Mac App Store.
Now Sparkle seems to be living a double life. You can use either the "legacy" version of Sparkle, or the more modern "v2" branch, which includes many improvements, such as the ability to update applications used in the "sandbox". I still use the legacy version because I'm familiar with it, and integrating the more modern version still feels a bit tricky. There is no need to fix what is not broken.
The process of generating an application update usually goes as follows: we check that the version of the application becomes larger with each update, create a package as described above (Sparkle understands zip, DMG and installer packages), and then use the tool
generate_appcast
to update feed. After that, we upload the deltas, the package of the new version and the updated AppCast feed to the selected hosting, after which users will see the new version by checking for updates inside the application.
It might sound daunting and definitely takes practice, but once set up, the process turns out to be completely hassle-free (much better than working with App Store Connect in my opinion).
Making money outside of the Mac App Store
If you want to distribute your Mac app outside of the App Store, chances are that at some point you will want to make money on it. As with the App Store, many different business models can be used, but the most popular for direct selling to customers is the good old pay-ahead model: the user pays to download the app, registers it with a license key, and gets updates for free, at least , over a period of time.
Another popular business model for apps distributed outside the App Store is the subscription model, whereby users pay a monthly or yearly fee to keep using the app. You can write an entire guide (or a series of guides) for choosing a business model, so I’m not helping you with that. In this section, I will assume that I am using the pay-up model that I have chosen for my applications.
To get paid for your product, you need some kind of store that users come to, learn about the app, and buy it (if they're lucky). A good option for newbies is the Gumroad site , which offers a store page, payment processing, hosting, and licensing. When I released the first version AirBuddy in January 2019 then used Gumroad and it served me very well, selling tens of thousands of copies of the app over the course of a year.
However, Gumroad was not originally designed to sell software, so it lacks the flexibility that other services have. After releasing my new FusionCast app and AirBuddy 2.0, I switched to Paddle , which now handles payment processing and licensing of my apps.
Another option is to simply use a payment service like Stripe or FastSpring, or you can process orders and license yourself. This gives you optimal flexibility, although you have to work harder and will likely need to pay for additional services (such as sending emails).
I would say that if you are looking to make some money selling Mac apps outside of the Mac App Store, then Gumroad is the best option, as this site does almost everything for you and you don't even have to create a site for the app. However, if you sell apps as a company or your main source of income, then a professional solution with fewer restrictions, such as Paddle, will provide more flexibility.
Licensing, copy protection and piracy
If you distribute Mac applications directly, you might end up piracy: anyone can take your application binary and run it without paying a license, unless you enable some kind of copy protection.
While this is the case, I've come to the conclusion that developers, especially indie ones, shouldn't spend any significant amount of time building copy protection. Yes, some people will steal your work, but they wouldn't pay anyway, so the time spent worrying about it or embedding super-advanced DRM in an application is time that could be spent fixing bugs and developing new features. In addition, these practices end up punishing legitimate users more often than discouraging piracy (just look at the many examples of this from the game development industry).
In the first version of AirBuddy, there was no copy protection at all, not even the simplest registration form for entering a license key. I found several coiled copies on the Internet (of course, some of them were infected), but I saw no signs that the application is pirated by a large percentage of users, and my indicators do not reflect this either. In version 2, I use the Paddle SDK to register when installing the app, but that's it.
Apps distributed through the Mac App Store also don't have automatic anti-piracy protection: you need to manually check the App Store check to make sure the copy is legal. Most check verification codes are trivial to crack, so an app distributed through the Mac App Store is no more secure against piracy than an app distributed directly.
Marketing
I added this section primarily to say there is no major marketing difference between direct distribution of a Mac app and distribution via the Mac App Store. These days, simply releasing an app on the App Store means next to nothing because there is a low chance that users will simply organically discover a brand new app without external information.
When distributing through the App Store, you can skip the website creation step, as you can use an App Store page as the main showcase, but even so, I believe most apps will benefit from having a separate landing page.
App marketing itself might be a topic for yet another tutorial, but in general, any channels available to you can be recommended, especially if you already have followers (Twitter, Instagram, TikTok, etc.). Submitting your app (with a free license) to websites and Mac app reviewers can also be a great way to increase popularity. You can also use paid ads on social networks, podcasts, and publications.