5 ms·

Replying to myself, I know. But a related point: So let's have fun with numbers... 1.4b Android users. 7.5% updated to the latest. That's ~105m. 500m iPhone

by chasing 10y ago

Replying to myself, I know. But a related point: So let's have fun with numbers... 1.4b Android users. 7.5% updated to the latest. That's ~105m. 500m iPhone users. 84% updated to the latest. That's ~425m. (I'm pulling these numbers from different sources, but they're probably of the right scale.) My only point is that there might be an argument that Android's deploying new versions on about 1/4 of the devices that Apple is, not 1/10. Which is an important distinction if your argument is that Google is failing at getting people to update their devices.

gremy0 10y ago
Yes but if you're going to be developing an app or service are you going to choose the latest version of Android and get 7.5% of the market or are you going to go down to lollipop and get 40% or down to kitkat and get 70%? It's webdev for IE all over again supporting balls old versions.
- shaftway 10y ago
  Except it's not really. Releases are always additive, and (to my knowledge) have never removed anything (even when they really really should have). The only reason to target a newer version is if you need things that were actually added to the OS (like fingerprint scanning). And even there it's pretty easy to gate functionality. The vast majority of apps don't need to care in the slightest and with appcompat almost everything useful is available. It's not like you have to make completely separate apps for Lollipop and Marshmallow the way you used to for IE and everything else.
  - st3v3r 10y ago
    Not quite true. Handling WiFi changed in 5, and changed again in 6 (really only relevant if your app deals with changing the Wifi state, admittedly). 6 introduced Doze, which can require different implementations of things. There were a number of graphical things in 5 which, if you wanted them on earlier versions (and your Design department does, and you're going to do it, dammit), require fairly different implementations.
    - shaftway 10y ago
      Which things are these? And since generally there's a lot of effort to not break old apps, why wouldn't you just do it the pre-5 way? Also, just to check, we're talking about versions and not API level, right?

by chasing 10y ago

gremy0 10y ago

Yes but if you're going to be developing an app or service are you going to choose the latest version of Android and get 7.5% of the market or are you going to go down to lollipop and get 40% or down to kitkat and get 70%? It's webdev for IE all over again supporting balls old versions.

shaftway 10y ago
Except it's not really. Releases are always additive, and (to my knowledge) have never removed anything (even when they really really should have). The only reason to target a newer version is if you need things that were actually added to the OS (like fingerprint scanning). And even there it's pretty easy to gate functionality. The vast majority of apps don't need to care in the slightest and with appcompat almost everything useful is available. It's not like you have to make completely separate apps for Lollipop and Marshmallow the way you used to for IE and everything else.
- st3v3r 10y ago
  Not quite true. Handling WiFi changed in 5, and changed again in 6 (really only relevant if your app deals with changing the Wifi state, admittedly). 6 introduced Doze, which can require different implementations of things. There were a number of graphical things in 5 which, if you wanted them on earlier versions (and your Design department does, and you're going to do it, dammit), require fairly different implementations.
  - shaftway 10y ago
    Which things are these? And since generally there's a lot of effort to not break old apps, why wouldn't you just do it the pre-5 way? Also, just to check, we're talking about versions and not API level, right?