(Originally published in 2012.)
Last year, I had a great idea for an Mac app to make my life easier. I loved using drag-and-drop to move things around on my Mac, but sometimes, it was a pain to navigate the windows on my screen while I dragged a little icon around – I really wished I could just set the icon down for a moment and come back to it. DragonDrop solves this, acting as a sort of coaster for my virtual drink. It activates with a quick shake of the mouse while dragging, staying out of the way the rest of the time.
I spent months developing it, trying to find the perfect interaction methods, polishing it to the best of my ability. On January 31st, I hit my self-imposed deadline and submitted it to the App Store. I even went out to dinner with my lovely fiancée to celebrate the milestone.
Weeks passed, and I didn’t hear a peep from Apple. I sent them multiple emails, and was rebuffed each time.
After three weeks, I finally received word that Apple had rejected my app. Over the next few weeks, I repeatedly tried to work with Apple to come to some sort of compromise, but without any luck. Unfortunately, they rejected the primary action of the app – shaking your mouse to open it up. What was I to do? Give up?
Of course not. It was time to go indie and make my own App Store. But what would that entail?
Of course, people sold software themselves for decades before the App Store came into existence. While the simplicity and substantial audience size of the store were appealing, I didn’t have much choice.
Let’s look at what’s needed to operate outside of the App Store.
That’s not such a long list. Let’s go through these one-by-one.
If you wanted to, you could sell your app in the Mac App Store without any other online presence. Apple categorizes apps and hosts your downloads. Despite that, you’re still quite likely to have a web site, and probably a Twitter feed, too. Instead of having an “Available in the Mac App Store” button, you just need your own “Download” button. Just make sure your server can handle the spikes in popularity that your app is likely to face – there’s nothing worse than losing eyeballs because you skimped out on your hosting.
Unfortunately, the App Store has a serious leg up when it comes to the installation experience. The App Store lets users install apps with just a few clicks; you need to walk them through downloading your app, copying it to their Applications folder, and running it. Each one of these steps offers substantial chances for people to get confused and give up.
You basically have three options for packaging your app:
Just zip it up. This is the easiest, but it’s quite likely to leave users with a copy of your app in their Downloads folder and nothing to show for it. If you’d like to pursue this strategy, you can make it a bit smoother by having your app detect that it’s being run from the user’s Downloads folder and have it offer to move itself to Applications. (Hat tip to Andy Kim at the Potion Factory for pioneering this idea and putting a solid implementation into the public domain.
Make a disk image. These are a pretty common way for Mac software to be distributed. You make a disk image with your app and a shortcut to the Applications folder, and then customize it with a background image containing instructive text. These work pretty well, but some users aren’t sure what to do once they copy your app to Applications.
Make an installer. This guarantees that your app will end up in the right place, but you may alienate people who just wanted to take a quick look at your app without committing to it. Installation feels like a commitment.
With DragonDrop, I chose option #2. DropDMG makes it pretty straightforward to create an attractive DMG. There’s still a risk that users will get confused, though – some people won’t know what to do after they drag your app to Applications, for example, and a whole other group will just run your app directly from the DMG. For future releases of DragonDrop, I’m contemplating adding an installer to the disk in addition to the .app file.
As developers, we’ve been spoiled by the App Store, which doesn’t support demos at all. Our users have suffered, though, and if they’re going to buy outside of the App Store, they’re not going to part with their money sight-unseen. You’re going to need to offer some form of demo or trial mode.
How you want to structure this is entirely up to you. Broadly speaking, you have two options:
I opted for a full-featured trial with a short timeout. While longer-term trials give your users more time to get used to your software, they generally delay purchasing. Your customers are the most engaged when they’ve just added your software to their system: leverage that.
Although some people try to make money by releasing their software as “donation-ware”, I’ve found that to be unsatisfying. As a user, I enjoy owning the software I use – being an anonymous contributor to a random project is much less satisfying.
This leads us directly to license keys. Writing a license key system is an interesting proposition, because you can go as deep as you want into the project. You could write a relatively simple system using hashes, or you could go all-out and make use of public-key cryptography).
CocoaDevCentral has an interesting discussion on the topic – no matter what approach you choose, there are some good guidelines for hardening your code.
That being said, I personally favour a relatively simple approach. There will always be people who try to steal your software: don’t pay them any mind. Put your effort into building good software for your loyal users and you’ll be much happier developer.
Of course, you’ve got to find a way to collect money from your customers before they can get their license keys. Your should have two goals for this part of your product:
In DragonDrop, when the trial is up, users are greeted with a dialog that offers them the option of quitting, entering a license key, or buying the app. If they choose to buy the app, they do so from a dialog, not from their web browser. This helps contain the flow and prevents users from getting lost or distracted – your users just want to unlock the app and keep working.
This flow may be the most important part of the application – take your time with it. If it’s confusing, complicated, or feels unsafe, you’re going to lose people. Make entering credit card information easy, and let people know how their card will be handled.
Make sure the registration happens automatically once they purchase your app – making them copy-and-paste a license key from one part of your app to another makes the whole experience feel hacky and cheap.
Finally, make sure users know what their license information is, in case they ever reinstall their computer or switch machines. Email them a receipt with their licensing information in it, and make sure you save a copy somewhere, too. People are going to lose their information: make sure you can help them.
Credit card processing is notoriously painful to deal with. A startup called Stripe is changing this, though, and offers a phenomenally easy solution for accepting credit card payments. They offer a great SDK for multiple platforms that takes the hassle out of the whole process, and they prevent you from ever having to handle sensitive user information. Best of all, their rates are extremely reasonable: 30¢ per transaction + 2.9%. If you’re selling your app for $5, that’s the difference between netting $4.55 per copy and $3.49 per copy in the App Store. It’s a big deal.
Even if you’ve set up Stripe, your job isn’t necessarily done. Some users won’t have a credit card, and others won’t want to trust you with it. Consider supporting PayPal or Google Checkout. I’ve found that users who are operating outside of the default flow are generally pretty patient. For DragonDrop, I haven’t automated PayPal purchases: I just include a note asking folks who’d like to use PayPal to email me, and we conduct the transaction over email. It’s not perfect, but it works, and I gained some customers I’d never have reached before.
The final piece of the puzzle is around software updates. Getting users to stay current with your releases is an uphill battle – you want to remove as many barriers as possible. Sparkle is a free framework that takes all of the effort out of this – it’s pretty amazing. You’ve probably used already encountered Sparkle: if you ever see an update dialog offering to “Install Now” or “Install on Quit”, that’s Sparkle. The ease of integration here is mind-boggling, and Andy Matuschak deserves a serious tip of the hat for his efforts creating it. You’re only about 30 minutes away from having auto-updating software: use Sparkle.
If you’ve ever sold an app on the App Store, you’re familiar with promo codes to hand out review copies. You should consider implementing something like this for your own software. They come in handy when giving out review copies, but they also fit perfectly into the manual PayPal purchase workflow I’ve got in place.
DragonDrop’s promo codes are actually URLs, so I can get people to register and download the app in a single step.
So, that’s what you need to go indie and sell your app outside of Apple’s walled garden. To be honest, if you can sell your app in the store, you should consider it – but the additional time investment required to also sell independently pays off pretty quickly. A few days of extra development are all it takes.
Selling independently lets you publish updates on your own schedule and control more of the user experience, all while offering you more direct access to your customers. You have more flexibility in how you accept payments, and have to give up a much smaller percentage of your proceeds.
Plant your product in the walled garden if you can, but don’t be afraid to sell it in the wild, too. At the very least, you’ll learn something new.