My mother had a shopping app on her old smartphone which runs Android v6. Recently I noticed that the app on her phone was no longer supported. I've seen such things happen on old phones generally with many apps. I just wanted to know, why do companies drop their support to older OS versions after few years? Does it cost them a lot to continue the support to older OS versions as well? Does it require a whole team to be hired to just keep managing the support for older OS? Just being curious about this. Thanks.
7
-
you can install old app version from apk mirror– alecxsCommented Mar 4, 2021 at 7:45
-
12"Does it cost them a lot to continue the support to older OS versions as well?" - Yes, it costs money. The developer has decided that their Android v6 user-base is so small that dropping support would not affect their usage stats in any noticeable way.– MonkeyZeusCommented Mar 4, 2021 at 19:21
-
1Could you look at that the other way round, and consider how much effort should be put into making new versions of Android support old(er) apps?– Robbie GoodwinCommented Mar 4, 2021 at 22:06
-
you can go to xda to see if there's a custom build of a newer Android version for your phone– phuclvCommented Mar 5, 2021 at 15:27
-
Supporting something old costs money and limits time and effort that can be invested into improvements without having any real benefits from it so people tend to drop support if the user base falls below the point of being worth keeping support. Besides that, the changes in Android versions are usually requiring changing how things work, so you need double the work - once to make the old version work, and for every new version possible the same thing but just in a different way - all that costs a lot of money just to maintain without any additional improvements or investments.– ChapzCommented Mar 5, 2021 at 20:43
|
Show 2 more comments
7 Answers
There are two ways to support old Android versions:
Build one app that makes use of compatibility patches to supports old Android versions (down to a specific version) but also support all modern Android versions.
Build two or more apps each for a set of Android versions.
The second option is of course very costly as you have to develop maintain each app app version independently (or at least large parts of the app). This way is often not used or only if the app has been completely rewritten for new devices and for old devices the old version remains with minimal to no support.
Therefore the common way is option 1 – one app that has all compatibility fixes included. The main problem is that newer Android versions include interesting new features that are not (fully) available using the compatibility system Google provides. Therefore if you want to make use of them and the functionality is not optional in your app, app developers may decide to drop support of older Android versions in favor if being able to use new features of new Android versions. Decreasing the number of supported Android versions simplifies the app as old workarounds can be removed and don't have to be maintained anymore. And of course it removes the necessity to test the app on such old devices which can be a problem if you want to test your app on physical devices (not emulators) as old devices break and are more and more difficult to get.
-
16In addition, Support of anything has costs. If I have create a new app and a new version of Android comes up, I now need to run tests to make sure that the app (and any changes I make) run on two versions. When a third version comes out, I need to run tests on three versions - and so on. If I say I support an older version, but I don't actively support that old version and old version users notice a bug, I'll get dinged in reviews. It just costs more to support more versions.– Flydog57Commented Mar 4, 2021 at 17:03
-
3Also, if you can't support newer features on older platforms, then you will be getting reviews from people who can't enjoy those newer features. They may even complain in the reviews about their absence. Commented Mar 4, 2021 at 22:22
-
Option 3: Provide parallel implementations inside the app for features that require APIs that are either not available in oldest supported Android version or have been deprecated in new Android versions. Another point is that to actively support vintage Android versions, you need a collection of vintage phones. If you don't already have them or they break, buying them is going to be difficult.– ojsCommented Mar 5, 2021 at 8:43
-
"if you want to test your app on physical devices (not emulators)" — emulators for older Android versions also provide worse emulation. More things that work on emulator which then break on a physical device or vice versa. I've a gut feeling that older OS versions are also tinkered with more by vendors, so you get further away from a vanilla Android that with newer OS versions. Commented Mar 5, 2021 at 14:33
-
It’s possibly worth noting that this is no different from any other platform. All major software eventually stops supporting old platforms, it just comes down to when they stop supporting specific versions. Commented Mar 7, 2021 at 0:02
The Android SDK (software development kit) sets a minimum version of Android that it supports, as explained by another Q and A:
https://stackoverflow.com/q/24441178/1836461
https://stackoverflow.com/a/61087797/1836461
Developers/companies (referred to as just "developer" from now on) can choose to support older version, but it gets hard to maintain that code. Speaking as a developer, it can be difficult to remember what settings or commands mean to different versions of an OS. Some of these differences are even deprecated (disapproved of) or completely removed from the newer SDKs, which makes it difficult or impossible to maintain backwards compatibility. And sometimes it's removed because of good reasons, usually meaning that it has significant security issues.
And just because the app is dropped, it doesn't mean that there isn't a newer version available. Some companies may rewrite their software completely (for various reasons including getting rid of large amounts of unnecessary legacy code), then post it as a separate app, leaving the previous version available as their idea of backwards compatibility.
In fact, most non-mobile software development is done like this. The old version is still available somewhere when a new version is released. Mobile stores like Google and Apple don't have an easy way for a user to get older versions, even though the developer can still see those old versions.
Other reasons
A company may also decide that their method of communication (protocols) need to be updated to newer specifications that aren't available in old versions of the SDK. If you have an app written in an old SDK that works with old phones, but you need/decide to upgrade those protocols to a security version the old version just doesn't support, you may have to remove some backwards compatibility to get access to the newer standards in a newer SDK. And if you're going to completely rewrite an app, it makes more sense to do it in the latest SDK, rather than one that'll be completely out dated again in 1-2 years.
Even just rewriting an app to clean it up, remove unnecessary functionality, redo the user interface/user experience (UI/UX), or 100 other reasons, using the most recent SDK also makes the most sense.
The Answer I linked to above talks about 25% of Twitter users being ignored because of platform changes due to an upgraded app. Well, those 25% are the older phones that will likely be the fastest shrinking group of phones around. They will eventually be broken, dropped, the battery ruined with no replacements available, or a 1000 other reasons, including other apps ceasing to support them. I'm not saying it's a good move to remove that many users from using your app all at once, but evidently they thought they could survive it.
Parallel example
In the desktop browser market, Chrome is the vast leader in usage.
https://netmarketshare.com/browser-market-share.aspx
https://en.wikipedia.org/wiki/Usage_share_of_web_browsers
As Internet Explorer (IE), Edge, Gecko, Firefox, Safari, and others have fallen out of use, developers stop doing as much cross-browser compatibility. As someone who's done that as well, it's a total PITA, especially when a requirement is pixel perfect compatibility, which is pretty much impossible. I have 5 browsers installed because of this reason, yet I only use 1 for browsing.
Some companies will insist on supporting IE and Edge, because "it's installed as the default on computers and most of our users don't know to install something else". It doesn't matter how few people actually use IE or Edge, because "the statistics are taken from sites where most users are devs or higher level computer users". But the reality is that the majority of browsers aren't worth the time to support. People don't support Netscape Navigator anymore, even if there is someone still running Win 3.11 for Workgroups, Win 98SE, or Mac OS 8.5.
Conclusion
What I'm saying saying is at some point, you have to draw a line as to what you're going to support, as older versions cease to be useful or usable by both the user and the developer.
Spending time, money, and effort on old versions that aren't heavily used isn't usually a good use of resources.
Sometimes this is strictly a "make more money" ideal, in that the developer wants to force you to buy the new version, but that's not always the case. It makes more sense to developers to spend more time on new features and relevant bugs in a new version than new features and bugs in the old version.
-
1I think your browser example is a bit too extreme. Netscape isn't supported because its EOL was 2008. Edge/FF/Safari/etc are still actively developed. According to your first link, Edge has a marketshare of 11.4% (and a constant upwards trend). Firefox has 6.5%. That's still pretty significant. Chrome has 68%, so if you only support Chrome, you exclude 32% of users. Your second link has very different percentages (safari rises to a significant 19%), but shows the same problem (only supporting Chrome excludes 37% of users).– timCommented Mar 6, 2021 at 7:42
-
To get back to Android, only supporting Chrome would be akin to only supporting above Oreo. Oreo is still not EOL and has a marketshare of above 15%. Deciding not to support it would be an odd decision which imho justifies questioning why that is. Marshmallow (OPs example) also still has significant usage (around 6%), but it was EOL in 2017. Not having security updates for 3+ years would imho be a good example of a valid reason to drop support.– timCommented Mar 6, 2021 at 7:46
There is more money in forcing users to upgrade to newer versions of Android, which in turn requires buying new hardware to run the newer version of Android.
To make this happen, the developers of Android change the programming APIs little by little as new versions come out. New ways of doing things are added, and old ways of doing things are removed over time. Bugs in the APIs that older software depended on are fixed, and no effort is put in to maintaining the old behavior to maintain compatibility.
Doing this forces app makers to constantly maintain their software and release newer versions of it with minor changes. It costs more money to tweak the software so that it works on older versions of Android as well as the latest release at the same time. To maintain compatibility across major versions differences of Android, multiple versions of the app may have to be maintained and distributed separately. This would become quite costly, and since most everyone has a newer device, the market to justify the extra expense just isn't there.
Microsoft's traditional approach has been to go to great lengths to maintain compatibility with older software. Large numbers of applications were tested on their next version of Windows prior to release, and many tweaks were done to ensure compatibility. Because of this, software developers can just make one version of the software that works on an older version of Windows, and it will work on the newer versions as well. With the release of Windows Vista Microsoft began to move away from this business strategy, and is now developing Windows 10 in a way that more resembles Android, but Windows compatibility with older software is still better than the mobile operating systems and even Mac OS X.
-
1Judging from the Android documentation, Android also goes to great lengths to maintain compatibility. Although, in some respects, that seems to be changing now, in the interests of “privacy”. Commented Mar 5, 2021 at 4:44
-
Microsoft maintained backwards compatibility because their bread and butter market at the time was government+businesses who are notoriously sensitive to the price of upgrading software. Android's primary market is home users who would rather have new features and forget about the old stuff. Commented Mar 5, 2021 at 20:42
TL;DR answer:
Because programming for each version of Android is slightly different and thus supporting each of them costs extra money. When a particular version is generating less profit than necessary to justify maintaining it, the support is dropped.
-
That calculation is oversimplistic, though. It could very well be the case, that only the fact that an app is available for a platfrom that is not financially viable in itself is the reason that the other platforms are viable, especially if they interact. - Removing support for a financially unviable platform may get other users to stop using the app, making more platforms unprofitable, and so on... Commented Mar 5, 2021 at 7:44
-
@I'mwithMonica Well, it's a TL;DR answer ;) My intention was to post a brief answer that gives a reader the general idea of the situation, without diving into details. Commented Mar 5, 2021 at 8:02
The other answers are great, and they respond to the question directly; let us try a slightly different approach.
Why do people still have phones running such old versions of Android in the first place? Usually it is because their manufacturers no longer support those models. Why not? Surely part of the reason is that the Android developers no longer support old versions of Android.
So not only is it inherently costly to develop apps for old versions of Android, such developers would have to put up with a platform full of known bugs that will definitely not be fixed. Who wants to do that?
Maybe developers will put up with it for a while, if their users demand it. But when there are not many users using an old Android version anymore, it is likely to be dropped.
The issues discussed here and in the other answers also explain why some websites only support the “latest versions” of the major web browsers.
The answers given thus far are factual, but I question the principles behind them, and would like to briefly address the question of "why..." in a deeper sense.
It makes sense that developers would upgrade apps and release new versions -- but in my opinion the release of new versions should not require retirement of older versions. Simply identify them as "unsupported" and let them remain available for those users who cannot run the new version. (Personally, I blame Microsoft for inventing, and making seem "natural," the "forced upgrade" business model in the computing industry...)
Actually, I also take issue with the very idea of "dropping support" at all. One can never be certain that nobody is still using something; I myself am just now getting around to looking at, and trying, some CD-ROM games for Windows 98... (Fortunately, I have never found it necessary to contact Microsoft for support, but somebody else out there may wish to.) Personally, as a software developer, I continue to support everything I've ever written, and have in fact taken support calls well into the 2000s for software I wrote (by which I mean parts of the turnkey host computer for a commercial product) between 1988 and 1997. In effect, this means supporting everything, forever. I reject the claim that this will cost any significant amount of money, because the number of users making demands on that support will decrease (probably inverse-exponentially, but never to zero, mathematically) and require less and less expenditure as time goes on.
-
The problem with this admirable position is the availability of development tools and test hardware. What development tools did you use in 1988, and can you still run them? What operating system(s) did your 1988 products run on, and can you still run those? Commented May 15, 2022 at 22:07
I work on software (math libraries) for quite a few platforms, including Android. I can describe our decision-making process for Android version support. It is not entirely typical, because we only produce native code, and don't touch Java or Kotlin.
We started on Android in early 2018 (so we were late-comers) because an existing customer who used other platforms wanted Android. They wanted to offer apps that dealt with data from their Windows products.
After some exploration and prototyping, we did an implementation, and shipped it in early 2019. The minimum Android version that the customer wanted support for was 5.0, and they only wanted 64-bit native code. Not needing to produce 32-bit native code was welcome, since the software has a lot of automated testing, and avoiding the need to test both 32-bit and 64-bit versions was welcome.
The main problem with needing to prepare in 2018 to support Android 5.0 was getting a 5.x device, since they were getting hard to find. We considered it obligatory to have a device on the oldest (or nearly so) version that we supported, so that we could reproduce version-specific bugs if they happened. If you try hard to ensure things like that won't be a problem, they usually don't happen at all.
We got an Amazon Kindle Fire with an OS based on 5.1, and found some incompatibilities with the 7.0 that we were using on new devices for the main testing. By early 2019 we were in production, testing on 5.1 and 7.0, and claiming support for 5.0 onwards. The newest released Android at the time was 9.x, but 8.x was the newest with any market share.
Android devices don't last forever, especially if they aren't being used regularly. Leaving them unused and unplugged for months is a bad idea, because sometimes they won't wake up again. To make sure that your software works on newer versions of Android, you need to test it on them, and you also need to preserve some devices on old versions, so that you can reproduce customer bugs. The simplest way to do this is to buy new test devices, approximately annually.
At that point, dropping support for older versions of Android was a good idea, because it enabled us to trim what would otherwise be an endlessly growing collection of old devices.
In mid-2020, we updated to a newer NDK, to get a newer C++ compiler, and made Android 7 our minimum supported version. Android 10 was the newest version in circulation, but we'd got some nice fast test 'phones with 9.0, and settled for that.
At the end of June 2022, I changed to Android 9 as the minimum supported. Android 12 was then the current version, and 13 was approaching release. The native code environment doesn't change nearly as fast as the app presentation layer, so updating every two years should be OK.
As of June 2022, according to the data at GlobalStats Statcounter, I'll be compatible with just over 82% of the worldwide Android market, heavily biased towards newer and faster devices. (88.6% of the North American market, 87% of the European market) My ISV customers (my employers don't sell end-user apps) are happy with this.
Update: GlobalStats Statcounter was unreliable for May and June 2023 but seems self-consistent again as of July. This was due to privacy changes in Google Chrome. GlobalStats compile their figures from web browsers that visit a wide range of websites, and updates to Chrome meant that the user-agent strings defaulted to Android 10, irrespective of the actual Android version. There are ways of getting the actual version, but they don't work for devices where the manufacturer has not implemented getHighEntropyValues(). That meant Android 10 was overrepresented.
answered Mar 6, 2021 at 21:03
