The what

Starting with Lion’s release Apple allows Mac apps on the Mac App Store to utilize In-App Purchases (IAP from now on). This means that an application can sell additional functionality or “stuff” to existing customers. This has been allowed for quite some time now on the iOS App Store but it’s new on the Mac.

One of the important aspects of IAP, from marketing point of view, is that they allow the developers to put an application for free and then sell additional functionality. Obviously, this is very popular with games. You can’t create time-limited or otherwise blatant trials with this, as Apple’s rules don’t allow trial version on App Stores, but you can create something similar, if you find a balance between the free and paid features.

This is all great if you write a new application, but things start to get complicated if you already have a non-free application in the store.

The now

Here’s the situation: we have an application that you can buy either on the Mac App Store or on our site. On our site we have a free trial, and 2 levels of licenses: Standard and Pro. So a person will download a free trial and then buy one of the licenses. Moreover, one can upgrade from Standard to Pro by paying the price difference. All this is pretty standard stuff in software licensing.

We were on the Mac App Store from day one, so we couldn’t create such a Free/Standard/Pro version, since IAPs were not available. Instead, we opted only to put the Standard version on sale, without calling it Standard.

The goal

Now we want to provide all this Free -> Standard -> Pro upgrade path with IAPs instead of the current paid version. Ideally, we want to replace current ImageFramer listing (which is paid only at this time) to the IAP-enabled one. Of course, all the people who already bought the application previously should get the Standard functionality, for which they already paid for.

The WTF

And here we hit it. There’s no way, which I’m aware of, to determine in the next, free, update of the app that the user already paid for the previous version. I’ll elaborate.

Joe, a happy customer of current version paid the full price for the software. The next update brings the Free+IAP model. The customer updates the app and he gets only the functionality of the Free version. This happens because he has not purchased the full-version functionality as an IAP. But Joe doesn’t care about that. He leaves a raging 1-star review on the App Store. If Joe’s a geek, you’ll also see his rage on the first page of Hacker News. Obviously this is not the kind of publicity that a developer would want. I don’t subscribe to the notion that every publicity is good publicity.

The why

The major problem lies in the StoreKit and the receipt, which Apple sends with the purchased application. The receipt does not contain information about the purchase. It doesn’t contain which version of the application was purchased originally. It also doesn’t contain the Apple ID (which you could use with your server to register purchases, for example). Using computer’s ID is not a good identification since Apple ID allows installs on several Macs.

Checking values that could identify full functionality in the application’s preferences doesn’t help. Even if I can check that the current installation was already using full functionality, I can only enable and remember it for this specific installation. If the the customer deletes the preferences, or simply chooses to install the application on his another Mac or he reinstalled the OS, this information is lost, can’t be restored, and we’re back to square one, with a trial-like version for which the customer had already paid. That’s not acceptable.

We also don’t want to create a separate, new, application in the Mac App Store, call it “ImageFramer Free” and use it in parallel with the regular ImageFramer entry. It’s one more release to maintain, it’s split ratings, duplicate management in iTunes Connect and it’s confusing to customers.

The solution?

Well, I haven’t yet found a solution that will satisfy all the requirements. There’s nothing far fetching in what we’re trying to accomplish here. I read about similar issues in the iOS world and nobody found a solution for that either.

Unless there’s something that I missed, the ball is on Apple’s side, which is rarely a good sign for developers. The easiest solution as I see it: Apple should add to the receipt which version of the application was originally purchased by the customer. We’ll simply see if this was a version before IAP or after, and act accordingly. Alternatively, I don’t mind having a StoreKit method that will retrieve the same information.

If anyone has a solution that will solve this in the existing situation, please share.