If the strategy is: 1. Make breaking API changes, but gate them behind the targetSdkVersion. 2. Force app devs to lift the targetSdkVersion to stay up to date by gating device access in the store.
It has a few effects: - Developers can be slow to move. There will be zero million new addressable endpoints initially, and customers may similarly build an expectation of new devices being problematic/best-avoided. - QA burden increases for split behavior *forever*. - The play store becomes an integral element of the privacy and security picture of the device, something that should be the OS’s job.
What would I rather? I’d rather an API evolution plan that doesn’t rely on targetSdkVersion as a means of controlling behavior of APIs. It’s an attempt to have one’s cake and eat it, too, and it clearly falls apart, anyway.
I’m wary of any plan that basically amounts to needing people from other companies to do something in order to succeed.
Many API changes are either extremely minor ("set this flag if you want to keep the worse, legacy handling behaviour") or extremely important ("actually ask the user before you drain their battery tracking their location in the background"). The new handling of notifications (requiring explicit permission) is also a godsend.
Google hosts and distributes apps effectively for free (let's be honest, how many Android users actually even pay for apps). The least you can do to keep the app running is to make it work with the modern API once every three years, with an announcement about the API bump requirement a year in advance.
Before Google did this, the Play Store was filled with crap from the Android 2 era that crashed on startup. Paying the one-time $25 developer fee and chucking an APK over the wall isn't exactly a good way to create a decent app store.
You don't have to comply with Google's desires if you don't want to, but you'll have to host the APKs some place else. Termux has had to do this, unfortunately.
Apps that don't get updated can't be easily installed on new devices. They'll still work and be easily installable on old devices (matching the targetSdk version) in case you rely on an Android 9 tablet embedded into your POS.
I think it's entirely fair to expect a yearly "is everything still okay" check from application developers.
Google rakes in money from all the in app sales, store sales, and subscriptions. Further, google is often the provider of in app ads. Not to mention all the money they get from advertising with google searches and adwords built into (practically) every android device.
And, let's be frank here, a 1, 20, 100mb APK isn't exactly a huge amount of data to host. Especially since there's almost always a linear correlation with the popularity of an app and the amount of revenue google makes from that app.
They aren't exactly operating a charity here. The least they could do with all this money flowing in is support backwards compatibility on their platform.
It definitely can be with scale. Distributing a 33MB app: Google says they've served 70TB, and this would be 170TB without their optimizations
That also equates to over 5 million downloads.
I'm guessing this app is likely pulling in a lot more than $700 for google.
10MM+ downloads on the Play Store (Unsure if Google gives us actual figures on the dashboard)
Google takes a hit on some apps to sell and advertise with others. What's hurting Google in this case is the release of an app update that is bad for customers and bad for the business. While it's just one papercut, the "huh, my iPhone version works just fine" razzing will ring just a bit more true for customers who got bit by the update. Do it enough, and they'll get tired of the hassle and jump.
It's a rough balance, building something scalable that also holds high quality, and separate policy decisions can sometimes lead to truly Kafkaesque journeys for developers and users. It's at least instructive for others. Making and evolving APIs and ecosystems is hard. Think very carefully about the holistic impacts of decisions.
This also makes me wonder, was the app already crashing on Android 13 before updating the target SDK version? I suppose the backwards compatibility layers must've kept the app alive on modern phones?
Personally, as a user, I like that Google forces developers to update their apps, because the old API designs were terrible for privacy, but they won't be enforced unless devs update their targetSdk. Breaking installed apps is not an option, but forcing the issue in Google Play works well. I'd also say their testing times were reasonable, if it weren't for the fact that they don't see obvious problems such as "app was never even tested on Android 13".