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.
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.
The Android SDK (software development kit) sets a minimum version of Android that it supports, as explained by another Q and A:
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.
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.
In the desktop browser market, Chrome is the vast leader in usage.
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.
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.
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.
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.
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 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. 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 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.