Matt Gemmell

Releasing Outside the App Store

14 min read3545 words

I recently released a new little Mac app, Sticky Notifications. It’s not currently in the App Store, and accordingly I went through a process that many Mac developers face: deciding whether to release software on the App Store, or outside of it (or indeed both).

In this article, I’ll talk about the pros and cons of each approach, and how I went about providing all the things we take for granted on the App Store (and pay for with its 30% fee), in an app I released outside of it. This piece is focused squarely on developers who want concrete and specific suggestions as to functionality, services and providers, and appropriate reusable components.

Firstly, let’s weigh up the App Store against releasing software on your own. This concerns the Mac, primarily, since you don’t have a legitimate non-App Store option for iOS devices. The pros and cons of the App Store (listed below) do apply to both platforms, of course. We’ll discuss the App Store route first.

Releasing on the Mac App Store

There are some fairly well-established benefits and problems with using the App Store as your software delivery mechanism. For completeness, let’s quickly run through the main ones.

App Store Pros

  • Payment, file hosting, bandwidth, and update-delivery (and notification) are all handled for you.
  • There’s no need to concern yourself with registration/licenses. If a customer has your app, they have the “registered” version (piracy notwithstanding, as always).
  • You’re less directly exposed to customers, on average. The App Store is essentially designed to be a reseller kiosk where you buy then leave.
  • You’re more discoverable to the average person, since everyone has the App Store on their Mac.
  • You probably won’t see quite as much of a tail-off after release surges. That’s a guess on my part, but it seems reasonable.
  • You have some negligible-to-unreliable chance of being “featured” by Apple, resulting in more sales.
  • Success breeds (significant) success, due to the various “top selling” lists within the Store.

App Store Cons

  • It costs 30% to use the App Store. That’s cheap for what you’re getting, but it’s a substantial chunk in absolute terms.
  • Apple can be very slow to approve apps, sometimes to the point of pretty much failing in their implied duty of partnership with you. At time of writing (24th August 2012), for example, average Mac App Store review times are 18 days. That’s not even remotely sustainable for a modern, reactive software business.
  • It’s impossible to quickly issue updates, or to provide customer-specific patches or versions in a reasonable way. Creating an ad-hoc build for a customer’s own device is still a nasty, multi-step, fiddly process, even with things like TestFlight. There’s a big technical/perceptual barrier there.
  • You can’t really address customer issues in a proactive and happiness-generating way, e.g. with a quick refund plus support and an update.
    • The in-store links to support channels are deliberately difficult to find, following the Amazon model (albeit the App Store puts support links on the front page but makes them visually hard to locate – and disables on-page search – whereas Amazon buries support links multiple levels deep). It’s sleazy, and cruddy for customers.
    • You can ameliorate this, of course, with prominent support-access built into the app itself, but there’s still a bad taste.
  • There’s no guarantee your app will be approved for the Store. Even if you follow the guidelines, you don’t know (1) how au fait with those guidelines your specific overworked reviewer will be, and (2) you don’t know what new or additional guidelines exist beyond those you’ve read about. It’s not difficult to find anecdotes on the web of developers who have fallen foul of this problem.
  • You can’t offer paid upgrades. The App Store model is “buy once, get free upgrades forever”, which is of course tantamount to encouraging disposable software (and support practices).
  • You can’t offer demo versions. This is not only cruddy for the customer, but will inevitably create extremely annoyed people who bought based on faith or misunderstanding.
  • There are various technical limitations placed on your app, for both legitimate (often, security) and not-so-legitimate reasons.
  • The customer-reviews system can be (and very often is) a capricious, hideous lunatic asylum filled with a vocal, whining minority of grotesquely entitled people.
  • It’s difficult to create customer-facing messaging; app descriptions (and release notes) are truncated by default, and designed to be skipped or never read in the first place.
  • There’s a strict limit on the number of promo codes you can issue for each version of an app, limiting your ability to convert previous non-App Store customers, to support journalistic requests for licenses, or to have giveaways.

That’s all old news, certainly, but worth the recap.

Releasing outside the Mac App Store

The converse of most of the above is of course true for releasing apps outside of the App Store, as follows.

Non-App Store Pros

  • On the whole, your total ongoing outlay (payment processing fees and bandwidth costs) probably won’t be as much as 30%, notwithstanding the price you put on the effort of managing updates, implementing the mechanisms the App Store provides, etc.
  • You decide whether an application is suitable for release. No-one can stop you releasing it.
  • You can release apps (and updates) instantly.
  • You can address customer issues directly and immediately, including with refunds and/or personalised builds.
  • Your app’s storefront doesn’t have ‘unfiltered’ customer reviews tacked onto the bottom of it. (Unvetted customer reviews are always ‘filtered’, of course, in the sense that only certain types of people complain publicly about issues they’re facing without first trying to resolve the issue).
  • You can offer demo versions, with appropriate limitations and registration-incentives.
  • You can offer paid upgrades, thus keeping your product (and business) alive.
  • You have far fewer technical limitations in terms of what your app can do.
  • You can respond to customer issues privately, as should be the case.
  • There are no limitations on promo codes, discounts etc.
  • You can choose your own storefront presentation, and your customer-facing messaging generally.
  • You can create more of a relationship with customers; the App Store very much encourages a “disposable purchase” mentality on both sides.

Non-App Store Cons

  • You need to provide your own licensing/registration system
  • You need to provide your own storefront, purchasing and fulfilment system
  • You need to pay for your own bandwidth, for downloads/updates
  • You need to provide your own updating mechanism
  • You are fully exposed to customers
  • You don’t have as much long-term visibility/searchability/discoverability as you would on the platform’s centralised store, though you can offset this somewhat with marketing

This article isn’t intended to be read as an outright condemnation of the App Store. It’s a valid delivery platform, if you can live with its constraints. It brings its own benefits. You can have a very successful business based solely on it. I’d advise you to at least try to release your software via the App Store initially, even if it’s not your only outlet. The process of preparing and submitting an app for the Store has become much less painful in the last year or two, and is a far cry from the relative agonies of the iOS App Store in its first year.

In some situations, though, you’re going to want to also (or instead) release software outside of (or “outwith”, a wonderful Scottish word meaning that very thing) Apple’s store. For developers who are considering doing the same thing, I want to talk about how I addressed the “Non-App Store Cons” section above with my app Sticky Notifications, so you’ll be able to get your software out there more quickly and easily.

Stuff I find scary

A brief digression, if I may. There are some app-development tasks that I find easy and enjoyable, and some that I find scary and/or daunting. I have no way to know how well I intersect with you on this, dear reader, but I suspect we have at least a few factors in common.

From the perspective of designing, building and releasing an app, here are the things I find fun:

  • Coming up with the idea, and choosing features.
  • Architecture design. Classes and protocols and properties and such.
  • User interface/experience design. I know that many people find this part daunting; I just happen to enjoy it.
  • Writing about all of the above.

Here’s the stuff I find a bit of a chore, though not awful:

  • Coming up with a name for the app. I like to know the name before I make the new Xcode project, even though that’s totally unnecessary. I have a weird hang-up about this.
  • Debugging. Boo.
  • Testing. It’s a reminder that even I make mistakes.
  • Making icons. The concept is beautiful in my head, but my Photoshop skills fall short.
  • Supporting non-current OS versions. Damned Luddites.
  • Non-Objective-C APIs generally. Life’s too short for C.
  • Manual memory-management. It’s long since become instinct, but it’s still a cruddy thing for a human to have to know or care about. All hail ARC!
  • Dealing with Xcode. You can only ever love Xcode in the sense that, after visiting the site of an ecological disaster, even your dilapidated, graffiti-covered, urine-soaked local park seems vaguely pleasant by comparison. A relationship with Xcode is basically abusive, but I have nowhere else to go (I don’t like that Java-based IDE; I fear change).

And finally, here’s the stuff I find actively scary:

  • Anything to do with taking people’s money. The actual order-processing, etc. Maximum fear.
  • Anything to do with cryptography. I get it, but I find it daunting, and I have to refresh my memory regularly.
  • By extension of the above, anything to do with license keys and serial numbers.
  • Updating and patching apps on the user’s system. I am terrified that things will go wrong, and leave the app horribly broken.
  • Having to know (or guess) how much bandwidth I’ll need for something. I fear what will happen if I go over some kind of limit, then sites or apps just disappear. And what if I’m away from my office at the time? Not good.
  • Anything to do with piracy and cracking apps, and combating same.

The astute reader will notice that my list of fears above are essentially all of the exact things that the App Store does for you. I don’t think this is coincidence. As a developer, I want to do the fun bits, a bare minimum of the “due diligence” bits, and ideally none of the scary bits. The idea of having to deal with the scary bits has the potential to sabotage my enthusiasm for the whole project. I bet that you’re at least a little bit similar.

I conquered my fears, of course, as many of you have, and I can conclusively say: there are pretty easy and quick solutions for all of the scary stuff. I don’t mean “easy and quick” to some kind of genius-level person who blogs about fiddly details of the runtime, or what actually happens when you swizzle a method, or any of that stuff. Yuck. I’m not that guy. Sometimes I’d like to be, but I’m just not.

Truth be told, I don’t even want to have to put that knowledge into my brain, ever. There are far cleverer guys than me who I can ask when I need to, like Graham or Mike. Or maybe even you.

Instead, I’m the kind of developer for whom “developer” isn’t the primary way I characterise myself. In this context, I like to think of myself as an “app maker”. Development is only one part of that, albeit a big one. I’m not hardcore; I just focus on the bits I’m good at. I’m pretty good, sure – but I know my limits. I think you’re probably the same. I think I can help you.

So let’s talk about those scary parts, and how you can pretty easily and quickly deal with them, so you can release your actual app like you want to. We’ll deal with the scary bits in the order I listed them above.

Scary money stuff

My perception: Taking people’s money is incredibly complicated, frightening, and prone to hideous legal problems.

The reality: It’s easy: get someone else to do that for you. There are loads of payment providers out there who are savvy about software. Whatever problem you’re anticipating, someone has thought of it and made it easy to solve.

Suggestion: Personally, I use FastSpring (@fastspring). They set my account up quickly, their web administration UI is fantastic, and you can do any of the stuff you’ll want to do. They integrate with popular licensing mechanisms, they let you do coupons and discounts, it’s easy to make custom order-confirmation and license email templates, and so on.

You can get paid every 2 weeks via direct bank transfer, and the threshold for payment is really low (mine is $25). Issuing refunds is easy and instant, and completely under your control. They handle VAT and all that stuff. You can do secure file downloads. Their rates are really reasonable; either 5.9% plus $.95 per order, or a flat 8.9% per order. You can choose which rate you want.

They also have in-app store SDKs for Mac and Windows on github, which is absurdly easy to integrate into your app. You have the option of generating licenses remotely or on FastSpring’s own servers, or you can supply a big list of licenses to use up.

How long it’ll take: They set up my account pretty much instantly. Configuring the store and products is all via the web UI; there’s no horror. Setting everything up for Sticky Notifications, including the license integration and email templates, took me maybe half an hour. Integrating the in-app store into my app took about the same. I’ve been using them for quite a while now, and they always pay on time with zero hassle. I’ve never even considered switching.

Notes: Testing is easy too. You just flag a product as being in test mode (newly-created products are of course in that mode by default), then you can place orders without being billed. You can do the same from the in-app store, and can even place test orders for fully active products with a single parameter.

Scary crypto and licensing

My perception: Generating license keys is an obscure, black art. I’ll have to read stuff for hours or days to do it, and even then my license keys will be crappy.

The reality: A cleverer person than me already fixed that. There are open source licensing schemes out there, with Cocoa same projects and integration, ready for you to use. Your payment processor may integrate with them already (FastSpring does for mine). It’s actually simple to generate licenses that are tied to the customer’s personal info, and to validate/verify licenses in your app.

Suggestion: I used CocoaFob (open source; github) by Gleb Dolgich. FastSpring knows about it natively, so it can generate licenses for you without your (or your own server’s) intervention, if you want.

How long it’ll take: To enable license generation for orders on FastSpring, it’ll take you about 2 minutes. To verify those licenses in your code, it’s a few lines of code; say you allow ten minutes for that. Then you need to do the stuff that makes your app behave differently once it’s registered – that’s up to you!

I also spent an extra ten minutes making a license-generation/verification tool to use locally here, for friends/journalists etc, and a further maybe fifteen minutes supporting a registration URL-scheme in my app. FastSpring also supports providing those URLs in license emails automatically, which is very handy.

I bet you can go from no-clue-at-all to a fully working license scheme in an hour, or two hours max. Then test it, of course.

Notes: Since CocoaFob uses DSA asymmetric crypto to do its thing (don’t worry if you don’t know what the hell that means), you’ll want to obfuscate your public key inside your app. Don’t just include the key file in the app package. I found a useful example of doing it in this file on github, which is inspired by Aquatic Prime, another option instead of CocoaFob.

Scary updating

My perception: Updating apps automatically is a veritable maelstrom of potential nightmares, with broken apps and agony all round.

The reality: It’s ridiculously easy. You have absolutely no reason to worry about it at all.

Suggestion: You must of course use the super-fantastic Sparkle. It’s already used in about forty apps on your Mac right now.

How long it’ll take: For the initial integration and setup, you’re talking about 30 minutes to an hour. For each update you push, maybe ten minutes just to update the appcast and sign the binaries and such. The documentation is clear and easy to follow. You won’t have any trouble.

Notes: You can include release notes in your updates, which Sparkle will show inside your app for the user to read. It can do ask-first updates, or automatic downloading. You can pick how often it checks, including at startup or not. It can even send back anonymous info so you can see what OS versions people are using, and such. It supports delta/patch updates, to save time and bandwidth.

Scary bandwidth and storage

My perception: I have no idea how much bandwidth I’ll need for all these downloads and updates, or what it’ll cost me. My puny hosted server will die. People will be angry with me.

The reality: It’s taken care of. You can get silly amounts of bandwidth for stupidly cheap prices. It will not fall over. Things will be fine. You won’t need to touch Linux or Apache or any of that crazy nerd gear.

Suggestion: Use Amazon S3. Whilst the pricing structure can seem confusing at first, let me simplify it for you: it will cost you really really small amounts of money every month to use really a lot of bandwidth. I’m talking about a-few-to-a-few-tens of bucks per month for what you’re probably planning. Very likely less than that. Setting it up is trivially easy: you sign up, then set up a “bucket” (a particular chunk of storage), and upload your stuff to it. The web console is easy to use, and file-transfer apps like the ultra-sweet Transmit know about it too.

How long it’ll take: From initial sign-up (with automated identify-verification by it phoning you, and you typing a PIN into the phone), to making a bucket, to uploading your first stuff: you’re talking about ten minutes.

Notes: There’s a totally free tier of S3 too. You get it automatically for the first year. You’ll only be charged if/when you go over its limits, or after the first year.

Scary piracy

My perception: Apps will be pirated.

The reality: Yes, that will happen, no matter what you do. Guaranteed. Can’t stop it. Can’t prevent it without (unreasonable, for most cases) amounts of effort. It happens to App Store apps too, all the time.

Suggestion: Seriously, don’t worry about it. Most people don’t pirate stuff unless it’s trivially easy to do so, and/or you make legitimate purchasing unduly difficult or expensive (see The Piracy Threshold).

Just accept that it’s going to happen, and don’t lose any sleep over it. Take it as a compliment that hacknerds want your stuff. As long as enough people do actually pay for your software, what do you really care anyway?

How long it’ll take: To not worry it? Zero minutes. Do something fun instead.

Notes: Maybe read a book? Not a technical book. A novel. Or head to the pub for a while.

Final thoughts

That’s about it. As it turned out, there was no need for me to be scared about the stuff I needed to do to recreate all the stuff that the App Store provides. If you don’t manage to get onto the App Store (or even if you do), there’s another way you can get your apps out there, and it’s not much extra trouble.

The “scary” stuff listed above can be done in just a few days, without head-scratching or undue discomfort, and after you’ve done it once you’ll be good to go much more quickly the next time.

The development process which inspired this piece, as I said, was for my Mac app Sticky Notifications. You can find out more about it (and download a copy) here; I hope you’ll have a look. If you enjoyed this article, buying a license (or something from my Amazon Wishlist) would be a good way to say thanks. And you look like a cool sort of lady-developer or gentleman-developer.

I also wrote an article about the various measures I took to make Sticky Notifications (including its registration system and in-app store) as user-friendly as I could.

If you want to get in touch (or stay up to date), I’m @mattgemmell on Twitter, and indeed also on app.net. Good luck with your app.