> You fail to understand how software development and maintenance works.
OK, dude. It's not like I've been in software for 25 years, 15 of them being on mobile, both on the OS side and on the third party app side. But, yea, I fail to understand.
On the 3p side, I've heard all the lame excuses, and they are almost all excuses rather than reasons. The big one is that supporting older versions blows up the test matrix (the number of device/OS/API level combinations that need to be validated). I can understand if you're a hobbyist, you might not be able to afford to buy the "myriad of different devices" and aren't staffed to test your app on each one. But if you are any kind of serious business, you signed up for this investment when you decided to write apps. Throwing a couple of older devices running older OSes onto that test plan should not blow your budget, and if it does, you probably shouldn't be writing that banking software to begin with. Also, almost all of your testing is automated, right? (Please say Yes). So it's not like you need to hire more human testers as your test matrix grows. If you are unable to support more than the bleeding edge OS, it makes me wonder what kind of fly-by-night developer shop you are.
The second excuse is about valuing developer convenience over users. "Oh, the new OSes contain cool new stuff that we want to take advantage of, and it's a total bummer to maintain the code paths that support 'legacy' devices." You already have the code that runs on the previous OS or API level, you're choosing to get rid of it, deliberately throwing users under the bus, so that you can clean code up or at least not have to maintain it. Bad tradeoff IMO.
There are a whole bunch of other little excuses for no longer targeting older systems, and most of them boil down to either cost, laziness, or a skill issue. None of them respect the end user.
I have a little more sympathy on the OS side. Sometimes a major step forward on the hardware (particularly the CPU architecture) might make it really tempting to cut off previous versions. I still think both major mobile OSes cut off old devices way too early. I have PCs from the early 2000s that can still run modern Linux distributions, so support for old hardware is usually technically possible, just inconvenient and costly. I'm not asking companies to support devices from 20 years ago, but they could.
Your "security holes" excuse is ridiculous: All major OS vendors already provide security updates to at least 5 previous major OS releases. There is no security reason for an app developer to support only the bleeding edge latest OS.
Part of it is also Apple. They don't hesitate to break things across OS versions, whether it's on iPhones or Macs. Unlike Windows which will run basically anything ever built for Windows. Also AutoLayout is bad at adapting to new screen sizes. The iPhone app I built in high school targeting a 3GS was more futureproof than a lot of newer apps cause I just used C macros to calculate UI sizes/positions.
End result, even a simple "fart button" app has probably broken several times.
> Throwing a couple of older devices running older OSes onto that test plan should not blow your budget, and if it does, you probably shouldn't be writing that banking software to begin with. Also, almost all of your testing is automated, right? (Please say Yes).
OK, dude. It's not like I've been in software for 25 years, 15 of them being on mobile, both on the OS side and on the third party app side. But, yea, I fail to understand.
On the 3p side, I've heard all the lame excuses, and they are almost all excuses rather than reasons. The big one is that supporting older versions blows up the test matrix (the number of device/OS/API level combinations that need to be validated). I can understand if you're a hobbyist, you might not be able to afford to buy the "myriad of different devices" and aren't staffed to test your app on each one. But if you are any kind of serious business, you signed up for this investment when you decided to write apps. Throwing a couple of older devices running older OSes onto that test plan should not blow your budget, and if it does, you probably shouldn't be writing that banking software to begin with. Also, almost all of your testing is automated, right? (Please say Yes). So it's not like you need to hire more human testers as your test matrix grows. If you are unable to support more than the bleeding edge OS, it makes me wonder what kind of fly-by-night developer shop you are.
The second excuse is about valuing developer convenience over users. "Oh, the new OSes contain cool new stuff that we want to take advantage of, and it's a total bummer to maintain the code paths that support 'legacy' devices." You already have the code that runs on the previous OS or API level, you're choosing to get rid of it, deliberately throwing users under the bus, so that you can clean code up or at least not have to maintain it. Bad tradeoff IMO.
There are a whole bunch of other little excuses for no longer targeting older systems, and most of them boil down to either cost, laziness, or a skill issue. None of them respect the end user.
I have a little more sympathy on the OS side. Sometimes a major step forward on the hardware (particularly the CPU architecture) might make it really tempting to cut off previous versions. I still think both major mobile OSes cut off old devices way too early. I have PCs from the early 2000s that can still run modern Linux distributions, so support for old hardware is usually technically possible, just inconvenient and costly. I'm not asking companies to support devices from 20 years ago, but they could.
Your "security holes" excuse is ridiculous: All major OS vendors already provide security updates to at least 5 previous major OS releases. There is no security reason for an app developer to support only the bleeding edge latest OS.