views:

226

answers:

2

I am near the end stages of developing an iPhone application and will be releasing it as both a 'lite' (ad-supported) version and a 'pro' (ad-free, likely with additional functionality at some point) version.

I've followed suggestions here and elsewhere about creating multiple targets, etc. and am able to build these without any problems.

But this does bring to mind a question: What is the best, most user-friendly, accepted way in which to handle transitioning from a lite version of an app to a pro version?

As I see it - and please correct me if any of my assumptions are wrong - there are potentially two ways to do this:

  1. Give each application its own Bundle identifier (ie. com.companyname.fooapplite and com.companyname.fooapppro). This will result in both being treated as being completely separate entities. Data is not automatically migrated should a user move from one to the other and both could very well have both installed on the same iPhone at the same time.

  2. Give each application the same Bundle identifier (ie. com.companyname.fooapp), so that they are treated as essentially the same application. The lite version of the application will be overwritten by the pro version if they download and install it. Data from the lite version is maintained in the pro version.

The latter seems ideal to me - I can't imagine someone wanting to keep a lite version after they've just purchased a pro version - but this brings up a few questions:

  • Does Apple even allow option #2?

  • Will using option #2 result in any goofiness I should be aware of, ie. the two versions stepping on eachother in some way.

  • If it's not allowed, is there a suggested practice in place to migrate data from what are basically two completely different applications? I'm aware of StoreKit, but it isn't supported on free applications.

As it is, this current app doesn't really generate data of huge value and the worst thing that will happen is users will have to re-enter some authentication credentials upon upgrading to pro. But down the road, if I were to develop a similar app that stores valuable data locally, I'd like to know how to best transition users and their data in a seamless manner.

Thanks,

  • Jeff
A: 

I have not tried this myself, but a third option to exchange small amounts of data is to use the Keychain API. Apps that share an identifier stub -- com.companyname.foo as a parent to com.companyname.foo.fooapp and com.companyname.foo.fooapplite -- can supposedly write to the keychain from one app and read from the other. Haven't seen this done, but a lot of people claim it's possible. And in any case, the keychain is probably a good place to be storing things like authentication credentials.

Option four would be to have the lite app store some user data on a server you operate, and have the full app retrieve it from there, but there are all kinds of problems with that approach.

invalidname
Thanks for the quick response! Interesting idea with the keychain approach. I hadn't considered that option, and it might be applicable to my current project.As for storing data on a centralized server, that's (in a nutshell) what I'm doing with this app I'm working on - and why it's not incredibly important that I save anything locally with this app.The scenario I'm thinking of is, ie. a note-taking app, where significant amounts of user data is created that they might rightfully want to retain.
+1  A: 

One more option is to exchange data from the Lite to the Full version via a URL. Register a myFullApp URL with the full version and have the Lite app present an upgrade option that calls that URL with the various data you want to exchanged encoded in it.

That does require the user fire up your Lite version and hit a button, but it's fairly simple too.

mousebird
Mobile Orchard actually has an article on this approach: http://www.mobileorchard.com/lite-to-paid-iphone-application-data-migrations-with-custom-url-handlers/
Brad Larson