For the past few weeks I have been debating on whether or not to distribute a new Mac app via the Mac App Store or independently. I have arrived at a crossroads in development where I need to make this decision. I am mostly code-complete for my MVP 1.0 release. The question I am facing is how I want to spend the remainder of my time to cross the finish line.

A brief background

For the best user experience, my app requires Full Disk Access. It is a utility that interacts heavily with the filesystem. Unfortunately, there is no API to simply request Full Disk Access from the user upfront and explain why you need it. Nor is there an API for simply asking the user for access to a folder — it is all implicit via open/save dialogs or drag-and-drop. A workflow similar to how iOS handles its various permissions would be great, but it does not exist on macOS.

Sandboxing and file permissions

A quick search on the web for “macOS Full Disk Access” yields myriad results of various company help articles and support pages carefully instructing users how to enable Full Disk Access for their apps. It is obscure and opaque from both a developer perspective (no explicit APIs like iOS!), and an end user perspective (no explicit prompts like iOS!). The breadth of this baffling and abjectly terrible design is evidenced by every single identical help article that every developer must write to explain to users how to enable it.

To get a sense of how much extra work and effort is required to support the app sandbox, see Ben Scheirman’s excellent piece on Modern AppKit File Permissions, or Peter Steinberger’s gist on how to access sandboxed URLs after an app restart. Even when a user grants you access to a specific file — that is, they select a file from a standard Open Dialog using NSOpenPanel — you cannot even fucking rename that file because you do not have write permission to the file’s enclosing directory.

In order to achieve a somewhat acceptable user experience, you must utilize the Security-Scoped Bookmarks API to “save” access to any files and directories to which the user has previously granted your app. Otherwise, you must constantly prompt the user with annoying Open and Save Dialogs to implicitly regrant permission to the filesystem after your app is relaunched. You cannot simply use NSFileManager like you would expect. Using Security-Scoped Bookmarks is an another non-trivial rabbit hole into which you must descend during development, in addition to other sandboxing quirks and nuances. Because of this, we have an entire open source library (by Leigh McCulloch) to accommodate working with sandboxed file access.

Even Quinn admits that there are no ideal solutions for working within or around the app sandbox limitations in certain situations, and even suggests distributing outside of the Mac App Store!

Mac App Store or Independent?

So this brings me to the question I need to answer. Do I spend my time and effort properly sandboxing my app (and writing a help document to explain Full Disk Access to my users!), which will undeniably produce a worse user experience (even with Leigh’s library)? Or, do I instead spend that same time and effort learning and figuring out how to distribute my app independently, which includes a solution to payment processing and licensing? What are the benefits and drawbacks of each?

Mac App Store

✅ Distributing via the Mac App Store is simple. You upload your app bundle to App Store Connect, fill-in your metadata, and set your price. You do not have to implement your own software update mechanisms, binary hosting, payment processing, or licensing.

✅ Discovery and installation is easier for most, typical users.

✅ The App Store is familiar, because of my extensive iOS experience.

🚫 I must pay the (bullshit) 15-30% App Store Tax.

🚫 Sandboxing requires a lot of development effort and resources. It produces a worse user experience, in general, but it is especially terrible for my app.

🚫 There is a risk of an outright rejection during the initial submission. All that effort to sandbox would be wasted if Apple does not want my app in its store. I am currently 2 for 2 on rejections. See: Lucifer and Red Eye. Admittedly, these are unserious, hobby apps — but still.

🚫 Even once accepted, I will potentially be subject to arbitrary, bullshit rejections during updates, or possibly complete removal.

🚫 Every update is subject to frivolous, undocumented App Review policies.

🚫 Limited business model options: no paid upgrades, no proper trials, etc.

Independent

🚫 I need to figure out and implement distribution, hosting, software updates, payment processing, and licensing on my own. Likely I will be using Paddle for payments and licensing, and Sparkle for updates. I’m not sure about hosting.

🚫 Discovery and installation is more difficult. But it’s arguable how beneficial the App Store is for “discovery” anyway.

✅ However, learning and implementing all of the above is mostly a “set up once” kind of task, after which maintenance should not be too time consuming. Furthermore, after building this foundation, I’m ready to take advantage of it for any future apps I create. I could even bring these enhancements to Lucifer and Red Eye, to turn them into something more serious and consider selling them.

✅ I do not have to implement sandboxing. This is a better development experience, requires less testing, and produces a significantly better user experience.

✅ Paddle takes a percentage of transactions, but it is nowhere close to Apple’s 15-30% tax. I will capture more of the value I produce for myself, instead of subsidizing the wealthiest corporation in the world.

✅ More business model options, and the ability to easily change or experiment with them.

✅ The are no submissions, no reviews, and no rejections to deal with — ever.

Final thoughts

I also recommend checking out Guilherme Rambo’s excellent guide on distributing Mac apps outside the App Store.

It is clear to me that independent distribution is a significantly better investment of my time — especially considering Apple could reject my app from the start. It gives me more control and greater independence. It will provide me with a better, more lucrative, sustainable, long-term foundation to build on — not only for this app, but for all future apps I create.