You’ve just submitted your first Mac app having a number of in-app purchases. A few days later, your app got rejected and this is what the reviewer said:
2.6: Apps that are “beta”, “demo”, “trial”, or “test” versions will be rejected.
You sank in your chair, feeling miserable with that sinking feeling: “.. those months of hard work are going down the drain”.
Well, fear not. The battle isn’t over yet and you’d probably only meed to tweak your app a bit to get it App Store worthy. In this post you can learn a few user interface techniques to get your app “app store worthy” when it comes to in-app purchases. These are proven techniques used by existing apps currently selling in the Mac App Store.
The Purchase Label
The easiest — and perhaps the most widely used — method is to append a “
... (Purchase)” suffix to command labels that invokes an optional feature which needs purchasing. For example if the menu item label for the optional feature is “
Do Magic...” then the label should show “
Do Magic (Purchase)...” if the user hasn’t bought the feature (note the ellipsis since this command brings up an additional dialog of options). Selecting the command will bring up an App Store purchase prompt instead of showing the “
Do Magic” dialog if the user hasn’t bought the item.
One app that uses this method is Klammer, a file viewer for Microsoft Outlook files. They do this in two places: a button in a dialog and a menu item in the main menu bar. Klammer has an optional “bulk convert” feature to transcode multiple Outlook files into a something that the built-in Mac Calendar and Mail apps can understand.
Clicking on either the “Bulk Convert” button in the welcome screen or the one in the menu bar brings up a own dialog showing the benefits of the purchase and allows you to go ahead purchasing this item or to restore the purchase if you have bought it earlier.
This technique directly fulfills the following extended description that normally accompanies the “app is trial” rejection reason:
Non functional features/buttons should not be present in the app until they become functional. Such buttons must otherwise be clearly marked as requiring a purchase.
Thus adding a “
…(Purchase)” suffix clearly marks that the command will invoke an in-app purchase prompt,
The Phantom Option
GarageBand – now an App Store offering on the Mac – asks for more money by showing an option that appears to be disabled but actually clickable. When you select one of these grayed-out options, GarageBand shows its own dialog showcasing the benefits if you purchase. Only if you click through this option then GarageBand will show you the App Store login and purchase confirmation.
You can see this for yourself if you haven’t purchased the Complete Set of Content in-app purchase item.
- Open GarageBand then create an empty project.
- Select the Software Instrument.
- In the left hand Instrument library, select Guitar and then click on “Classical Acoustic Guitar”
- You’ll see the “Add More Sounds” dialog which eventually will lead the App Store in-app purchase prompt.
Take a look at the above screenshot from GarageBand. It looks as if the instruments below Classic Clean guitar are disabled. However unlike normal disabled controls, clicking these brings up something (which is the prompt to purchase those instruments as part of a bundled set of features).
This phantom option method of doing in-app purchases may be slightly harder to implement than the purchase label strategy described earlier. You will probably need to create a custom control which looks disabled but in reality still responds to clicks. You also would probably want to centralize handing of these in-app purchases (if you’re doing something similar to GarageBand since multiple buttons could trigger the same feature but may be doing slightly different things when the feature is purchased). On the other hand the purchase label technique can be achieved by just changing the text of the menu item or button.
Strangely enough having a greyed out button does not clearly mark it as requiring a purchase (as per the app store rejection details may have told you). But since Apple themselves uses this technique, you could just say that you’re following their lead. Thus if you go with this method and got rejected, at least you can appeal and say that you’re just following GarageBand’s example. Let Apple sort it out internally.
The Mini Store
Still probably the most heavyweight alternative will be having your own “feature store” within the app. List down all optional features in its own window and allow the user to purchase them one by one just like the App Store itself. It’s like having a “mini app store” inside the app. Then you could simply disable or hide all un-purchased commands to comply with Section 2.6 of the App Store Review Guideline.
Granted, this would only make sense if you have a good number of optional features to offer. However if you have consumables or subscription items, you would probably need to have something like this anyway – something that’s quite common for freemium games or periodicals, but may also applicable to non-game apps. Say for example if you’re making a finance app and you charge money for blocks of 100 financial reports, you’d probably want to have a screen saying how many reports that the user can generate and to allow buying credits to create more reports.
One app that uses the Mini Store approach is Easy Books. This is a finance app for micro businesses – primarily self-employed one-person companies. Easy Books is free to download but you’ll need to buy a good number of in-app purchases to do anything serious. Furthermore it offers online syncing as a subscription item that necessitates a “mini store” to be present for the user to manage his/her subscription.
Easy Books’ “feature store” is accessed via a button on the right side of the title bar, just to the left of the full-screen button. Yeah, it’s a rather odd place to place a button there but it’s space saving, obvious and easy to find.
Last But Not Least
Whatever approach you ended up choosing, make sure you tell the App Store reviewers about your decision. In the review notes, you’ll need to mention an existing app in the store that uses a similar technique (and include the App Store link to the app, just to be sure). Essentially you’re justifying your approach by showing a precedent.
Better yet, you can refer them to this article and say which technique(s) you used in your app ^_^ Since I’ve already detailed each method complemented with existing apps in the store with links and screenshots, linking to this article saves you time from collecting those links and screenshots yourself to include in the app review notes.
Thanks for reading – until next time!
Do you enjoy this post? Enter your e-mail address below to receive articles like this one in your mailbox.