For me as mobile developer, this is one of the reasons why I'll keep developing iOS apps first and target Android second.
Android adoption rates can be seen here[1].
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.
i'm kind of mystified how you are doing things to make this the case... the only significant headache i have ever had with backward compatibility is when apple stop me from being able to do it by force.
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?).
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...
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.
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.
http://developer.android.com/about/versions/android-4.4.html
All pretty reasonable for an API upgrade, and I don't think it's going to break legacy.
[1] http://developer.android.com/about/dashboards/index.html
Android and iOS have different development models, if that isn't taken into account then comparisons are meaningless. Google often gives people the chance to opt into beta or dev releases, by this standard nearly every desktop Chrome user is two versions behind the latest release.
BTW, Chrome is available from the store, though webvew isn't (yet).
We're still in the Gingerbread era. Yes, it was released three years ago, but almost a quarter of Android users are still stuck on Android 2.3:
Indeed, phones with it installed are still widely available for sale.
http://www.amazon.com/HTC-A510e-Unlocked-Android-Bluetooth/d...
Some of my relatives who took my iPad 1s when I bought new Ipads for my kids are stuck on iOS 5.1.1. Those iPads are from September 2010, but stopped receiving any updates for system apps as of May 2012.
So yes, granular, loosely coupled updates are better than "rebuild the whole tightly coupled world and ship a firmware-diff" updates.
In particular, if an app is not tied to specific kernel features on Android, changes are it can have along life, because Android OS level services like Google Play Services can be independently updated as well.
My iPad 2 (just over two years old) is a real pain with iOS7, virtually every time I switch apps the app has to restart from scratch
Still, I have zero issues with iOS 7 on my iPad 2 and my parents are happy on their 4S.
The issue there is that for someone living in a country where data is expensive, a 10MB download is better than an ~800MB one every time there's some bugfixes/app updates. Plus from my knowledge, Play Store can deliver a patch of the app, instead of downloading the whole 10MB.
Yes they do: http://cdn.macrumors.com/article-new/2013/09/ios_7_0_2.jpg (since iOS 5).
Aside from Maps (for which there were alternatives) the other apps haven't really had any urgent patches bundled into minor OS upgrades that I can recall.
One could even say that the advantage of Google being able to system app updates on the Play Store is that Android apps competing with iOS ones (not a great comparison, but Google Now and Siri) have an advantage in that Google keeps on pushing updates regularly as and when they are ready, whereas Apple would update Siri during a major OS update or the incremental ones. [I am aware that back-end services/responses are updated regularly by both, but I'm referring to code which would change an app's behaviour].
This is not true for apps that come with the OS. Some Apple apps were updated later, but only those that come from the App Store like any other regular 3rd party app.
The advantage Google has to be able to update core apps from the store instead of through OS updates is specific to Android's nature, because it allows them to work around OS updates not being available to customers (because of carriers, OEMs, whatever). Apple doesn't have that problem because they update the OS themselves. Also, Google likes to update its software more often than Apple does.
also apple should (but don't) reject apps that ask for a front facing camera and yet don't use it. its in the app store submission requirements...
A quick search will bring up tables of which device requirements will disallow which devices, so it's not an unheard of practice. But nobody is excluding potential customers out of spite, it's because the older harware genuinely can't handle the apps.
I have a 3Gs so i can also be exception, like you, and keep upgrading my apps/sites and not having to add "front facing camera" just so i can be a slob and not test for the phone poor people uses.
screw upgrading phone every year. my gaming desktop is not upgraded that often.
What Google is doing is helping but the ideal solution would be to have people be able to upgrade their mobile devices for at least 3 years. As much as I dislike Microsoft, if they provide a better upgrade path, they could become a much bigger player by making upgrades trivial for the 99.9%.
apt-get upgrade versus make buildworld :)
...
Base system, of course.
Now those on Android 3.x are definitely screwed. At least the 4.x phones are getting the new apps, and new APIs.
iOS needs a whole OS update to update things like Mail, Maps, Safari, Siri, Notes, Reminders, Camera, Photos, etc
On Android, many of the core equivalents are available as Play store updates with the exception of stuff like Chrome and WebView which had deeper OS dependencies.
Is someone stuck on say, Android 4.2 (two releases ago) in a worse situation than someone stuck on iOS 5? The Android user in many cases could still get the latest Google Now cards, Chrome, Gmail, Maps, etc
Yes, it was bad in the Gingerbread era. But if you've got Jellybean or equivalent, in many cases, you don't need to be on KitKat to get the majority of the latest features.