> "what? surely you just use the new features as and when they become available and always use the oldest API as a 'base level'? this is the same for all platforms... including iOS - if you approach backward compatibility as something you seriously want this is not even a problem. even given the quick uptake on updates in the iOS world, supporting just iOS 7 seems a bit nuts to me.... maybe i get the wrong end of your stick though."
In iOS often newer versions of the operating system make certain functionality much easier to develop due to the new API's that are added or existing API's that are extended or improved. I personally don't find backwards compatibility hugely important, I just want to provide enough backwards compatibility to serve 85+% of the market. I think in the coming months we'll reach that stage for iOS 7, so for the current app I'm working on will target iOS 7+, that is if I can convince our client this is a good idea.
Sadly, for Android I'm likely required to target versions 3.2+, which means some functionality might not work as well or look as great compared to what's possible in the newest versions of Android, especially if I find myself using the lowest common denominator of API's. I don't like to do extra work just for a small part of the audience, so that is something I'll try to avoid (perhaps some people will hate me for this?).
that makes sense. ditching backwards compatibility does make life a lot easier - as long as you are aware of the compromise (or that it doesn't exist if you are targeting some enterprise environment perhaps) then it does make sense.
In general though I think as an approach it is customer unfriendly and programmer (or other ulterior motive) friendly /only if the programmer is lazy or starting from scratch/. Eventually you do have to decide a cutoff point based on the time you spend vs. the reward - however if you reuse your code properly these become one time costs that are rapidly amortised - and following the practice of backwards compatibility helps in a cross platform environment to ensure that your /architecture/ is actually future proof and platform agnostic.
As a one man band I enjoy supporting all of the platforms and with a large amount of backwards and forwards compatibility. It might be easier as a team of one, but it makes me feel (that bad kind of) pride when I look at 10+ man dev teams failing to do the same...
Why would you target android 3.x? 3.x was a very short-lived, tablet-only release that never had a significant install base.
I understand wanting to support 2.3 for older/low-end phones, but I've never seen any statistics, including those you posted, that suggest 3.x has enough market share to be worth supporting.
> Sadly, for Android I'm likely required to target versions 3.2+, which means some functionality might not work as well or look as great compared to what's possible in the newest versions of Android, especially if I find myself using the lowest common denominator of API's. I don't like to do extra work just for a small part of the audience, so that is something I'll try to avoid (perhaps some people will hate me for this?).
This is a bunch of nonsense, support apps back to 2.2 or 2.1 is not difficult and you can easily target higher level APIs even if you use an older OS version as a base API level.
In iOS often newer versions of the operating system make certain functionality much easier to develop due to the new API's that are added or existing API's that are extended or improved. I personally don't find backwards compatibility hugely important, I just want to provide enough backwards compatibility to serve 85+% of the market. I think in the coming months we'll reach that stage for iOS 7, so for the current app I'm working on will target iOS 7+, that is if I can convince our client this is a good idea.
Sadly, for Android I'm likely required to target versions 3.2+, which means some functionality might not work as well or look as great compared to what's possible in the newest versions of Android, especially if I find myself using the lowest common denominator of API's. I don't like to do extra work just for a small part of the audience, so that is something I'll try to avoid (perhaps some people will hate me for this?).