Developing under Symbian 9, Windows Mobile and BlackBerry has always been a juggling act when selecting an SDK. The aim has been to select an SDK far enough back to support a large number of current phones while ensuring the SDK is new enough to support the newer features that are needed by the application and new enough to fix known bugs. Putting it another way, an app written on an older SDK always works on a newer phone but calling a new API on an old phone will fail with an error. Sometimes, it’s necessary to have two or more versions of an app so that both older and newer phones (and their newer features) can be supported.
I have been doing some Android development that has required me to write code with the latest SDKs that needs to work on older phones. This has made me think about how much less of a problem this is with the newer iPhone and Android platforms. First of all, both Apple and Android devices are being continually upgraded so that most people are on newer versions of the OS. This makes supporting the very old versions less of a problem. How long this advantage exists, remains to be seen because devices cannot be upgraded indefinitely because of limiting older ROM sizes (and improving hardware capability that can’t be retro-fitted).
The second thing is that Android supports Java reflection. Java reflection allows code to be written that examines an API to see if it exists. This means it’s possible to work around APIs you know might not exist. It allows an application written with a new SDK to run on an older phone without error. However, reflection can degrade performance and makes the code more difficult to understand and maintain. Hence, in time, managing increasing backward Android compatibility through more reflection will have its limits.