> No. No they don't if you're not being completely disingenuous. Jetpack AppCompat style libraries backport app functionality that older Apple devices will get via OS updates in a strictly saner way than having to rely on a backport of a TextView...
This is critically important, though. Look at Compose vs SwiftUI for example–Compose works really well, and even in beta was more stable than SwiftUI, which is nearly impossible to support on iOS 13 devices without massive kludges.
> OS-level functionality does not get backported and of course cannot come from library changes.
This is true, though not super relevant IMO. What OS functionality are folks missing on Android due to being behind? Security updates are the important bit, and most devices still get those for years.
> Gmail is not the Android built-in mail app, just like on iOS Gmail is an additional app that's shipped by Google.
The built-in app isn't updated because Google moved away from that model entirely. Why even bring it up? It's irrelevant.
> Headline features like Assistant changes, privacy and permissions, and system UI overhauls don't end up on your old device either.
Good point regarding privacy & permissions, apps also need to use newer SDK versions to support those IIRC.
The UI overhaul is a weird thing to be concerned about on Android. If you care that much you will install your own launcher. And apps that care will ship the updated UI, one of the advantages of them just being libraries. I guess the notification pane won't update, but is that a huge deal? I'd guess for most folks the answer is no.
> Android's update strategy has resulted in a hellscape where Google is forced to recommend supporting a 6 year old version of their OS
It isn't perfect, but far better than supporting SwiftUI on iOS 13, for example
> What you're doing is like bragging that your neighbor's filet mignon is a little undercooked while you chow down on dog food.
Honestly this is just rude imo, no
To be clear, I think there are pros and cons to both approaches. I think somewhere in the middle would be better, but generally prefer the way Android approaches putting new APIs into older apps.
> This is critically important, though. Look at Compose vs SwiftUI for example–Compose works really well, and even in beta was more stable than SwiftUI, which is nearly impossible to support on iOS 13 devices without massive kludges.
People who need to force iOS 13 support are not representative of the development environment. iOS 14+ (from 2 years) represents 99% of the market. You couldn't target that percentage of Android devices even if you targeted Marshmallow, a 7 year old release!
> The built-in app isn't updated because Google moved away from that model entirely. Why even bring it up? It's irrelevant.
Gmail on Android is comparable to Gmail on iOS.
Mail.app is comparable to AOSP Email.
AOSP Email stopped being updated because Android devices never get updated, so it was becoming a liability. Except now realize that issue applies to _every single feature_ baked into an Android release.
But it's not nearly as powerful, assistant regularly leverages APIs that are part of new OS releases, so just like you're describing on iOS, you'll get the version but you won't get all the features
> The UI overhaul is a weird thing to be concerned about on Android
The first headline feature is about the UI changes and that's always been a thing.
> Honestly this is just rude imo, no
It's not rude, it's being real. Android's update situation is an absolute nightmare on so many levels. Millions of devices that don't get security patches anymore since even the 5 year standard is recent and Google-specific. Backporting even the most basic functionality like a simple text view to 8 year old versions.
It shouldn't be defended, Google had the power to pressure SoC manufacturers, got halfway with Treble, then just kind of gave up by not enforcing compliance via CTS. Now they want to switch to enabling updates with hypervisors, but again haven't made a peep about ever bringing down the hammer on compliance.
The same way that the AOSP Email app hasn't been updated in years so you want to compare Gmail, these manufacturers need Google to have the experience (western) audiences expect. So Google is 100% fumbling their one role at being a buffer between the wild west SoC manufacturers want where they drop new SoCs and stop updating them after 5 minutes.
> People who need to force iOS 13 support are not representative of the development environment. iOS 14+ (from 2 years) represents 99% of the market. You couldn't target that percentage of Android devices even if you targeted Marshmallow, a 7 year old release!
It is important to look at AppStore Connect and actually check the breakdown of your users. When your app has millions of downloads and even 5% are still on 13 it hurts to drop support for them.
> Mail.app is comparable to AOSP Email.
It really isn't. Nobody gets an Android phone to use AOSP email, and it doesn't come on most phones by default.
> It's not rude, it's being real.
That's not the way I see it. Like I said, there are pros and cons with both approaches. Your comments are too black and white and ignore the reality that there are a lot of advantages to Google's approach, and iOS would be improved by adopting similar tactics.
FWIW, I think it would be nice if Google strong-armed folks into longer update cycles (or better yet, manufacturers just did it!). I think if Google brings the hammer down as you suggest the anti-trust situation they find themselves in will be debilitating.
This is critically important, though. Look at Compose vs SwiftUI for example–Compose works really well, and even in beta was more stable than SwiftUI, which is nearly impossible to support on iOS 13 devices without massive kludges.
> OS-level functionality does not get backported and of course cannot come from library changes.
This is true, though not super relevant IMO. What OS functionality are folks missing on Android due to being behind? Security updates are the important bit, and most devices still get those for years.
> Gmail is not the Android built-in mail app, just like on iOS Gmail is an additional app that's shipped by Google.
The built-in app isn't updated because Google moved away from that model entirely. Why even bring it up? It's irrelevant.
> Headline features like Assistant changes, privacy and permissions, and system UI overhauls don't end up on your old device either.
Assistant receives updates via the Play Store: https://play.google.com/store/apps/details?id=com.google.and...
Good point regarding privacy & permissions, apps also need to use newer SDK versions to support those IIRC.
The UI overhaul is a weird thing to be concerned about on Android. If you care that much you will install your own launcher. And apps that care will ship the updated UI, one of the advantages of them just being libraries. I guess the notification pane won't update, but is that a huge deal? I'd guess for most folks the answer is no.
> Android's update strategy has resulted in a hellscape where Google is forced to recommend supporting a 6 year old version of their OS
It isn't perfect, but far better than supporting SwiftUI on iOS 13, for example
> What you're doing is like bragging that your neighbor's filet mignon is a little undercooked while you chow down on dog food.
Honestly this is just rude imo, no
To be clear, I think there are pros and cons to both approaches. I think somewhere in the middle would be better, but generally prefer the way Android approaches putting new APIs into older apps.