This is the third in a series of posts relating to the making of Soundproof for iPhone. See also: part 1, part 2

During the process of making Soundproof, we had to consider what the business model would be. I wrote some early thoughts about pricing and talked about some issues with implementing upgrade pricing with In-App Purchases previously. Here, we’ll take a brief look at the experience of implementing In-App Purchases and the user experience.

You’re most likely a professional so you’ve already read Apple’s documents about implementing In-App Purchase. It turns out that while Apple handle most of it for you, the nitty-gritty of getting the user experience right is rather tricky to get right.

In the case of our app we made it free and require an In-App Purchase to remove a 30 minute per week practice limit, and offer another purchase to unlock “pro” features. This decision was made so that iPhone 4 users can receive all the features at no cost (much like Marco’s Overcast) because future versions may require iOS 8 which will not be available to those users.

This decision to charge for features has broad user experience implications. Once you have established what you will actually charge for, you must carefully choose your “choke points” where you will prevent the user from using your app fully, and how you will introduce them to the option to pay to remove the barrier.

Apple goes to great lengths in various places to explain that making the purchase process as smooth as possible is critical to maximising your conversions (a conversion is when somebody buys something they previously did not have). This makes common sense, but is a multi-faceted problem. Separate from this is honing your marketing text in the purchase screen to enthuse people about purchasing¹.

We’ll take the 30 minute practice limit in Soundproof as an example. Users will use the audio player to practise, getting the full experience of using the app. Once they have played audio for 30 minutes in a given week, it will stop playing and show them an alert explaining that they can just wait until next week, or they can unlock it now.

At this point we could have automatically presented the modal In-App Purchase “store” screen that we have, instead of the alert. However we felt this was too heavyweight. If people want to buy, they will do so. If they want to practice 30 minutes for free, we’re fine with that and not having the entire player UI obscured when they hit this weekly limit feels less intrusive. By showing an alert — ugly though they may be — we give the user the feeling that it is entirely their choice. In pure efficiency terms this adds an extra tap for people who do want to purchase, but the experience is softer.

An interesting example of another choke point is the Repeat Markers feature. Here, we wanted people to be able to use the markers, but without bloating our code with complicated limits. So we decided that users would be able to add markers once per track, but once they switch out of repeat markers mode, they cannot go back in without passing through the choke point.

In each case we have a different message in the alert to explain what they cannot do and what they will get if they unlock it. Avoid generic “Pay to unlock this” messages, as you are in effect having a sales conversation with the user at this point. “Fuck you, pay me” is not the right sentiment in this context.

As mentioned in part 2 we have a single button for the repeat markers workflow which changes its title from “Add marker” to “Set end marker” to “Delete markers”. In the case of when we need to introduce the choke point, we change the title of the button to “Unlock markers” instead of the “Delete markers” in the state where markers have been defined.

This has the happy side effect of blocking the user from re-starting the marker definition process. If we didn’t do this, we would have “Delete markers” as an option, which the user would tap, but then be disappointed that they hit a choke point. By making “Unlock markers” the call to action on the button, the user is performing a deliberate action to buy.

The unlock screen itself is presented from multiple choke points as well as the Settings screen. Very briefly, the things to consider on this front are:

• Testing is very painful, so make a test plan document and repeat it every time you do a release²
• Make your “adhoc” beta test builds unlock everything for free, but not your developer builds so that you can verify IAPs work using sandbox accounts. Don’t even think about getting beta testers to use iTunes Connect sandbox accounts
• Have a message in your unlock screen that makes it clear whether IAPs have been unlocked for free or not — to avoid testing confusion
• Pre-load your price information at strategic points so that the user doesn’t have to wait on your unlock screen. Contacting the App Store to do this can be relatively slow. Test price downloads a lot. Lots of things can fail, and your user should never see a “nil” price
• Make sure you handle StoreKit errors properly. There are many scenarios including network outage, but you should not usually tell the user what happened. StoreKit already lets them know about most issues, so be careful and usually don’t do anything except reset your UI
• Have some sensible UI that screams at you if your product ID can not be resolved against the App Store. This will save your sanity
• Remember that purchases can complete at any later point, especially with iOS 8 “Ask to buy”

Finally, some words of caution about using free plus In-App Purchases as a business model. In my experience it can negatively affect your marketing. You cannot get promo codes for In-App Purchases (despite Apple trialling this earlier in 2014). You cannot gift In-App Purchases either. You can gift iTunes credit to people, but only if they are in the same App Store territory as you, and only above a minimum payment limit. I couldn’t give the minimum £10 iTunes credit to every journalist just so they could purchase £3.49 of features — and even if I could, most are not using the UK store.

Some press also wanted to have competitions where they would give away unlocked copies to users, which was also not possible with this model. You can offer to pay iTunes credit to the winners, but it all becomes very fiddly for such little gain, and it is not worth the time of the outlet to deal with you. Again, the store territory would break this too.

Hopefully Apple will offer In-App Purchase promo codes some time soon to solve this problem. Until then, the only chance you have is to give beta access to the press — perhaps this will be less painful for the press when TestFlight is properly rolled out. Still they will not get long-term unlocked copies which is seen as a bit of a perk of being a reviewer.

Soundproof — Music Player for Practice is available in the App Store for free with In-App Purchases. The makers Marc and Adam are available for contract iOS app development.