Lessons from 14 Years on the Mac App Store: What startups should know before launching apps

Most young founders I talk to treat "ship to the App Store" as the finish line. You build the app, upload the binary, wait for the green checkmark, and start counting downloads.

We have been building Mac apps at Nektony for going on fourteen years, and most of the real work, in my experience, begins the moment you hit upload.

The App Store shapes far more than how your app reaches people. Its rules quietly inform your architecture, your roadmap, and your launch date, and they do that from the first week of the project whether you account for them or not.

Here is what we learned over those years, written down so a team starting today can see it coming.

Start with the sandbox

The first thing that surprises teams coming from the web is the sandbox. Every app on the Mac App Store runs inside it, and the sandbox governs what your code is allowed to reach: other apps' files, system folders, the network, the hardware. Each of those capabilities depends on an entitlement that Apple has to grant you.

This matters most when you build anything system-level. We make cleanup and uninstaller utilities, and a fully sandboxed app simply cannot reach into another app's Library folder to clear out the files it leaves behind.

We ran into this when we decided we wanted our apps available on the App Store as well, and it changed how we thought about the product from then on.

So the first question for a new app is a practical one: what does your app actually need to reach, and will Apple let it?

I would read the entitlements list early, alongside the API docs, and request only what you genuinely use. Every sensitive entitlement, from Full Disk Access to the camera to location, is something a human reviewer will later ask you to justify.

Budget real time for review

Earlier, Apple reviewed most submissions quickly, approximately within 24 hours. But because of the rise of vibe-coded apps, the process might occasionally take up to a week or more.

The risk is planning a launch as though any speed is guaranteed for you, because three situations slow it down in ways that catch new teams by surprise.

• Your first submission. A new app, from a new developer account, doing privacy-sensitive things, is the profile that gets the closest look. Plan for your first review to be a slow one.
• Entitlements that need explaining. The moment you ask for something powerful, an automated check becomes a human conversation. We put a clear note in the App Review notes for every sensitive capability, saying why we need it and how to test it, because a reviewer who cannot reproduce your feature will hold it back.
• The December slowdown. Apple eases off new releases, and in some years has paused them, for roughly a week around the winter holidays. If your launch lands in late December, give yourself a wide buffer or move the date.

The rule we follow is simple.

For a normal update, plan around a couple of days.

For a launch, a brand-new app, or anything touching entitlements, give yourself a week of slack and a fallback date.

Apple does offer expedited review for genuine emergencies, such as a crash on launch or a security fix, and it is worth saving for exactly those.

When you get rejected

Rejections are part of the process, and every team I know has collected a few.

Most of the ones we have seen fall into a handful of groups:

• Metadata that does not match the app, such as screenshots from an older version or a description that mentions other platforms.
• Privacy labels that do not line up with what the app actually does.
• A reviewer who could not get a feature to work.
• Guideline 2.1, which is Apple asking for more information.

Very few of these are fatal. Most are simply round-trips.

What has worked for us is replying in the Resolution Center calmly and specifically, with steps to reproduce and, where it helps, a short screen recording.

When we genuinely believed a reviewer had misread a guideline, we asked for a call or filed an appeal, and we have had decisions reversed that way.

Resubmitting the same binary in the hope of drawing a different reviewer tends to go nowhere, so it is better to fix the actual issue or explain clearly why there is nothing to fix.

The part that adds up is time. Each rejection is a round-trip measured in days, and three careless ones can quietly cost two weeks.

The cheapest review is the one you pass on the first try, so it pays to read the App Store Review Guidelines carefully before you submit.

The autumn macOS release

There is a rhythm to Mac development that is easy to underestimate at first.

Every autumn Apple ships a major macOS release, and each one changes the ground under your app in small ways.

We have seen a new version put a permission prompt in front of a feature that had worked untouched for years. We have seen Apple retire a system surface we relied on: macOS Tahoe removed Launchpad, which broke a workflow we had been recommending to users for a decade.

The move to Apple Silicon meant shipping everything again as a universal binary.

None of these were our bugs, yet all of them became our work.

I would treat this cadence as a fixed cost.

We run our apps against the developer betas through the summer, every summer, and we keep room in the roadmap to make things work on the new OS before users upgrade and the support inbox fills up.

A team that plans for September tends to look steady to its users.

A team that meets it by surprise every year tends to look unreliable through no real fault of its own.

What helps an app sell

Getting approved puts your app in the store, and turning that listing into customers is a separate effort.

After fourteen years, here is where I have seen the most leverage, roughly in order.

• Screenshots do most of the selling. Many people decide from the first two or three screenshots without reading a word, so we treat them as the main conversion surface and lead with the outcome the app delivers rather than a tour of the interface. We have seen reordering screenshots move conversion more than a new feature did.
• Recent ratings carry more weight than the lifetime total. A steady stream of fresh reviews signals a product that is alive and maintained. We ask for the review at a moment of success, right after the app has done something useful, and we reply to reviews in public so the next reader can see that someone is paying attention.
• Your pricing model is part of your positioning. Mac users are noticeably more resistant to subscriptions than iOS users, and many still expect to own the software on their desktop. We offer a real free trial, and where a subscription makes sense we make the recurring value obvious. One concrete thing worth doing early is enrolling in the App Store Small Business Program, which drops your commission from 30% to 15% under $1M a year. For a bootstrapped team, that difference is real runway.
• Localization is inexpensive conversion. Translating the store listing, even just the metadata and screenshots, lifts conversion in non-English markets well out of proportion to the effort it takes.
• Apple featuring is real, and you can ask for it. Some of our largest spikes came from being featured. There is a nomination form, and the most reliable way we have found to earn an editor's attention is to support the newest OS features in the week they ship.

Shipping outside the App Store

There is one thing specific to the Mac that is worth keeping in mind as you weigh all of the above.

On the Mac you have a second, fully legitimate way to reach users: distributing your app directly from your own website, as long as it is signed and notarized through Apple.

Apple has required notarization for direct distribution since macOS Catalina and documents the process for developers.

A notarized direct build runs outside the App Store sandbox, so it can do things a sandboxed build cannot, which is why so many Mac utilities exist in both forms.

For us this became a permanent part of the operation.

We ship two builds of the same app:

• A sandboxed App Store version with a narrower feature set.
• A notarized direct version that can do the full job.

That means two code paths, two sets of capabilities, two update channels, and two streams of support questions, for as long as the product exists.

I would think this through at the start rather than bolting it on later, because adding a second distribution model to a finished app costs far more than designing for it early.

If your app lives comfortably inside the sandbox, the store on its own may be all you ever need.

If it does not, that is something you want to know before you have built around the assumption.

What it adds up to

If I had to compress fourteen years into a single idea, it would be this:

The App Store works best for teams that build with its constraints in mind from the beginning.

The sandbox, the review queue, the autumn releases, the way ratings move, all of it is simply the shape of the business you are choosing to be in when you ship a Mac app.

Teams that design for it early tend to have quiet launches.

Teams that meet it one rejection at a time tend to spend their first year on rework they could have planned around.

Either way, the constraints stay the same, and the part you control is how early you account for them.