Hacker News Reader

Comment by wsc981 | Hacker News Reader

It's bad for developers though. You have to stick with older API's when developing Android apps if you want to target the largest audience possible. As we speak already ~75% of iOS users are on iOS 7[0] and I'm quite sure it'll be close to ~90% in the next 2-3 months.

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].

[0]: https://mixpanel.com/trends/#report/ios_7

[1]: https://mixpanel.com/trends/#report/android_frag

View on HN

"You have to stick with older API's when developing Android apps if you want to target the largest audience possible."

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.

> "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?).

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.

I might have been mistaken with 2.3 yeah :)

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...

> 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.

With iOS, 75%-80% of people are already on iOS7, far higher than that if you look at people who install new apps

I think the point he is trying to make is that the technically newest APIs (19/Kitkat) aren't all that different from any of the 3 Jelly Bean APIs in a significant enough way that the SDK can't mitigate the differences in an acceptable way.

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.

The stats at your second link are based on apps that use mixpanel. I suspect that Google's statistics [1] are going to be more accurate because they are based on play store purchases and periodic update checks.

[1] http://developer.android.com/about/dashboards/index.html

The support libraries solve most of the API problems though.

Reply on news.ycombinator.com