As an iOS dev of 7 years, year to year changes are generally mild and impact is generally low, particularly if your app is built with UIKit.

For the past 4-5 releases the worst I’ve seen in the apps I’m responsible are a small number of minor non-breaking quirks… think things like a button rendering slightly oddly. It’s never been beyond what a single dev could handle.

Android on the other hand…

>Android on the other hand…

Yeah. Hence why Kotlin is a dead end and React Native is more or less the new standard.

I am not an iOS dev, but is it possible that banking apps (and I admit they're slow at adapting) depend on certain APIs that have changed, or Apple deciding to enforce a use of a specific API for a specific type of apps?

I am asking to learn.

It’s definitely possible. But iOS deprecated APIs, iirc, it doesn’t just delete them. (At least that’s what I remember from iOS dev four years ago.)

I conjecture that the bank didn’t bother to test the app on a new version of iOS until this week, found a major bug, and knew they couldn’t fix it fast enough.

But they could have tested three months ago when the beta came out, and any major issues (like using an old API) probably would have occurred then.

With a few exceptions (mainly where hooking into the kernel is concerned), deprecated iOS/macOS APIs tend to hang around for many years after deprecation.

If I coax a random FOSS Mac app project from the early to mid 2000s into compiling on modern macOS there’s usually deprecation warnings left and right, with many of the deprecations having happened in OS X 10.2-10.6 (well over a decade ago), but it’ll still work fine.

So devs usually have plenty of chance to move things over. The grace period just isn’t indefinite like it is with e.g. Windows — sometimes the deprecated APIs are removed 5-6 releases down the road and so it’s a good idea to move off of them sooner than later.