[gumballhead]

I often get sympathetic comments for being an Android developer because of this. It's honestly not that bad. Android provides backwards compatible support libraries for whatever SDK you're supporting, and was designed from the beginning to handle diverse screen sizes and hardware.

By far a bigger problem is manufacturers shipping their own version of Android that is sometimes incompatible with the SDK. I've had to implement some ugly hacks for Samsung before, which is unfortunate because of how popular their hardware is. It's becoming less of a problem over time though.

[enzanki_ars]

The problem with outdated versions is not app compatibility, but security updates. If a zero-day were released, most of these devices would never receive an update fix the issue.

Worst case scenario: An Android zero day that can be spread via WiFi or Bluetooth that infects devices in a cryptolocker style. The more versions it can affect, the better.

Shoot. Probably shouldn’t give people ideas, especially when I have an Android device. At least it runs LineageOS and can be updated easily...

Edit: To clarify my idea, imagine the Windows XP crypolocker viruses, but for Android instead, spreading not through cell towers or WiFi routers, but instead spreading via the cellular/WiFi/Bluetooth chips in the devices.

I’m starting to wonder if I should buy a portable Faraday cage for my devices...

[IshKebab]

It's also a problem with compatibility. Just because they've found a reasonable way to mostly work around it (by basically bundling an up-to-date version of the framework into each app) doesn't mean it isn't an issue. Not everything is in the support library.

But I agree, at this point the security issues are a bigger concern.

[thecupisblue]

That "worst case scenario" isn't that hard to achieve. But maybe the only thing stopping something like that from happening is, ironically, the OEM fragmentation which screws up a lot of code related to gaining root or lock screens and similar.

[erikb]

Why not see it the other way around? You can totally go and develop an app that just runs on Samsung Galaxy S8 and nothing else. But with the Android SDK you get the option to support a range of other devices as well with a little overhead. That's far better than with IOS where you only get to support one device type, just maybe different versions of it.

[iainmerrick]

Even if you just target Samsung it's still not the same, unfortunately.

There's a pretty wide range of iOS devices now, but they're all similar, they're all good (or were good when they were released), and you can check your app on them in the Simulator. Just last week I was able to find and fix some bugs in an app that only showed up in certain combinations of screen sizes and iOS 10 or 11, without needing any real devices.

Samsung has many, many more devices; some of them are very good but lots of them are very bad; they do offer some testing infrastructure but it's not as comprehensive or convenient as Xcode; and they frequently make breaking changes to Android without any documentation. A recent example is their "game tuner" which automatically runs games at lower refresh rates and/or screen resolution. Depending which API you use to check the screen dimensions (and Android being Android, there are plenty to choose from) a game can end up displaying at the wrong size.

[maaaats]

Yeah, I remember when iPhone changed ratio/screen size, and people scrambled to make their apps work. This is something a developer had to handle from day one on all other devices.

[iainmerrick]

This is still a lot more work than it ought to be on iOS. It's possible to write screen-size-agnostic code, but the tools push you towards individually customizing everything for each of the current screen sizes.

For example, in Interface Builder there's a toolbar with buttons to switch between different screen sizes. But it would be a lot easier if they just made the UI freely resizable (in Interface Builder, not necessarily on the device).