We have immensely powerful version control and branching at developers' disposal, much better than at any past time I can think of. Yet, most companies insist on having a single release that increments, and users must take everything or nothing whenever they update.
Phone/OS manufacturers are actually better than most, and both major operating systems do provide security updates in parallel with major (feature) updates, but only for a very short amount of time.
So if you release the feature branch every 3 months after a few years you will have a dozen maintaining branches to backport fixes to, and in which to carefully test that the fix actually works. The problem is linearly worse if you release the feature branch more often.
Select: Base version that will only receive security updates. No changes in features. OR All updates
Edit: By "Base version" I mean the first software version for that device.
Of course, they also fired a lot of their testers, and seem to have thought that testing was something end users do in prod, so...
This has been solved by LTS releases for some time. You have a newest release branch that gets feature updates immediately and an LTS branch which has a full release e.g. once every two or three years, at which point it catches up on features to the then-current newest release branch. The newest release branch doesn't have long-term support and you're expected to take the latest feature update, the LTS branch gets only security updates, the user can choose between the two or three LTS releases currently in the support window or the newest release branch.
Never mind the problem of if you started out on a non-LTS version.
And also the problem of not getting the actually nice updates, and perhaps losing app compatibility.
So, no, not solved at all.
> now I’m trying to think of what I can do to secure their devices if they’re not going to update