No you dont get it. It's not about maintaining or not, its about what a developer spends their time on. Do you want the developer to spend months moving the code from one legacy API to a new one, that will give the user no tangible benefit, or do you want the develop new features requested by the users?
“No tangible benefit” is a very weak assumption. Upgrading to new APIs means familiar UI controls, possibility of integration with system features - off the top of my head, iCloud copy & paste, versioning, handoff, low power/data mode, form inputs behave the same as everywhere else, font rendering, window controls - all very tangible for users.
Except there's no reason those things couldn't be supported in an existing API with less friction to adopt. It's software.
I think the reason software abruptly changes (API switches, rewrites, UX redesigns, etc) is because doing that employs more software people than incremental improvements to old stuff. I don't think this is necessarily a choice, it's just the way it works out.
It's kind of a perfect business in that way. The downside is that occasionally an important customer says "enough!" They're totally justified in doing that, but it doesn't align with growth, so it's the cost of business.
> Do you want the developer to spend months moving the code from one legacy API to a new one
If the situation demands it I would say yes. I treat it as one big refactoring job. There are lots of shims in old software libraries that may not need to be there anymore. There are also lots of vulnerabilities that a fresh set of eyes and a different perspective can illuminate. A product that began its life being developed by a lone developer may have an entire team now. The rewrite is a good opportunity to explore how it works and why certain decisions were made.
