1. Offer a free ‘lite’ version and a paid for ‘full’ version.

2. Offer in app purchases (eg free app with basics, but can buy extra levels).

I cant find any real stats comparing the two ways, but there are obvious problems with both.

The ipad App store has (at the time of writing) about 109,000 apps in it. A search for “lite” apps showed 4400 results. That’s 4% of the apps!! (more if you consider that all those apps are essentially duplicated in the app store because they have ‘lite’ and ‘full’ versions.

So when browsing the app store – 8% of the apps you’ll see are duplicates with arbitrary separation between trial and full. Each of these apps appears in the app store twice (noise) with separate reviews (inconsistency).

For the in app purchase – the common metaphor is buying extra levels, widgets, or content. Technically it is a lot more work, which will prevent a lot of developers from doing it just to offer a trial and full version i the same app. Secondly – although I can’t find any info comparing this, my hunch from my own behavior is to avoid apps that offer in app purchases unless they are content based (eg buy a new book). I don’t like the idea of paying for new levels or add-ons.

Here is what I’d like to see: an Apple sanctioned way of offering in app upgrades. When a user searches for an app they see a single app in the app store. They can install it as either the lite or full version. Either way, the same app is installed, and the app itself has an API call to check what ‘level’ it is. Eg – [theApplication isServiceLevelLite]. There would also need to be an API to upgrade from within the app.

This type of solution has a lot of benefits.

- cleans up the mess of doubled up applications (again – 8% of the app store)

- consolidates incorrectly segregated reviews

- a consistent way of upgrading apps if they are upgradeable

- a less intimidating way (than in app purchases) to offer an upgraded version of an app

- a consistent trial/full paradigm

I think it’s a big win for both developers and consumers. The lite/full app versions is clearly a paradigm that has become commonplace – and I can’t wait until app decides to properly streamline it.

—

Update : Aparently 66% of in-app revenue is from ‘consumable’ goods. (At least for apps that are games).: http://techcrunch.com/2011/08/16/what-ios-android-gamers-actually-spend-money-on/

Upgrading Rails

I imagine there is probably a better way to do this, but since I change the version of rails so infrequently I’m not sure. (If there is a better way, please let me know). My flow is as follows:

Install the new version of the rails gems:

sudo gem install rails

Branch your app

git branch newrails
git co newrails

Remove the old version of frozen gems

git rm -rf vendor/rails

Update your config/environment.rb file to the new version of rails:

RAILS_GEM_VERSION = '2.3.2' unless defined? RAILS_GEM_VERSION

freeze the new gems

rake rails:freeze:gems

Please note, that if instead of installing the new gems and freezing them from your local gems, it looks as though you need to be careful if using rake rails:freeze:gems. You can read more about it in the official post or in this post which I found more understandable.

Testing Your App

The first and most obvious error you will run into is this:

uninitialized constant ApplicationController

This is because as of Rails 2.3 application.rb is now application_controller.rb. To fix this just do

git mv app/controllers/application.rb app/controllers/application_controller.rb

The next error I got was

undefined method `relative_url_root' for #

I narrowed this down to a stylesheet_link_tag call. I got around this by updating the asset_packager plugin, and updating HAML to 2.0.9. By the way, if you’re not using asset packager, you should be.

That’s it! It overall was a very easy upgrade that took much less time to test than my rails 2.1 to rails 2.2.2 upgrade.

Here are some other rails 2.3 gotchas to watch out for courtesy of thoughtbot.