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

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.

Solution 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.

Solution 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.

Solution 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

Solution 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.

Solution 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.