| |
| ▲ | TheDong 4 hours ago | parent | next [-] | | I have a google nexus 7 tablet from 2013. Thanks to Google unlocking all their bootloaders by default, I can install u-boot and a modern linux kernel on it (thanks PostmarketOS). Since linux runs on it, I can run the latest versions of great pieces of software like ed, slack in a web browser, etc. It is 100% apple's fault that they do not open up the bootloader for devices they'll no longer offer updates for and allow the community to build a custom darwin or linux fork. Even though we paid for the hardware, we are not allowed to use it any longer than apple says. | |
| ▲ | doe88 3 hours ago | parent | prev | next [-] | | It will go as long as certificates chains are valid. | |
| ▲ | swiftcoder 4 hours ago | parent | prev [-] | | > TL;DR sometimes it's not Apple, it's the app devs that deprecate them. Are the app devs deprecating just because their support matrix is too big, or because current SDKs will no longer build apps compatible with those devices? I think the later case is less common on the Android side of the fence, but Apple is not great about keeping old versions of the dev tools functional, and you end up needing to keep elderly Macs around to target older versions of the OS. | | |
| ▲ | plorkyeran 2 hours ago | parent | next [-] | | The primary hard part is testing the old versions. Xcode has decent backdeploy support (Xcode 26 supports targeting iOS 15, the final version to run on the 6S), but there's no way to actually verify that it works other than on an older device that's never been upgraded. It's a pretty substantial increase in testing burden and greatly increases the size of the pile of phones that you need to janitor for your CI setup. Submitting apps to the app store requires using the latest version of Xcode (with a ~half year lag after a new one comes out), so it's now impossible to submit an update to the app store that supports iOS <15. | |
| ▲ | cosmic_cheese an hour ago | parent | prev | next [-] | | It’s because every supported version multiplies support burden and sometimes can prevent use of new APIs that substantially improve quality of life unless the dev is willing to turn their code into a patchwork quilt of version checks (which brings its own problems). On Android it’s less of an issue because the SDK ships separately from the system, but there are often still substantial behavioral differences between system versions under the same SDK that can be a real pain in the rear, especially when it comes to permissions-related issues. This why it’s common for Android apps to have odd bugs or behave strangely on ancient versions of Android — while it’s easy for the dev to produce a build technically runs on a wide range of versions, properly testing against all those permutations of versions and manufacturer skins is practically speaking impossible unless you’re a sizable company that keeps a lab full of devices with CI rigged up to test against them all. | |
| ▲ | eptcyka 2 hours ago | parent | prev | next [-] | | I cannot buy a device without resorting to Ebay to test my app on iOS 17. There are still bugs that manifest themselves on real devices and not on the simulator. And some APIs are just broken on the older releases. | |
| ▲ | mantas 4 hours ago | parent | prev [-] | | As ex-iOS dev, usually it's because devs want the new shinny APIs. And after some point stakeholders are OK to stop supporting a tiny percentage of users stuck on old iOS versions. In my experience it was never because of Apple. |
|
|
