Making an iPhone app 2.2.1 compatible

Posted: October 5th, 2009 | Author: admin | Filed under: Recap | No Comments »

One of the things we added to the 1.1 version of Spooky Puzzle (still in review with Apple) was compatibility with iPhone OS 2.2.1. Really we should say iPod touch OS 2.2.1, because those devices are usually the ones that people don’t upgrade, because it costs them money to do so. Anyway, we’ve read widely varying accounts of how many people update to the latest OS, and how fast, but we wanted to give it a shot to at least learn how it’s done and to try to make our apps as compatible as possible.

As it turned out, for Spooky Puzzle it was pretty easy to make it compatible, once we figured out how to do it. That last part, of course, is almost always the catch. Maybe we can save you some time by telling you what we figured out.

Note that there are a number of ways you can do it, some more elegant than this one. This is how we did it, quick and cheap and easy. Want elegant, extendable, pretty? Keep Googling.

The first thing you we did was kept our Base SDK as we normally would, to the latest version:

This allows us to keep using all the latest and greatest OS3.0+ methods and properties in our code, without #ifdef’ing them out. Of course, a 2.2.1 phone/touch won’t have any idea what these calls are, so if they come across one of them they will flail and crash. But we’ll get to that later.

The next thing we did was set the deployment target to the earliest version we wanted to support:

In this case, we’re saying anyone with 2.2.1 can run this binary, even though it uses the 3.0 SDK as a base. Which is exactly what we want to happen.

So now that we set that up, you can see that Xcode will allow us to run our app using a 2.2.1 Device or the 2.2.1 Simulator:

Sweet! We’re done! Just compile and run and… ah crap, it crashed.

So the final step is to figure out what doesn’t work with 2.2.1, and handle those specific cases differently as needed. For example, in Spooky Puzzle we found out that modal transition styles got an upgrade with 3.0, and the ones we were using weren’t supported in older OS versions. So, in our code we check the version of the device, and only set the transition style if we are running 3.0 or greater:

Running 2.2.1? Sorry, you get the old, lame, default style. Bummer for you, but at least the app runs.

Now, how did we know what bits needed to be changed and worked around? Well, that’s the tricky part. A good first step is to look through the 3.0 release notes to see what Apple added and changed. Or, alternately, you can just say screw it and run the thing and see what happens. Yes, we did this first, and so will you. Anyway, this works… as long as you test everything thoroughly and perfectly, which is of course impossible. There’s also the problem that things might mostly work, but they might not work exactly like you want or expect them to work. For example, I noticed a difference in the way ViewWillAppear was being called between 2.2.1 and 3.0, and had to tweak my code so that the things that were set there were being set properly in either version. So you actually do need to jump in and test everything yourself, both in the simulator and on a 2.2.1 device. You can’t assume it will work right just because it “should”.

So, making an app backwards compatible is stupidly easy right? Well, this one wasn’t bad, once we tried a few different approaches and found one that worked. Our other app though, the Halloween Costume Generator, would have been a much bigger task. It uses table views, and there are some differences in the way you set cell fields between 2.2.1 and 3.0 that would have required me to change most of that code. The Costume app also uses the Apple Reachability code to test for an internet connection, and that didn’t want to work properly either, which is tricker because now we’re talking about modifying other peoples code, which can always give you unexpected results. Finally, the Costume app allows you to send emails with the costume info, and that again was very different in 3.0 vs 2.2.1. So we ended up not making this app 2.2.1 compatible, since it has a limited shelf life up to Halloween, and if by next year anyone is still running 2.2.1… well, let’s hope they’re not…

Now, the important question: will it make any difference in sales in the end? Given how long 3.0 has been out, and the already low sales of Spooky Puzzle, we kind of doubt it. But, at least we figured out how to handle these cases for when Apple comes out with 4.0, 5.0, 6.0. Also, it is nice to avoid the 1 star reviews from people who somehow download a 3.0+ app to their 2.2.1 device, and then get mad at you because it doesn’t work. Every little bit helps!

---