Is it common to test apps for compatibility with much older iOS versions (in my case, iOS 4.3 apps with iOS 2.x)? Or are most apps just tested one version back or so. Any idea what percentage of the iOS market will be lost to me if my app doesn’t work on much older versions? I’m guessing a miniscule amount, but that seems to be enough for my employer to ask me for distant backwards compatibility -_-
Share
This varies quite a bit app-to-app, depending on features being used and broadness/niche-ness of market. The broadest you should target is: current release, previous “dot” release, last version of previous major release. (Now, with 5.0 not yet released, that would be 4.3, 4.2, 3.2 (which was iPad only, so 3.1.3 for iPhone/iPod).
My suggestion is that you never need to support more than this. If your product doesn’t work on 3.0, the user can update for free. Of course older hardware doesn’t always update, and if your market is “people getting left behind” (which usually doesn’t overlap with “people spending money in the app store”) you can support older.
Some will only support newer because of powerful features being used in newer releases. 4.0 had a lot of great additions (blocks/GCD/multitasking among them). Leave 3.x behind as soon as you can.
If your audience is a push-the-edge crowd, you can just support the latest (4.3, 4.2 right now – realistically, there’s not huge API differences there).
I have an app targeted at 5.0 that will not support anything older, newer APIs are central.
As far as testing, if you have the oldest hardware with the smallest RAM you think you are targeting, that will help test. CPU and memory can really be pushed on those.