> Don't let developers use patterns, fix it on OS level.
I think Apple hasn't done this because it's not practically possible.
For example, if it's possible to change the content of a view (which it obviously should be), then it's possible to remove all content and and replace it with all new content. If triggered by some user action, this effectively is "going to a new screen". But the OS-level gesture won't work since the developer in question didn't use your proposed OS API call "createNewView", but instead just replaced the content of the current view.
However, Apple could make use of this OS API mandatory in order to pass review. Although I still think there's some subjectivity around what is "a new view" (that I can "go back" from) versus "an existing view with stuff changed" (that I can't "go back" from).
* There is a dedicated control for going back to a previous view / state, that control is always positioned by the OS in a predefined location, and cannot be removed or disabled.
* The OS automatically does the right thing, that is, navigates to the previous view, unless the developer has jumped through hoops to override this behavior (e.g. to warn about unsaved data).
Android does this, and it's very helpful and natural.
Gesture support on iOS feels natural because it's implemented by the application (?).
On Android back gestures usually aren't 1:1 because they behave like a back button. Swipe and let go, then the back action is executed.
Firefox on desktop Linux has better gestures than Android, namely swiping to the right goes back and swiping to the left goes forward. Firefox on Android doesn't, because the OS treats swiping in either direction as a back-button action.
iOS does this too. It doesn’t mean I can’t override it. And that’s what many, many, many people do. Try using an app made in Unity on iOS or Android. It immediately feels janky.
iOS has many faults, but not being able to go back is not one of them.
I think Apple hasn't done this because it's not practically possible.
For example, if it's possible to change the content of a view (which it obviously should be), then it's possible to remove all content and and replace it with all new content. If triggered by some user action, this effectively is "going to a new screen". But the OS-level gesture won't work since the developer in question didn't use your proposed OS API call "createNewView", but instead just replaced the content of the current view.
However, Apple could make use of this OS API mandatory in order to pass review. Although I still think there's some subjectivity around what is "a new view" (that I can "go back" from) versus "an existing view with stuff changed" (that I can't "go back" from).