How do I manage building a Lite vs Paid version of an iPhone app?

Question

I'm starting to get to the point where I want to consider building a lite version of my iPhone app. I've found a few things on the web that talk about the process a bit, namely:

http://developer.apple.com/tools/XCode/XCodeprojects.html

http://www.pacificspirit.com/blog/2009/01/27/building_for_multiple_iphone_targets_in_xcode

What I'm specifically interested in is simplifying the process of managing which files are included in the different versions of my app as I continually modify and enhance my paid for version.

Mariettamariette

Answer 1

Original answer is from the days before in app purchase. The correct answer now is to ship a single binary and offer your paid version through in app upgrades. It's slightly more code but it's a single shipment and your conversion rate will probably be better.

However, if you still want to versions of your app:

Xcode has good support for multiple targets.

From the project menu select "New Target...". Add another iPhone executable (Cocoa Touch Application) you can then specify on a resouce by resource basis which items are included in your target. This can include only compiling certain code into your paid version.

You can get quick visual feedback on what is and is not included in the current target by right clicking on the "Groups and Files" list header (top lhs) and enabling Target Membership.

You switch between building different targets in the same way as you switch between building for Simulator or iPhone.

To specify at build time how a specific class behaves you can do two things - include two versions of the class which are each built for their respective target or, you can set a build time flag for the pre-processor. Select the Target in the "Groups and Files" list then "get info" on that target. Go to the build tab and search for "preprocess". You should see a n item called "Preprocessor Macros" add LITE to your lite target and in the same way add PAID to your paid target.

Thein in your source files you can determine at compile time which version you are compiling for using #ifdef LITE etc.

Going even further, you could set a global flag or AppDelegate member variable based on #ifdef LITE and change behaviour at runtime for the Lite and paid apps. I'm not sure I see value in that though.

Cense

Vote up because it is a good technical answer, even if it competes with my philosophical one. – Spain

Thanks for your answer Roger.... How does the "Product" concept work with the different targets? Or is it something completely different all together? – Mariettamariette

producst are just executables Xcode builds for you. I'm suggesting setting up one product for your paid app and another for your lite app. They would each produce a different <productName>.app bundle to be uploaded to the app store. – Cense

Just a comment in case anyone comes along and reads this. In the current version of the iPhone SDK (2.2, xcode 3.1.2), the 'Preprocessor Macros' option has disappeared from the simulator, but it is still there on 'device' mode. – Deangelo

Answer 2

As a developer you want to write the least code possible (less bugs, less time). As the build versions diverge you will have to invest more work and separate tests.

Unless you are making an expensive hacker tool you might consider keeping the difference as simple as possible - just have some hidden preferences or settings. This way the majority of checks and tests will do the same work in both builds, very little code will be different. The key concern is not to burden yourself as a developer.

The reason to have divergent builds is to ensure that the Free cannot be hacked into a "Paid" version. The people who would try and circumvent such a simple limitation are primarily a sub set of those who would jailbreak their phones. No matter what you do you will not get their money under any condition other than they are so wowed they buy it just to show appreciation.

Spain

Voted up because it is a good philosophical even if it advises against using my technical solution ;-) – Cense

I completely agree, and I'm going to try and stay as close to my paid version as possible, without giving it all away! – Mariettamariette

Answer 3

The creator of "Flower Garden" details the pros/cons of different approaches to creating a lite version here:

http://gamesfromwithin.com/from-full-to-lite-in-under-an-hour

Mariettamariette

Answer 4

With iPhone 3.0, you can use in-app purchases instead and allow that to unlock the full functionality without having to make more than one app. I also think that this will avoid people getting this for free, but I'm not as sure about that.

Piragua

Do you have any references/resources regarding this? I'd love to offer an in-app upgrade option but I don't want to require the user create an account and I don't want to have to track the users' upgrades myself. If the user installs the app on another phone will the in-app purchase still apply? (I want it to.) – Rinehart

Answer 5

I used a git branch. I branched my main app and made a few tweaks to disable a bunch of content. Now i work mainly in the master branch and switch over to lite and merge in the latest when major developments occur. Works very well.

Wareroom

Answer 6

The better approach is to have just a single project, with multiple targets instead – one for each version of your app. So what are targets: Multiple Targets

Brause