3 reasons devs ditch the App Store, and what this freedom costs

What do Sketch, Coda, and BBEdit have in common?

Apart from being big name Mac apps, they’re all big name Mac apps that have walked out on the App Store.

There’s something fundamentally wrong about people leaving the place that was built to make their lives easier. But then again, you know what’s paved with good intentions. Helpful as it was planned to be, right now the App Store is a pain in the oh-so-tired developer necks. The 30 percent cut you have to give away. The absence of trials and upgrade discounts. The technical limitations that keep your hands tied. And to crown it all, the two words that give every developer a nervous eye twitch — App Review.  

Our bestseller app CleanMyMac never made it to the App Store and has been selling outside it right from the start. Nevertheless, we’ve had our share of unforgettable interactions with the App Review team when submitting other MacPaw apps. There’s been email stalking (on our part), middle-of-the-night calls (on theirs), and other attributes of a teenage breakup.

Besides the habit of turning off our phones for the night, there are two things we took home from our experience with and without the App Store. One, what the process of reviewing apps shouldn’t look like, ever. And two, exactly how much the free life outside the App Store costs.

Everything wrong with the App Review.

It’s painfully slow

The average time it takes to review an OS X app starts at 8 days, and the end of it dangles in-between 14-18 days in peak periods.

For a developer, a week is meeting or missing the deadline. For a marketer, a week is profit, earned or lost. For a company, it’s release dates, publicity, being featured in the media, and, most importantly, getting customers.

When release dates for your app directly affect your publicity and profit, a delay means you lose it all.

Our dev team always plans in advance and submits apps at least a few weeks before the deadline. But sometimes even that is not enough — as it happened with Tint, our small app that never saw the light of day.

Last October, we tried to hijack the tvOS bandwagon and release a bunch of apps for it before it becomes cool. Most of our apps passed with flying colors, because we have people who know the Review Guidelines better than their kids’ names. Tint didn’t get any response for a month. When we resubmitted it, it was rejected, because a similar app was already there.

Someone else’s app got approved before ours. TV App Store was released, Tint still wasn’t. We couldn’t be any more late, even if we tried.

It’s inconsistent

App Review is a Chaotic Good force: In the fight for a clean, safe App Store, it keeps accidentally killing good apps along with the junk. Or better still — killing good apps that have been on the store for years.

A routine, minor release of our iOS player Listen got rejected because it had a picture of a Daft Punk album on the screenshot. The exact same picture it had since day one, included in a dozen previous submissions. All of them got the green light, this one didn’t.  

The inconsistency spreads far beyond online. Once at WWDC we asked the reviewers personally if it’s ok to show ads for CleanMyMac, an app that is not on the App Store, in CleanMyDrive, an app that is on the App Store. When we got a straightforward “yes”, we returned and spent months developing an ad mechanism, planning our campaigns, spending time and budget, only to find out that no, we cannot promote CleanMyMac in CleanMyDrive. And they don’t know why they told us otherwise on WWDC. Funny story.

It has a zero feedback policy

Getting rejected per se is not as bad as having no clue why or how to fix it. Time and again, developers stay in the dark, because App Review has the feedback range of a wall.

The most detailed feedback you get on a rejected app is a screenshot of a paragraph from the guidelines. If you ask for clarification, you can get another screenshot. Most often, the same — the one that can be interpreted in 27 ways and applied to any place in the app.

When another tvOS app we made was rejected, we bombarded the review team with emails for weeks, trying to figure out what was meant by “the advertised feature of the app being not a true version of that feature.” Eventually, tired of our persistence, Apple reviewers called us. This is their answer to our gnawing questions: “Listen, your app is not going to be approved. We have internal guidelines as well, and we’re not obliged to share them with you.”

That settles it, they have internal guidelines that they don’t have to share with developers. You know what I’m thinking? If the original goal of the whole App Store thing was to help developers make great apps, something went wrong on the way.

There’s freedom out there, but it’ll cost you.

When you have to go through all this misery just to get your product on the shelf, does being in the store even make sense?

I’m sure the thought has crossed the mind of Mac devs everywhere at some point. One of the things that still keep people on board is that the App Store takes a lot of coding work off their hands — like licensing and delivering updates. An app that’s on the Mac App Store doesn’t need these mechanisms, they are provided by Apple. An app that’s not needs a bunch of frameworks just so users could try, activate, and update it.

So, how much does it cost to build your own theme park, with trials and delta updates?

Let’s say you’re an experienced, agile (don’t flinch) OS X developer. You know exactly how much your working time is worth. The questions are what your app needs to sell outside the App Store, and how much of your time that will take to develop.

As people who’ve been there and done that, we’ve crunched some numbers and made a rough estimate of how much it costs to meet the basic needs of a Mac app. We’ve done it for CleanMyMac, Gemini, and our other products, so the Maslow’s hierarchy here is based on real-life experience:

1. A licensing mechanism (ideally with trials, beta versions, and custom license types) ≈ 400 hours to develop, ≈ $20,000
2. A crash reporting mechanism ≈194 hours, ≈ $9,700
3. Collecting user feedback ≈ 120 hours, ≈ $6,000
4. Analytics (tracking launches, session durations, etc.) ≈ 56 hours, ≈ $2,800

Total: 770 hours = $38,500

(Of course, there’s also update delivery to think about — but fortunately, a free framework like Sparkle does the trick.)

Should you roll up your sleeves and try to code it all yourself, or rummage through developer forums and put together a bunch of third-party tools? Well, it’s your call. Us — we decided to make our own set of frameworks that would cover everything our apps needed for decent user experience and full-fledged marketing.

Took us four years

Believe it or not, it was time well spent: The result is our very own SDK that enables us to sell apps when, where, and how we want it. (In fact, it has grown into a standalone tool, so we called it DevMate and shared it with other devs to save ‘em the trouble.) And while many MacPaw apps still have an App Store version, it’s good to know their fate doesn’t hang solely on the App Review verdicts.

But it’s not about MacPaw or how life outside the App Store is treating us. My point is there is life outside the App Store, and it is rewarding. It’s free from feature limitations, obscure guidelines, or subjective opinions that determine the fate of your release.

And I bet it’s the number one reason why Mac devs exit the App Store, one app at a time.