The Case Against the Mac App Store for Indie Apps

The Mac App Store turned 14 in January 2025. It launched in 2011 as Apple's answer to the iPhone App Store success: a curated, trusted, easy-to-discover catalog of Mac apps with one-click install. The early years were genuinely good. BBEdit, Pixelmator, OmniFocus, the Affinity suite, many of the apps that defined modern indie Mac shipping found their footing on the Mac App Store.

That was a long time ago. As of 2026, most of the apps I respect ship outside the Mac App Store, with a few even pulling existing apps off the store after years on it. The reasons are accumulated, structural, and worth understanding if you're a Mac user wondering why your favorite apps live on the developer's website instead of in the Apple-curated catalog.

Disclaimer first: I run an indie Mac shop. Every app I ship is currently available outside the App Store, distributed via the developer's own website with notarization. So this is an argument from someone who has made the choice. Read accordingly.

The fundamental problem: no paid upgrades

The Mac App Store does not support paid upgrades. If you sold "AppName 1.0" for $20, and you ship "AppName 2.0" with new features, the App Store gives you exactly two choices:

1. Push 2.0 as a free update to all existing 1.0 customers. New customers get 2.0 at the new price (which can be different from 1.0's). Existing customers paid for 1.0 and now have 2.0 free.
2. Submit "AppName 2" as a separate product. Existing 1.0 customers can choose to buy 2.0 at full price. They lose 1.0 if they upgrade. The two apps are not connected in the App Store and the migration is awkward.

Neither option is what indie devs need. The healthy model is: charge $30 for a major version, ship free updates within that major version for a year or two, and offer existing customers an upgrade path to the next major version at a discount. That model is impossible in the Mac App Store. It has been impossible since 2011.

Apple has acknowledged the problem in interviews multiple times and has not fixed it in fifteen years. The result is that indie devs who want to monetize ongoing development have two options on the Mac App Store: subscriptions, or rename-the-app as a workaround. My piece on why subscriptions ruin Mac software covers the downstream effects.

The 30% cut

Apple takes 30% of every sale, dropping to 15% after a customer's first year of subscription. For a one-time purchase $4.99 utility, that's $1.50 to Apple, $3.49 to the developer (before payment processing fees, which are baked in for App Store sales).

Compare to direct sales: through Polar.sh or Paddle, the indie dev keeps closer to 90% of revenue after fees. On a $4.99 sale that's roughly $4.30 to the developer, almost a full $1 more per sale than the App Store. That's a 25% increase in per-sale revenue, which compounds dramatically over a 5,000-sale catalog.

The 30% would be defensible if the App Store delivered enough customer acquisition to offset it. For most indie utilities it does not. App Store organic discovery is poor unless you're already in the top charts, and the top charts are dominated by apps with serious marketing budgets that the indie dev can't compete with. The App Store ends up being a list, not a discovery engine. Direct distribution doesn't get you Apple's discovery, but it doesn't pretend to either.

Sandboxing constraints

Mac App Store apps must be sandboxed. The sandbox limits what an app can do: filesystem access, hardware control, inter-app communication, system-level event monitoring. For most apps, sandbox compatibility is achievable with effort. For some categories of indie utility, it is genuinely impossible.

Examples of categories that struggle in the sandbox:

• Window managers. Need to control other apps' windows. Sandbox blocks this; requires Accessibility permission, which sandbox apps can request but the UX is awkward.
• Backup tools. Need full disk access. Sandbox apps cannot ask for full disk access.
• System utilities like CleanMyMac. Need to scan and modify system files. Sandbox blocks broad filesystem access.
• Some clipboard managers. Need to monitor pasteboard changes from background, which has worked through sandboxing but with caveats.
• Anything that hooks into other apps. Hookmark, Default Folder X, BetterTouchTool. Generally sandbox-incompatible.

The result is that many of the most useful Mac utilities have to choose: ship in the App Store with reduced functionality, or ship outside with full functionality. Most pick full functionality, which means the App Store catalog is structurally missing the apps power users actually want.

Review delays and rejection arbitrariness

App Store review for Mac is generally faster than iOS, typically 1-2 days for an established app, sometimes longer for new submissions. But the delay still imposes a planning constraint that direct distribution does not. If you find a critical bug in a shipped App Store version, you patch it, submit, and wait. With direct distribution, you sign and ship the same day.

More frustrating is rejection arbitrariness. App reviewers operate from internal guidelines that are not always consistent across reviewers. Indie developers regularly report a feature that has shipped through several App Store releases suddenly being rejected on a fresh build, with no explanation beyond a generic guideline citation. The dev has to engage in slow correspondence to get the rejection lifted or modify the feature.

This is part of running an App Store business. It's also a reason direct distribution looks attractive: no review, no rejection, no guideline.

The "out of band" feature gap

Indie Mac developers often want to do things that the App Store either doesn't expose or actively disallows. Examples:

• Time-limited trials. The App Store doesn't support trials. Apps that want them have to roll their own (in-app purchase + trial flag, or external license server). Direct distribution apps can ship a 3-day free trial natively.
• Family pack pricing. The App Store has Family Sharing but it's not the same as a direct-sale family-pack license. Direct distribution lets the developer set this up however makes sense.
• Custom checkout flow. Direct distribution lets the developer use Polar.sh, Stripe, Paddle, or whoever. Different markets have different payment preferences. The App Store has Apple's checkout only.
• Email follow-up to customers. The App Store hides customer emails from the developer. Direct distribution lets the developer collect (or not) customer emails and follow up with release notes, security advisories, or upgrade offers.
• Cross-platform discounts. A developer with iOS and Mac apps can offer a "buy both" discount via direct distribution. The App Store charges full price for each platform.

Each of these is a small thing. Cumulatively they shape the kind of business an indie can run inside vs outside the App Store.

What about notarization and Gatekeeper?

The historical fear about distributing outside the App Store was that the app would feel "unsafe" to users, Gatekeeper warnings, can't-be-opened errors, etc. Apple addressed this with notarization in 2019. A notarized direct-distribution app installs cleanly on macOS Catalina and later, with no warning beyond the standard "downloaded from internet" prompt on first launch.

Notarization requires:

• A $99/year Apple Developer Program membership.
• A Developer ID code-signing certificate.
• Submitting builds to Apple's notarization service for static analysis (typically 1-15 minutes).
• Stapling the notarization ticket to the app bundle.

This is the same work the App Store does for a developer except it's done from the developer's own machine and there's no review queue for human inspection. The user experience for the customer is essentially identical: download a notarized app from a developer's website and it installs without drama. Most users in 2026 don't notice any difference between an App Store install and a notarized direct download.

The argument for the App Store

Honest counterargument time. The App Store does some real things well:

Trust signal. "On the Mac App Store" is a recognizable trust marker for less-technical users. Some customers won't install from outside the store for any reason.

Updates and license sync. Family Sharing, automatic updates, and license sync across devices are smoother through the App Store than through any indie infrastructure.

Localized payment processing. The App Store handles VAT, sales tax, and local currency for every market without the developer thinking about it. This is non-trivial.

Discovery (limited). Some categories, kids apps, productivity, photo editors, get genuine App Store discovery if the app is well-positioned. Utilities don't, but other categories do.

Search. Apple's App Store search, while not great, brings some traffic.

For the right kind of app, broad consumer software, not power-user utility, the App Store is still a fine place to be. Pixelmator built a substantial business there. So did Acorn (which dual-distributes). The answer isn't "never use the App Store"; it's "match the channel to the audience."

The dual-distribution pattern

The pattern most established indie devs converge on: ship the same app both directly and on the App Store. Two builds, both notarized, with the App Store version sandbox-compliant and the direct version unrestricted (or modestly more capable). License keys work across both. The developer learns which channel produces more revenue and reallocates marketing accordingly.

The challenge with dual distribution is the engineering cost of maintaining two builds. Sandbox-compliance changes can be invasive. Some features get cut from the App Store version because they can't ship there. Some features get added only to the App Store version because Apple wants them.

For a tiny indie shop with a single utility, dual distribution is often not worth it. They pick one channel and stay there. The TeenyApps catalog is currently direct-distribution only. We may add App Store distribution for some apps in the future, but each app is a separate build choice.

What happens to App Store apps over time

A historical pattern worth noting: many apps that started on the App Store have, after years on it, pulled out or added direct distribution as the primary channel. Reasons include the paid-upgrade problem, sandbox constraints discovered late, and the desire to ship a subscription with more control than the App Store allows.

BBEdit dual-distributes. Acorn dual-distributes. The Affinity suite eventually moved primary distribution to direct. Sketch direct-distributes. Many of the apps in the one-time-purchase Mac apps list are direct or dual.

The opposite migration, from direct to App-Store-only, is rare among established apps and almost never happens after the developer has been off the App Store for any length of time.

The user side: should you worry?

If you've been hesitant to install Mac apps from outside the App Store, the decision matters less than it used to. As long as the developer is reputable, the app is notarized, and you're downloading from the developer's actual website (not a search result that might be a spoofed mirror), the security profile is essentially identical to App Store distribution.

Things to check before installing a direct-distribution Mac app:

1. Verify the developer's website. Look for a real "About" page, real social presence, and a real history.
2. Check if the app is notarized. Most reputable indie apps say so prominently. The first launch will tell you (no scary warnings).
3. Check the developer's response time on email. Send a question. If they respond, they're real.
4. Look for established communities (Mac Power Users, MacStories, ATP) discussing the app. If multiple respected Mac people use it, the trust transfers.

Direct distribution isn't risky in 2026. It's just where most of the interesting Mac software lives.

The bottom line

The Mac App Store is a good distribution channel for some apps and a bad one for most indie utilities. The reasons are structural, paid-upgrade absence, sandbox constraints, 30% cut, no time-limited trials, and they have not changed in fifteen years despite consistent feedback from developers. Apple's interest in fixing these problems appears low.

The good news is that the Mac uniquely supports robust direct distribution. Notarization, code signing, Sparkle for updates, and a customer base willing to install from indie websites are all infrastructure that lets indie devs run sustainable businesses outside the App Store. iOS does not have this. Mac does.

If you're a Mac user, your favorite apps probably live on the developer's website. That's not a sign of a problem. It's the norm. Trust the developer, trust notarization, install the app, and enjoy a Mac software market that the App Store cannot constrain.