One of the loudest complaints about the iPhone AppStore has been the lack of support for eval or demo applications. In the desktop world users can often download an application and use it for a period of time before deciding whether it’s worth paying for. But in the iPhone AppStore universe (where all transactions occur) there is no such support. Developers are then faced with the option of offering a lite version for free (or inexpensively) and a full version of their apps. The problem is that this still doesn’t allow the end-user to test out the full app and then choose to buy it if it fits their needs. And switching from a free to a full app involves installing an entirely independent application.
What we really need is a way to upgrade an eval app to the full version once the user decides the app is worth paying for.
Yesterday Apple publicly announced the developer release of iPhone 3.0 software (it won’t be publicly released until this Summer). To the dismay of many developers, there was — once again — no mention of support for eval applications among the 100 new features and “1000 new APIs.” So again, we are left without the option of letting users download an app, take it for a test run and then pay for it.
Or are we?
One of the features announced publicly was support for In App Purchases. This was presented as a way for users to obtain add-on levels or objects directly within games. The transaction (or more precisely, micro-transaction) still goes through the AppStore and gets charged to the same account. Despite public detractions I belive this is a Good Thing — especially since the feature can be used to legitimately support eval applications, even if the AppStore doesn’t officially support it yet.
- Developer offers application for free on the app-store. This is a fully functional version (i.e. not lite or crippleware).
- User downloads and runs the application and is informed that the application is in eval mode and will stop working after a period of time.
- After the eval period (say, 1-4 weeks) the application puts up a notice indicating the eval period has expired. It can either stop working or drop into a degraded mode.
- At this point the user is given the option of performing an In App purchase of the full application.
- If user accepts, the application contacts the AppStore and purchases the add-on — which would be priced at what the full-price of the App would otherwise be. Once completed, the app downloads an add-on key indicating the app has been purchased.
- The presence of add-on indicates that the full app has been purchased and the timeout is taken out. All the application has to do each time it is launched is to look for the presence of this add-on.
- Everyone’s happy.
There’s a key assumption here — that the AppStore keeps track of already purchased In App purchases the same way it does with full applications today. In other words, if the user tries to re-download an In App purchase that they’ve already purchased with the same iTunes account, they shouldn’t be charged twice. If a user deletes the app or moves to a new phone, all they have to do is download the free version of the app, perform another In App purchase (for free this time) and off they go.
However, if this assumption is not true and In App purchases are tracked separately than full applications (or the application itself is responsible for keeping track of those transactions) then the developer will have to implement a way to track In App purchases that works across multiple app installs — most likely a simple web-server to keep track of eval vs. purchased apps. Let’s hope it doesn’t come to that (the documentation on the Store Kit is not out as of this writing and even if it was, developers under NDA won’t be able to talk about it publicly until the public release of the 3.0 software).
There are some other issues that need to be hashed out, mainly what happens if unscrupulous third-parties find out what this add-on looks like and make it available for free download? The iPhone application sandbox makes it a non-issue since only the application itself is allowed to write to its Documents directory or modify its user settings — unless the phone has been jailbroken, in which case the concerned developer may want to support more complex security (like cryptographic signing) for the add-on. Given that the AppStore DRM appears to be compromised using this technique does not significantly increase the risk of software piracy.
Another potential issue is the user who downloads the fully functional eval version, uses it for the full eval period, then deletes it, re-download and installs it so they can get another free eval period. If this is an area of concern, it can be handled through a simple web-service that keeps track of how many times the same user has installed an app. Personally, I don’t think it’s worth the hassle given that deleting an app also gets rid of all user-generated data. But that’s me.
Note also that when I’m talking about downlaoding something, I don’t mean literally downloading a chunk of code, but some sort of token that takes away the eval time limit. The whole operation can be performed very quickly once the In App transaction is completed.
I firmly believe having support for eval apps is critical for medium to high-priced applications to flourish on the AppStore. A user will hesitate to fork out a high price for a full-featured app without having the option to kick the tires beforehand. This method can easily solve the problem and let developers do eval apps as soon as the 3.0 software is officially released.
Update: Apple has since announced that free apps can not use StoreKit. This is to avoid a potential bait-and-switch situation where the consumer downloads what they think is a free app and then get hit with a fee. However, I think it’s a misguided policy. A developer who does that will quickly get down-reviewed (if they even make it out of the app-review chute). A more likely scenario would be to allow users to use an app for a limited period of time, but give them the option to unlock the app for continued use.
Another more fundamental issue, however, is whether app developers even want an eval feature. I’ve heard from several Android developers that the Android store return policy has severely impacted sales of their apps. Their argument is that returns should be based on faulty apps, not because someone found their game too hard. Presumably, enabling eval apps will cut down on a lot of impulse-then-discard purchases that go on today.
Certainly a topic worthy of further discussion.