My Vision for macOS App Distribution
If you want to distribute a native macOS app, you have 2 options. The Mac App Store or distributing the app yourself using Developer ID.
Using the App Store comes with multiple benefits like automatic distribution of updates, TestFlight, a merchant of record payment provider via Apple's StoreKit, and sometimes visibility. Those benefits come at the cost of 30% of your revenue.
But the Mac App Store also puts many restrictions on developers through Apple's strict App Store guidelines. Not every app can conform to Apple's guidelines, like using the sandbox entitlement, which strongly limits what an app can and cannot do.
If your app cannot make use of the sandbox entitlement or doesn't conform to the review guidelines, your only option is to distribute the app yourself. That means you will need to manage app updates and payments yourself. For payments, you most likely will need to implement some kind of licensing system. To keep your app up-to-date, you will use the brilliant Sparkle framework. But setting both of these up is cumbersome and takes time away from building your app.
Sparkle
The Sparkle updater project is the de facto standard to distribute app updates outside the Mac App Store. It's decades old, reliable, and familiar to users. But setting it up will consume your day. The process of publishing a new update to your app using Sparkle also takes a bit of time. I assume that it costs me around 30 minutes each time I want to ship a new update for my Mac apps.
The process for each update:
- Archive the app
- Notarize the app
- Staple the notarization ticket onto the app
- Create a DMG or ZIP the app
- Sign the update via Sparkle
- Create a new
appcast.xml - Manually edit the changelog in the
appcast.xml - Upload the resulting files to some server
If you want to use some of Sparkle's more advanced features, like minimum system version requirements, major or critical updates, phased group rollouts, or beta channels, you will need to manually set that up as well.
My Vision
What if there is a project that has all the benefits of the Mac App Store without having the downsides like App Store Review and strict sandboxing requirements plus the 30% Apple tax?
That's what I am planning to build. My vision is to offer a simple developer toolkit that makes distribution and licensing of macOS apps easier and faster than publishing an app on the Mac App Store.
I split the project into 3 phases:
- Research and feedback
- Managing of app updates and distribution
- Payments and licensing
Managing App Updates and Distribution
This project is still in phase 1, but for my research I started to tinker around with a command-line tool I call amore.
The end goal of amore is to have a single command to release a new app update. Whenever you want to release a new version of your app, you simply execute amore release and it will take care of the rest for you. From archiving your app, through notarization, and uploading it to a server. All the 8 steps from above. amore will be able to take care of it.
On your app's side, you will only have to add 2 new Info.plist entries to set up Sparkle. A URL for the appcast.xml so your app knows where it can check for new updates and your public ed25519 key. Don't worry, amore will handle key pair generation and management for you, too.
So far it can only do steps 4 through 8, but as I continue, I will add all the remaining steps. It's a single binary that's fully compatible with Sparkle and has 0 dependencies.
amore pairs with a server to manage updates and advanced Sparkle features like optional anonymous analytics collection about your users and more. In addition I want to offer a web- or app-based WYSIWYG editor to make the creation of release notes easier.
In addition to the command line tool, I am thinking about a Mac app that you can just drag updates into and manage new releases. Although I am not sure if developers would prefer this instead of a CLI.
The app could work like Helm, but without being slow and built around App Store Review.
Purchases & Licensing
This is a bigger project and will probably have to happen in stages because I need to learn more about use-cases and what developers actually need.
For payments, I would start with a bring-your-own-API-keys model compatible with Stripe, Gumroad, Paddle, etc. Eventually I would like to provide a merchant of record scheme to be able to offer a full package, but getting there will take time.
The plan here was to start with the 2 most popular licensing models for your apps:
- One-time purchase
- One-time purchase with free updates for a year
This would come with a client SDK to make implementing license validation straightforward.
Security & Privacy
App updates are a critical failure point in your application, and that's why the service won't require your Apple credentials or your private ed25519 key used to sign each Sparkle update. All the steps requiring private credentials or keys will happen on your computer with your permission.
To stay independent of amore and the server you will be able to use your own domain, preventing vendor lock-in.
Pricing
To finance the service we need to charge money. I don't know what a realistic price is yet, but for the update distribution I was planning to charge the same as Apple. An annual fee of $100 for unlimited apps. Free for FOSS projects.
I am not sure how to monetize the payments and licensing part yet.
Your Feedback
For now I'd like to learn more about the Mac developer community's wants and needs. The purpose of this post is to let you know what I envision and to spark feedback and discussion.
- Is this something you would like to use?
- What do you need?
- What's your biggest pain point when distributing apps outside of the App Store?
- Would you pay for this?
Please share your thoughts with me via this feedback form, email or Mastodon.
If you are interested in the project and want to get notified about updates, you can use this form to give me your email address. I won't spam you. I promise.
Inspiration
This project heavily inspired by Zhenyi Tan's Idea: A Modern Potion Store and my own frustration with how Apple governs the Mac App Store.
Thanks for your ongoing advice and guidance, Nim
