But it will not appear if the app opens the webpage as its own View (instead of opening Safari). In that case, there is no button and the user has to hunt for how to go back. And the user has no way of knowing whether an app will open Safari or will open the webpage itself.
iOS requires users to build muscle memory in learning how to use each app. Android requires users to maintain a back stack in their head to remember what came before. Switching between the two is very jarring.
If it's a full-screen in-app webview, there's a Done button on the top-left; alternatively, you can swipe back from the first page in the webview and it will close the webview and leave you where you were.
If it's a card webview, just swipe it down from the top edge.
> Switching between the two is very jarring.
I think that's the crux of the problem. Someone who's used to one style and has built muscle memory and some kind of hierarchy and ontology of the interaction with the system will have trouble with a different paradigm. That doesn't necessarily mean there's something wrong with either - they're just different, and some people will prefer one over the other.
Switching between GNOME and KDE, or vice-versa, has a similar effect.
To be fair, captive browsers are also a plague on Android apps. I despise them and especially so if there's no way to turn them off in a particular app.
It is literally just one qualification, which doesn't even apply because why would the "back to previous app" button show when you're in the same app. In the meantime you haven't mentioned one inconsistency yourself. If you like discussions with made up arguments may I suggest you check out reddit?
It is consistent. If the current app was opened by another app (e.g. by clicking a link that opened Safari, or if you're in Safari and click a link that opens in another app, etc), the button will be there.
OTOH if the current app was opened manually by the user, it won't be there.
