App Development
Selling a Mac App: App Store, Direct, or Both
By the Coast Creative team4 min read
On iPhone there's one way to sell an app. On the Mac there are two, and most people building their first Mac app don't realize the choice has to be made early. It isn't a marketing decision you can defer until launch week. It changes what your app is allowed to do, so it changes the code.
Here's how the two routes actually differ, and the questions that settle it.
What the App Store really gives you
Discovery is the reason people assume they want the App Store, and it's the weakest one. The Mac App Store is small, and unless you get featured, almost nobody stumbles onto your app. Plan to drive your own traffic either way.
The real value is everything around the sale. Apple handles payment, refunds, fraud, and sales tax in every country you sell into. Customers already trust the checkout and already have a card on file. Updates flow through a system users understand. For a solo developer, that's a lot of infrastructure you don't have to build or babysit.
In exchange, Apple takes a cut of each sale — the standard rate, or a reduced rate if you qualify for the Small Business Program. Check the current terms before you model anything, because those numbers have moved before.
The sandbox is the real constraint
Every Mac App Store app has to run sandboxed. Your app is walled off from the rest of the system, and anything outside that wall requires an entitlement Apple has to grant.
For a document-based app or a focused tool, that's fine. For utilities, it's often fatal. Apps that read detailed system stats, automate other applications, manage files across the disk, or sit in the menu bar watching what the machine is doing tend to hit walls the sandbox won't open. Some of those entitlements don't exist. Others exist but get denied without a compelling justification.
This is why so many well-known Mac utilities sell direct. It isn't ideology. Their apps could not ship in the store as designed.
So the first question isn't where you want to sell. It's whether the app you have in mind can legally live inside the sandbox at all. Answer that before you write the app, because retrofitting sandbox compliance late is miserable.
What selling direct actually takes
Going direct is very doable, but it's a real checklist. You need a Developer ID build that's signed and notarized by Apple, or macOS will refuse to open it cleanly on other people's machines. You need a storefront and a payment processor. You need license keys and a way to validate them. You need an update mechanism, which in practice means Sparkle. And you need to handle sales tax, which is the part that surprises people.
The shortcut on taxes is a merchant of record — services like Paddle or Lemon Squeezy sell the app as the seller and take on the global tax obligation. You pay for that convenience, but for a small operation it's usually the right trade against registering for tax in a list of jurisdictions.
Support and refunds are yours now too. That's not a hidden cost so much as an unavoidable one.
Trials are the honest advantage of direct
The App Store still has no true trial for a paid app. You can ship it free and charge with an in-app purchase, which works, but it changes how the app is built and how it's perceived.
Sell direct and you can offer a straightforward time-limited trial. Someone downloads it, uses the full app for a few days, and buys if it fits. For a utility that has to prove itself on someone's own machine and their own files, that demo is worth more than any screenshot on a store page.
Doing both
Plenty of developers ship a sandboxed store version and a fuller direct version. It's legitimate, and for some apps it's the best of the two.
Be honest about what it costs. Two builds, two feature sets to document, two update paths, two support flows, and customers who bought in one place asking why a feature is missing. It's a maintenance decision as much as a sales one, and it's easier to add the second channel later than to run both from day one.
How to decide
Three questions get you most of the way there. Does your app need capabilities the sandbox won't allow? If yes, direct is the answer and the rest is moot. Does your app need to be tried on real files and a real machine before anyone will pay? If yes, direct is much stronger. Are you doing your own marketing regardless? If yes, the store's discovery advantage mostly disappears.
If none of those apply and your app is self-contained, the App Store is a reasonable default. The cut buys you real infrastructure.
We ship our own Mac apps direct with free trials, which means we make this call before the first line of code rather than discovering it at submission. If you're planning a Mac app, decide the channel first — it's the constraint everything else has to live inside.