It's been a number of months and some incredibly late nights in the making but the Realestate.com.au iPad App finally went live in the iTunes store last Friday, August 12. I was lucky enough to be able to give a demo of the app the night before release at the Melbourne Cocoaheads meeting at the Intunity offices in Cremorne and the response from probably the largest (70+) crowd ever to attend a cocoaheads was really exciting.

I joined the REA Mobile team back in March 2011 to help with the contenting development of their iPhone app, and after a UI uplift release for the iPhone we started working on the universal iPad app. After some hiccups along the way, we managed to deliver a brilliant looking, stable app that I'm really proud to have worked on. I'd say it's reset the bar for iOS property apps, and is streets above its competition.

The REA Mobile team is lead by Kevin O'Neill (@kevinoneill), second chaired by Luke Cunningham (@icaruswings) and backed up by Steve Hollaway, Ben Thomas, Mike Rowe, Myles Abbot, Mujtaba Hussain and myself.

Some awesome technical bits / features of the app include:

• Custom forms (IBAForms) for advanced property searches.
• A gorgeous custom UI including the little bits that are really hard to customise.
• Custom map callouts are really hard to customise.
• It's a true universal app it has a shared underlying code base and consistent behaviour, look and feel.
• It rotates, and it rotates like a boss. Rotate it, and see it resize itself without any of that crappy UI flickering you see elsewhere.
• Swishy tap, pan and swipe gesture recognisers all over the place make interactions really fluid.
• It's damn fast (it has it's own purpose built back end).
• It's stable. We tested the f*ck out of this app... and the competitors...
• It caches images and searches and other things;  it also behaves nicely when errors occur.
• It's using the latest iOS 4+ technology and minimal amounts of old legacy code (there's always some right?)
• It leverages/wrangles a handful of awesome open source frameworks.
• It sets the bar for it's category in mobile property apps.

The realestate.com.au iPad app "Money Shot" as we call it

Custom callouts are one of the hard things to customise

So yeah ! If you haven't already - check it out on iTunes -> Realestate.com.au in iTunes

Now that we're well into 2011 the question has to be asked: Is it still worth supporting iOS 3 devices? There's a lot of cool APIs and language features you can take advantage of in iOS 4 (blocks - woo!), most new work I'm involved is targeted at iOS 4 and soon we'll have iOS 5 - but are you cutting off paying customers or future paying customers by requiring iOS 4.0 and above?

My short answer: no, not really. iOS 3 numbers are in steady decline and I don't think new or existing apps will be alienating too many active customers by requiring iOS 4+.

Quick Stats

• Only 11% of my active users are running less than iOS 4.0
• Only 6% of active users of my main paid app  Seoul City Metro are running less than iOS 4.0

Now, lets have a look at some of the data I've compiled. Hope you enjoyed the graphs!

This first graph includes all the data I have collected so far summed up by month and major iOS version. The decline of iOS 3 is clear here with iOS 4 accounting for 89% of all active users by March 2011.

The second graph shows a sample of the last week's data split by iOS version.

The third graph splits up the 89% pie piece from graph 2 and shows the uptake of each distinct iOS 4 version. I found the iOS 4.3 update really interesting, since it was released on March 11 (only 9 days ago) and already accounts for 30% of users. (FYI: the first occurrence of iOS 4.3 was 15-01-2011) The previous version (iOS 4.2.1) is the second highest total at 55%. This means 75% of iOS4 users are actually quite up to date!

The same graph for the iOS 3 distribution (not included) shows the latest version of non iPad iOS 3, 3.1.3 accounts for 81% of users, and the version prior to that (3.1.2) accounts for  17.6%.

Graph four looks at the difference between paying customers and non-paying customers. The results are interesting but as I expected; paying customers are more up to date than non paying customers. There are half the number of iOS 3.x users (by percentage) of my $1.99 app as there are using my free app. It makes sense that people who pay for apps keep things up to date more than your user with a phone full of free apps.

P.S. I was inspired to pull all these details together today when I was noticed that my blog post about Delhi City Metro's iOS usage statistics had been linked to on Stack Overflow . I hope you find this all interesting.

P.P.S. Since July 2010 I have been collecting a basic set of anonymous data from users of my apps on launch. I collect iOS version, app version, unique device ID and the device type, I have recorded just over 109,000 pieces of data so far.

Not long after iOS 4.0 was released I pushed a small update to Delhi City Metro to keep track of some basic (anonymous) user statistics. I'm keen to gauge the audience of any specific iOS 4 features I might consider adding and now that I've been able to visualise these, I thought I'd share them here.

To add a geographic angle to the iOS usage statistics you can see in the second graph that the majority of Delhi City Metro users are from India.

Several weeks after the launch of iOS4 the split between iOS 4 and iOS 3 is 4.x 64% and 3.1.x 31% with iOS 3.2 at 4%. (Delhi iOS Statistics 13-26/8/2010)

Overall Delhi Sale Statistics

Today I was tooling around with some interface concepts and playing with apps like foursquare and Twitter (previously Tweetie) and I wondered if I could implement something similar to the now famous 'pull down to refresh' method of initialising a refresh of the content within a UITableView.

As it turns out it wasn't as difficult as I thought; There were already a couple of elegant solutions out and about. The first example I found was by Oliver Dropnik, which talked about altering an existing solution posted on git hub by user devindoty called EGOTablePullViewRefresh.

Oliver's code looked like it was a good addition to devindoty's because he had decided to subclass UITableViewController which leads to a much more complete solution that's easier to move between projects. My only issue with Oliver's code was that it refactored a lot of the underlying implementation, where I didn't see too much wrong with it.

I decided to come up with a half way measure; I moved the majority of the grunt work into a subclass of UITableViewController, cleaned up the XCode Demo project included with the source code and pushed it all back up to git hub. If you're at at all interested in this, I'd suggest checking out my fork of the EGOTablePullViewRefresh project on Git Hub.

Get a pull-to-refresh effect like Tweetie 2 and foursuare

Update: Another pull to refresh implementation is now in the three20 library by Facebook, but I'm not sure where exactly it's buried.