5 ms·

Back when I developed Android apps I never bothered to watch IO and barely kept up with the latest SDKs. There was no point because it takes years for new vers

Back when I developed Android apps I never bothered to watch IO and barely kept up with the latest SDKs. There was no point because it takes years for new versions of Android to go live on enough devices to make the effort worthwhile. By the time half of users are on the latest version a whole new version has been released. I mean just look at this: https://gs.statcounter.com/os-version-market-share/android https://gs.statcounter.com/os-version-market-share/android . No recent version ever even hit 50%. Maybe it would have been different if I was part of a large team with more time to spend on somewhat frivolous efforts.

scarface74 4y ago
And compare to this https://gs.statcounter.com/ios-version-market-share/ https://gs.statcounter.com/ios-version-market-share/
Larrikin 4y ago
AppCompat, AndroidX, and their other library projects have basically made SDK concerns something you rarely have to think about at this point. Usually the only thing you need to consider are security concerns that newer versions force on you, like updated, new or more finely grained permissions. Everything else pretty much just works. My current teams app supports all the way back to API 23, and has only needed to drop support for older versions a couple times for security reasons. It all works so well with older versions now that on an evaluation from the mobile teams of the new UI frameworks Jetpack Compose and Swift UI, we decided fully in support of Jetpack Compose because it worked very well out of the box with older versions and was getting tons of updates. We decided against Swift UI since it was tied to the iOS version, and although most people who can update their phone do, significant numbers of users it seems don't immediately buy new iPhones anymore when they don't get updates anymore. As much as the dev experience would have been improved using the latest Swift UI on latest, the lowest version we support is stuck with one of the terrible first iterations. For something like UI, it just wasn't worth losing so many users.
- colejohnson66 4y ago
  I thought developers could bundle Swift with their app? So even if iOS has version X, you can bundle X+1 and it’ll work.
  - ajconway 4y ago
    Apps targeting pre-2018 iOS versions bundle the mid-2018 version of swift runtime for compatibility reasons. For example, when you run an app made in the iOS 15 era on an iOS 13 device, the app can’t use any runtime features that are not included with iOS 13. Given that swift is still rapidly evolving, that amounts to a lot of useful features. This year, iOS 16 apps get to use the cool new Regex features.
- NullPrefix 4y ago
  Marshmallow (23) is an odd version to support. Most legacy device apps go back to at least Lollipop (21). Compose UI and some other stuff requires API 21. Any reason for Marshmallow?
  - Larrikin 4y ago
    Our app heavily uses BLE and we integrate with a number of different partners. I don't remember which libraries required it, but a few of them required us to move up to 23.
    - NullPrefix 4y ago
      I see, that explains it.
- dpkirchner 4y ago
  I'll admit it has been a long time -- androidx was only just showing up when I stopped developing for the platform. > AppCompat, AndroidX, and their other library projects have basically made SDK concerns something you rarely have to think about at this point. I kinda wish this meant they would spread out the releases a bit more, say 2-3 years apart. At least then they'd have even more motivation to ensure that the support libs et al offered compelling features that don't require manufacturers to stop being lazy.

scarface74 4y ago

And compare to this https://gs.statcounter.com/ios-version-market-share/ https://gs.statcounter.com/ios-version-market-share/

Larrikin 4y ago

AppCompat, AndroidX, and their other library projects have basically made SDK concerns something you rarely have to think about at this point. Usually the only thing you need to consider are security concerns that newer versions force on you, like updated, new or more finely grained permissions. Everything else pretty much just works. My current teams app supports all the way back to API 23, and has only needed to drop support for older versions a couple times for security reasons. It all works so well with older versions now that on an evaluation from the mobile teams of the new UI frameworks Jetpack Compose and Swift UI, we decided fully in support of Jetpack Compose because it worked very well out of the box with older versions and was getting tons of updates. We decided against Swift UI since it was tied to the iOS version, and although most people who can update their phone do, significant numbers of users it seems don't immediately buy new iPhones anymore when they don't get updates anymore. As much as the dev experience would have been improved using the latest Swift UI on latest, the lowest version we support is stuck with one of the terrible first iterations. For something like UI, it just wasn't worth losing so many users.

colejohnson66 4y ago
I thought developers could bundle Swift with their app? So even if iOS has version X, you can bundle X+1 and it’ll work.
- ajconway 4y ago
  Apps targeting pre-2018 iOS versions bundle the mid-2018 version of swift runtime for compatibility reasons. For example, when you run an app made in the iOS 15 era on an iOS 13 device, the app can’t use any runtime features that are not included with iOS 13. Given that swift is still rapidly evolving, that amounts to a lot of useful features. This year, iOS 16 apps get to use the cool new Regex features.
NullPrefix 4y ago
Marshmallow (23) is an odd version to support. Most legacy device apps go back to at least Lollipop (21). Compose UI and some other stuff requires API 21. Any reason for Marshmallow?
- Larrikin 4y ago
  Our app heavily uses BLE and we integrate with a number of different partners. I don't remember which libraries required it, but a few of them required us to move up to 23.
  - NullPrefix 4y ago
    I see, that explains it.
dpkirchner 4y ago
I'll admit it has been a long time -- androidx was only just showing up when I stopped developing for the platform. > AppCompat, AndroidX, and their other library projects have basically made SDK concerns something you rarely have to think about at this point. I kinda wish this meant they would spread out the releases a bit more, say 2-3 years apart. At least then they'd have even more motivation to ensure that the support libs et al offered compelling features that don't require manufacturers to stop being lazy.