7 ms·

This is a problem with how we treat backwards compatibility on mobile operating systems. Imagine if this was an app for Windows. Would you still be scared of up

This is a problem with how we treat backwards compatibility on mobile operating systems. Imagine if this was an app for Windows. Would you still be scared of updating? This is why no one ever pays more than a couple bucks for a mobile app. That would be a terrible investment, as the app could break at any time! Similarly, this is why mobile will never be a good platform for traditional single-player video games.

phoboslab 4y ago
Very true. Apple has removed several of my games (all working perfectly fine) because, well, they felt like it: > Since this app hasn’t been updated within the last three years [...] it has been removed from the App Store
- musicale 4y ago
  I hate this. I don't think it's the right approach to improving search and discoverability in the app store. (My personal suggestion for instantly improving it 100% would be removing ads that eat up the first half-screen of search results on an iPhone.) I also greatly dislike how iOS takes the backwards approach of offloading backward compatibility as a yearly support burden multiplied across every developer - rather than maintaining it in the OS. Platforms are supposed to absorb developer pain for multiplicative benefit - not the other way around.
  - kitsunesoba 4y ago
    As a developer I’m not sure that I agree. Some degree of backwards compatibility is good, but it quickly becomes an unwieldy burden that acts as a ball and chain on the development of the OS and platform toolkit. Among modern operating systems, iOS is probably the worst in terms of backwards compatibility but it’s also one of the most pleasant to develop for — UIKit/Cocoa is unrivaled in terms of both breadth and depth. One can easily build a top class iOS app with few or no third party dependencies, which is not the case on most other platforms. I don’t think that’s a coincidence… if the iOS dev team were encumbered with maintaining backwards compatibility for upwards of a decade it would be much more difficult to build such a complete and polished toolkit.
    - Wowfunhappy 4y ago
      If iOS had versioned libraries and separate teams maintaining the older branches, would that really impede the modern toolkit? I realize that expanding the scope of a project by adding more developers isn't as simple as it seems, but I feel like there ought to be an organizational/development structure that could make this work. I wouldn't even be opposed to older apps running in some sort of seamless-to-the-user virtual machine.
    - deleted 4y ago
      [deleted]
- pram 4y ago
  Yeah this is insane. I bought Sonic CD and Sim Tower for iOS years ago and they're both just completely gone. Not listed, impossible to install. I'm never buying a mobile game again. It blows my goddamn mind.
kllrnohj 4y ago
Android's backwards compatibility, especially for apps that don't update, is quite solid. The cases where previously working behavior is broken without requiring the app to "opt-in" to the breakage is generally scoped solely to things that are considered abuse vectors. Which "draws over other apps" unfortunately is. It's not as good as Windows' back compat, no. But then again nothing is, as that's the only platform concerned with preserving not just API compatibility but bug compatibility.
- cesarb 4y ago
  There's one case I know of where previously working behavior is broken, for something which was not an abuse vector at all: if your app depends on the hardware "menu" button (which is the case for nearly all apps made back when having a hardware "menu" button was standard for Android), for several versions Android showed an emulated software "menu" button next to the back/home/etc buttons, but more recent Android versions no longer show that button, breaking all these apps (since there's no way to get to their menu). See https://www.xda-developers.com/rip-menu-button-android-10-drops-legacy-support-extremely-old-apps/ https://www.xda-developers.com/rip-menu-button-android-10-dr... for details.
- BoorishBears 4y ago
  Android's backwards compatibility is atrocious with a capital A. Every version has random will-be-breaking changes that get held off if your app was compiled before said version came out, but there's only a release or two before the change starts to ignore your compiled version (for example, when a massive permissions change comes down the pipe, any app that's compiled against the newest SDK breaks immediately, and apps that were compiled against older ones just get to break next release) And just like any mobile platform, apps heavily rely on the OS to provide UI widgets and layout. So even design language changes can (and often do) break the UI. - What you're probably seeing is what developers are forced to work around: the fact that everyone is stuck targeting ancient versions of Android because Android users have just accepted their devices never getting OS upgrades. Android Studio will still default to targeting a minimum SDK version of API 25. Android 5.0. From November 12 2014. The situation is so bad that Google removed it from their dashboard (https://developer.android.com/about/dashboards https://developer.android.com/about/dashboards) and buried it in the IDE: https://9to5google.com/2022/05/20/android-2022-distribution-numbers-chart/ https://9to5google.com/2022/05/20/android-2022-distribution-... Nearly a third of Android devices are on a version of Android >5 years old... just imagine if all your iOS apps had to target iOS 11 as a minimum feature set, and XCode defaulted to supporting iOS 8 for all new projects When the apps can't rely on any newer features, it creates the illusion of backwards compatibility.
culopatin 4y ago
But then in the case of Windows we complain that Windows releases in 2022 still have stuff that looks like Windows releases from 2002. Maintaining that backwards compatibility can become a massive pain too.
- jeroenhd 4y ago
  I've seen several remnants of Android 2.1 or below in my Android phone in settings and dialogues that don't need much maintenance. They're reskinned easier, but they are there!
- VancouverMan 4y ago
  Those tend to be the most usable parts of recent Windows releases. It comes as a relief to encounter them.
jeroenhd 4y ago
While you're right that Microsoft has a much better track record for backwards compatibility, this isn't just limited to mobile operating systems. See: Apple breaking x86, deprecating OpenGL, switching platforms, disabling drivers, etc. Most things that actually break on Android break for good reason, in my opinion. I consider giving apps the ability to draw overlays without any kind of permission in a supposedly sandboxed environment a design flaw, for example. I'm more annoyed by their restrictions on dynamic loading but even that still seems to work fine if you avoid the Play Store and set your API targets to a version that triggers the backwards compatibility system. The recent change to the way uploading to Google Play works (where you have Google sign your apps instead doing it yourself) is the worst change in years, but that's technically a Google change, not an Android change. Almost all API changes necessary to run old apps are minute. The permission overhaul for Android 6 (interactive permissions for many permissions that were previously granted install-time) requires a few more lines of code to show an error if the user denies a critical permission but it doesn't require a full rewrite. The consequence is that app devs with some minimal time on their hands can update their apps to work on modern devices quite easily. Only apps that are thrown over the wall and abandoned or created by defunct companies are now broken. Luckily, decompiling most Android apps is quite trivial. If the app is indeed completely defunct with the company disappearing, one might relatively safely maintain a decompiled fork of the abandonware to make it work on modern platforms. It's a pain, but not a dissimilar amount of pain to searching working on NoCD cracks for games that require DRM broken on Windows 10. Enthusiasts do it, quite regularly as it turns out! This is also why I'm in favour of laws about source control for abandonware; if a company doesn't exist anymore and people still use their software, the source code should be opened so customers aren't screwed over. Source escrow isn't unheard of in B2B applications and I don't see why it can't be done for consumer apps.
- sgtnoodle 4y ago
  Re: source code release, it seems like that could get rather messy for anyone using third party source code that isn't open. Also, right away any sort of law like that would become incredibly nuanced. I have a pacemaker and there's an optional BLE app for it. Security through obscurity is lame, but I'd rather that app's source code not be dumped on the internet if the pacemaker company stops supporting it. The source code wouldn't keep the app going because it is dependent on the cloud, and would only be of value to folk trying to reverse engineer the diagnostic protocol. Personally that sounds like a lot of fun, but it's also hardwired into my heart...
deleted 4y ago
[deleted]
deleted 4y ago
[deleted]

phoboslab 4y ago

Very true. Apple has removed several of my games (all working perfectly fine) because, well, they felt like it: > Since this app hasn’t been updated within the last three years [...] it has been removed from the App Store

musicale 4y ago
I hate this. I don't think it's the right approach to improving search and discoverability in the app store. (My personal suggestion for instantly improving it 100% would be removing ads that eat up the first half-screen of search results on an iPhone.) I also greatly dislike how iOS takes the backwards approach of offloading backward compatibility as a yearly support burden multiplied across every developer - rather than maintaining it in the OS. Platforms are supposed to absorb developer pain for multiplicative benefit - not the other way around.
- kitsunesoba 4y ago
  As a developer I’m not sure that I agree. Some degree of backwards compatibility is good, but it quickly becomes an unwieldy burden that acts as a ball and chain on the development of the OS and platform toolkit. Among modern operating systems, iOS is probably the worst in terms of backwards compatibility but it’s also one of the most pleasant to develop for — UIKit/Cocoa is unrivaled in terms of both breadth and depth. One can easily build a top class iOS app with few or no third party dependencies, which is not the case on most other platforms. I don’t think that’s a coincidence… if the iOS dev team were encumbered with maintaining backwards compatibility for upwards of a decade it would be much more difficult to build such a complete and polished toolkit.
  - Wowfunhappy 4y ago
    If iOS had versioned libraries and separate teams maintaining the older branches, would that really impede the modern toolkit? I realize that expanding the scope of a project by adding more developers isn't as simple as it seems, but I feel like there ought to be an organizational/development structure that could make this work. I wouldn't even be opposed to older apps running in some sort of seamless-to-the-user virtual machine.
  - deleted 4y ago
    [deleted]
pram 4y ago
Yeah this is insane. I bought Sonic CD and Sim Tower for iOS years ago and they're both just completely gone. Not listed, impossible to install. I'm never buying a mobile game again. It blows my goddamn mind.

kllrnohj 4y ago

Android's backwards compatibility, especially for apps that don't update, is quite solid. The cases where previously working behavior is broken without requiring the app to "opt-in" to the breakage is generally scoped solely to things that are considered abuse vectors. Which "draws over other apps" unfortunately is. It's not as good as Windows' back compat, no. But then again nothing is, as that's the only platform concerned with preserving not just API compatibility but bug compatibility.

cesarb 4y ago
There's one case I know of where previously working behavior is broken, for something which was not an abuse vector at all: if your app depends on the hardware "menu" button (which is the case for nearly all apps made back when having a hardware "menu" button was standard for Android), for several versions Android showed an emulated software "menu" button next to the back/home/etc buttons, but more recent Android versions no longer show that button, breaking all these apps (since there's no way to get to their menu). See https://www.xda-developers.com/rip-menu-button-android-10-drops-legacy-support-extremely-old-apps/ https://www.xda-developers.com/rip-menu-button-android-10-dr... for details.
BoorishBears 4y ago
Android's backwards compatibility is atrocious with a capital A. Every version has random will-be-breaking changes that get held off if your app was compiled before said version came out, but there's only a release or two before the change starts to ignore your compiled version (for example, when a massive permissions change comes down the pipe, any app that's compiled against the newest SDK breaks immediately, and apps that were compiled against older ones just get to break next release) And just like any mobile platform, apps heavily rely on the OS to provide UI widgets and layout. So even design language changes can (and often do) break the UI. - What you're probably seeing is what developers are forced to work around: the fact that everyone is stuck targeting ancient versions of Android because Android users have just accepted their devices never getting OS upgrades. Android Studio will still default to targeting a minimum SDK version of API 25. Android 5.0. From November 12 2014. The situation is so bad that Google removed it from their dashboard (https://developer.android.com/about/dashboards https://developer.android.com/about/dashboards) and buried it in the IDE: https://9to5google.com/2022/05/20/android-2022-distribution-numbers-chart/ https://9to5google.com/2022/05/20/android-2022-distribution-... Nearly a third of Android devices are on a version of Android >5 years old... just imagine if all your iOS apps had to target iOS 11 as a minimum feature set, and XCode defaulted to supporting iOS 8 for all new projects When the apps can't rely on any newer features, it creates the illusion of backwards compatibility.

culopatin 4y ago

But then in the case of Windows we complain that Windows releases in 2022 still have stuff that looks like Windows releases from 2002. Maintaining that backwards compatibility can become a massive pain too.

jeroenhd 4y ago
I've seen several remnants of Android 2.1 or below in my Android phone in settings and dialogues that don't need much maintenance. They're reskinned easier, but they are there!
VancouverMan 4y ago
Those tend to be the most usable parts of recent Windows releases. It comes as a relief to encounter them.

jeroenhd 4y ago

While you're right that Microsoft has a much better track record for backwards compatibility, this isn't just limited to mobile operating systems. See: Apple breaking x86, deprecating OpenGL, switching platforms, disabling drivers, etc. Most things that actually break on Android break for good reason, in my opinion. I consider giving apps the ability to draw overlays without any kind of permission in a supposedly sandboxed environment a design flaw, for example. I'm more annoyed by their restrictions on dynamic loading but even that still seems to work fine if you avoid the Play Store and set your API targets to a version that triggers the backwards compatibility system. The recent change to the way uploading to Google Play works (where you have Google sign your apps instead doing it yourself) is the worst change in years, but that's technically a Google change, not an Android change. Almost all API changes necessary to run old apps are minute. The permission overhaul for Android 6 (interactive permissions for many permissions that were previously granted install-time) requires a few more lines of code to show an error if the user denies a critical permission but it doesn't require a full rewrite. The consequence is that app devs with some minimal time on their hands can update their apps to work on modern devices quite easily. Only apps that are thrown over the wall and abandoned or created by defunct companies are now broken. Luckily, decompiling most Android apps is quite trivial. If the app is indeed completely defunct with the company disappearing, one might relatively safely maintain a decompiled fork of the abandonware to make it work on modern platforms. It's a pain, but not a dissimilar amount of pain to searching working on NoCD cracks for games that require DRM broken on Windows 10. Enthusiasts do it, quite regularly as it turns out! This is also why I'm in favour of laws about source control for abandonware; if a company doesn't exist anymore and people still use their software, the source code should be opened so customers aren't screwed over. Source escrow isn't unheard of in B2B applications and I don't see why it can't be done for consumer apps.

sgtnoodle 4y ago
Re: source code release, it seems like that could get rather messy for anyone using third party source code that isn't open. Also, right away any sort of law like that would become incredibly nuanced. I have a pacemaker and there's an optional BLE app for it. Security through obscurity is lame, but I'd rather that app's source code not be dumped on the internet if the pacemaker company stops supporting it. The source code wouldn't keep the app going because it is dependent on the cloud, and would only be of value to folk trying to reverse engineer the diagnostic protocol. Personally that sounds like a lot of fun, but it's also hardwired into my heart...

deleted 4y ago

[deleted]

deleted 4y ago

[deleted]