> That doesn't seem true, I can easily imagine an app that's based on Firefox but can still cause a WebKit page to open, you just need a system API that uses WebKit.

It's still not using two different browser engines for the same purpose. This is no different than having two different apps that each use a different browser engine. The attacker needs the app to be using the exploitable browser engine in the context where they can deliver an attack payload, not in some other context.

You can also improve this situation for system APIs by making the API open the page using the user's default browser instead of one hard-coded by the system or the app.

> That's not how the app update lifecycle works, they're all independent. (Otherwise they'd break a lot more easily.)

Breakage isn't common when systems implement this properly. When you get the new version of libssl from apt, all the packages that depend on it get updated and it's unusual for any of them to break.

I’ve worked on Android apps that embed a browser engine but also use native web views. I doubt it’s rare. They’d exist on iOS too, if it were possible.