> And even if you don’t want to update the app, Google will eventually start hiding apps from users if the app doesn’t target some minimum API version. This means you can’t just publish an app and leave it at that; it’s several days of work per app per year to keep up with the latest rug-pulls from Google.
That's something I just can't understand. If the old API is insecure or whatever, then surely the OS can put some sort of a secure emulator sandbox around old apps. You can run 35 years old NES games but not a 5 years old app? This doesn't make sense.
I never particularly liked Microsoft but userspace compatibility is something they got right and Google got wrong.
Take for example an old gallery app that request complete file access.
Now the new API adds fine-grained access and removes complete access.
What are they gonna do? Give the old gallery app fake file access, making it completely useless?
This would make for a very bad user experience. It works for emulators, because noone expects emulators to be well integrated with the system. But it doesn't work for native apps.
Many features cannot be preserved. They could preserve some features, but doing so would result in some weird 50% support for old APIs, which wouldn't be great either.
In my view, dropping old APIs entirely makes sense.
> I never particularly liked Microsoft but userspace compatibility is something they got right
With the result of having absolutely zero sandboxing.
> Give the old gallery app fake file access, making it completely useless?
Yes. When any API is used for the first time, pop up a toast saying "this legacy app is trying to use File Access permissions. [Allow access to whole device] / [ Restrict to apps own files ]".
If the user hits 'allow', grant the legacy API. If the user hits 'restrict', give a fake filesystem.
The dialogue box should be provided by the OS, and if the threading model doesn't allow pausing the app to wait for user interaction, simply kill the app to ask the question, and restart it with the permission.
Except that legacy app owners regularly get offered money by bad actors, to purchase the apps and take over. Which means that anyone who "Allow access to whole device" suddenly gets a malicious update that cryptolocks them or steals their files.
Real scenario, real problem, semi-common attack vector. Enough that it's a serious problem for Google.
You don't have to give access to whole device. Ask the user what he wants to share, then present the app with a skeleton directory tree where only allowed parts are visible. App can as well think that is has a "full access" whatever that means, it's a matter of terminology.
You've got an old app that uses an API that assumes full access to the device. A new API that restricts that access _cannot_ just guess what the app actually needs / uses - the only sane thing to do is to ask the user what the app actually needs.
The problem there is that the user is not incentivised to precisely curate the permissions boundary of the app, they're incentivised to _make the damn popup go away_.
> You've got an old app that uses an API that assumes full access to the device. A new API that restricts that access _cannot_ just guess what the app actually needs / uses - the only sane thing to do is to ask the user what the app actually needs.
No. It knows which actual paths the app tries to access. They can be grouped into exactly the same permission bundles (access to camera images, access to downloads etc) which are used for newer apps. Then presented to the user for approval, like they are with newer apps.
The only difference is, you may not get all permission popups at once -- but that's already the case with many newer apps. They only ask for permissions to e.g use camera when you actually need it. And I like it so much better than the old approach when the apps would refuse to run without camera even though I don't need this particular feature.
> The problem there is that the user is not incentivised to precisely curate the permissions boundary of the app, they're incentivised to _make the damn popup go away_.
Right, and exactly the same problem applies to new apps natively built against the new API. The app can request unreasonably wide permissions and the user will make the damn popup go away. It's not relevant to the problem of maintenance of old apps.
>> I never particularly liked Microsoft but userspace compatibility is something they got right
> With the result of having absolutely zero sandboxing.
With the result of having useful machines that do useful work, instead of toys that "protect" users and prevent them from ever doing anything interesting.
Doesn't the operating system show you a prompt to show which files you want to give the app access to? From the app's perspective, nothing has changed. It gets a handle to a directory and can list files in it. Whether that directory contains 1 or 10000 items makes no difference.
Just to be clear: I don't disagree with you. I think it's completely normal to have APIs be deprecated, and this means eventually your app will break and be removed from the store. I just don't think this specific example was entirely justified.
For the file system, the OS could do something similar to what iOS is doing when you want to share a picture - giving the user control over which pictures the app has access to. Yeah, for a gallery app it could render the app quite useless because of the UX, but it would solve the issue itself IMO.
> Now the new API adds fine-grained access and removes complete access.
> What are they gonna do? Give the old gallery app fake file access, making it completely useless?
Can you elaborate on your example here? Couldn't they just do something like replace oldGalleryAppOpensOrWritesToAnyPlace() to askPermissionsForWhichFilesAndFoldersCanBeWrittenTo() or ifSensitiveDirIsNoLongerAccessibleAskPermissionOnWhichFolderToUseForCompat() ?
They could intercept file access to common folders, showing you a pop up with the files you would like for the app to see and show only those files to the app.
> Take for example an old gallery app that request complete file access.
This applies even to apps that don't request any permissions. I have some plain OpenGL games there and they still require this useless maintenance for them, which I'm probably won't be bothering with anymore.
Sure, but why is the API still changing now, after nearly two decades? It should be more or less locked down whether you do "file system is a free-for-all" or "every app is sandboxed".
I don't think people are complaining about API deprecation being a thing, either. They complain about it being a thing that happens too often.
>I never particularly liked Microsoft but userspace compatibility is something they got right and Google got wrong.
they both have their ups and downs. Windows 11 still has parts of the base OS that feel like they never updated from XP. and I'm sure there's a lot of legacy cruft that ultimately slows down the boot process or many low level OS management. you add a .lot of cruft to make sure you can support 30+ years of legacy software.
> You can run 35 years old NES games but not a 5 years old app? This doesn't make sense
If you are willing to fill your phone with emulators of every single version of Android, then yes, you can run any old app. This is how we run 35 years old NES games.
Would you need every single version of Android? or just a much thinner compatibility layer for deprecated APIs? Newer apps wouldn't be able to use the deprecated API but older apps don't just disappear either
It's all related. Emulation, compatibility and compatibility-through-emulation are very old and well-studied topics. The reason why it's not present on Android is because Google doesn't want to, not because they can't.
>The reason why it's not present on Android is because Google doesn't want to, not because they can't.
Sad as it may be, I imagine that lack of desire also comes from consumer demand. Most people don't care about running those 15 year old games, so what's the motivation?
For archival's sake, you should be able to seek old APKs and run older ROMS through an android emulator. So the minority of those who care have options.
It seems perhaps more relevant to point out that WINE can run 30 year old win32 apps. I suppose that does include code that could be described as emulators for every single version of Windows, but it's less work because Microsoft, for their many other faults, preserves backwards compatibility so old APIs tend to just keep working.
according to the post you reply to it's anyway not about being able to run an app. it's about not having it listed in the play store. and that won't change even with an older android version.
If apps get removed from the store as a consequence, that's going to be many more users left behind.
It's been mentioned time and time again, but it's worth mentioning again — Windows maintaining backwards compatibility is what maintained its hegemony, as compared to it, Linux and macOS look like hobby projects. For the young as well, because games still run on it, without worrying that Apple will invalidate their library due to not being in the mood to maintain 32-bits APIs.
The US Navy was paying $9M to keep Windows XP updated and patched just for them.[0]
I bet if you pay Apple similar amounts of money per year, they'll keep specific APIs available just for you.
And it's not like updating the app to a new iOS version is a massive undertaking, in most cases it's just a matter of opening the project in XCode, adjusting the OS version, compiling and publishing it again.
I can't speak about iOS, but when I open Steam on macOS, I see more than 2/3 of my library unavailable since macOS Catalina, which entirely ruined macOS for gaming for me. Clearly, updating those wasn't so simple.
And also, it's unreasonable to expect all software projects to need updates, forever. My hammer doesn't need updates.
All the smartphone vendors do that. I have lost several iOS apps I once bought, because the developer chased to regularily update his app, which eventually killed it.
I always assumed that's their algorithm mostly and not related to the API levels. Apps that stand out most when you open the play store now are often these with heavily inflated user numbers through scummy ads or practice.
That's something I just can't understand. If the old API is insecure or whatever, then surely the OS can put some sort of a secure emulator sandbox around old apps. You can run 35 years old NES games but not a 5 years old app? This doesn't make sense.
I never particularly liked Microsoft but userspace compatibility is something they got right and Google got wrong.