I've seen DOM manipulation in the wild for other purposes (e.g. clickjacking for sending invites to friends). Beyond that, mostly speculation, yes. But there's nothing preventing the DOM hijacking from grabbing the password right out of the <input> field. (Unless there's some HTML5 permissions on those fields that I'm unaware of, certainly possible).

The other thing here IMO is if I'm a bank, and I have a 3rd party app making OAuth requests... I'll want to verify code before mass release. Or at least limit the amount of bearer tokens issued without approval (Nest does this for example).

Someone should internally want to review code, especially for a bank.

As a bank, if you provide an SDK for 3rd party developers to use, you are not in a position to review the app before release. Only Apple/Google gets to see that code.

The proper solution would be either 1) the ability to register 3rd party libraries with apple and require some kind of integrity check before approval (but even then, the 3rd party app could override library methods at runtime), or 2) code signing the binary blob library separately for every 3rd party developer (but then the problem is enforcement of where developers get the library from -- how do you verify SDK integrity from the bank server side?)

The fundamental problem is that, as soon as you give 3rd party developers the ability to natively integrate with your service via an SDK in their own app, you are playing a cat and mouse game.

It depends if that SDK has an API key barrier or not. I mean if I'm providing 3rd party access, I want to see how each individual app is performing and what it is doing.

But yes, aside from that potential difference, I understand what you're saying.

The presence of an API key is not sufficient to verify the client loaded your SDK with the same checksum as the one you released. The client can modify the code of the SDK to perform any arbitrary logic, including bypassing integrity checks.