Also Google IO is not fun any longer, knowing that I will only get to play with those features when my phone dies and is time for a replacement.
And even when buying one needs to take care, for example, plenty of Android 10 phones still on sale.
Also Google IO is not fun any longer, knowing that I will only get to play with those features when my phone dies and is time for a replacement.
And even when buying one needs to take care, for example, plenty of Android 10 phones still on sale.
I mean just look at this: 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.
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.
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.
> 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.
But that code was written in the times when there was no widely used non-NDK APIs for media. Right now landscape is very different: NDK is very niche, and if you’re seeing it everywhere, then either you’re in the gamedev / IoT / etc, or doing something in a very strange way.
What exactly do you use NDK extensively for?