> And yet, many iOS apps end up using screen space on a Back button.
I did not say "back" is a bad idea (seriously, read what's written, not what you think would be the easiest to pithily reply to). "Back" is a good idea when it is coherent and/or explorable. Which the android "Back" button is not, because it's mystery meat navigation.
iOS apps use screen space with a "Back" button, and that back button generally tells you where you're going to go back to[0]. Android's back button does not, you might go up in the application's hierarchy, you could go sideways into an other object of some sort from which you originally came, you could go to an other application, and you have no way to know without learning how each and every application hooks into that button.
[0] that's Apple UI guidelines, although even when applications don't implement it they won't just drop you into an other application "at random".
On Android you always go to the last Activity, whether that activity is from the same application or a different application. When you get something other than the last activity, that's because the developer is overriding the button's purpose.
> iOS "back" button is generally an "up" button, not a "back" button.
So's it on Android[0], except when it's a back button, or something else entirely.
Which, you may want to note, is the very issue I originally outlined with it: Android's back button behaves inconsistently and provides no way to discover its behavior in advance.
> For that reason, it's not nearly as useful as Android's.
Inconsistent behavior precludes usefulness. The iPhone's "back" buttons behave consistently (and explain where the user will land, if Apple's HIG are followed). Theoretically the Android back button could be more useful than iOS's, practically that is not the case.
> If your app was reached via the system mechanisms of notifications or home screen widgets, Up behaves as described for app-to-app navigation, above.
> For the Back key, you should make navigation more predictably by inserting into the task's back stack the complete upward navigation path to the app's topmost screen. This way, a user who has forgotten how they entered your app can safely navigate to the app's topmost screen before exiting it.
> For example, Gmail's Home screen widget has a button for diving directly to its compose screen. After following that path, the Back key first returns to the Inbox, and from there continues to Home.
You're quoting the reference I myself quoted elsewhere in these comments. I quoted it as evidential support for a trend in Android that I decry - one that may drive me away from Android, along with its movement away from the menu button towards cryptic app-specific icons and inconsistent menu button placement.
I did not say "back" is a bad idea (seriously, read what's written, not what you think would be the easiest to pithily reply to). "Back" is a good idea when it is coherent and/or explorable. Which the android "Back" button is not, because it's mystery meat navigation.
iOS apps use screen space with a "Back" button, and that back button generally tells you where you're going to go back to[0]. Android's back button does not, you might go up in the application's hierarchy, you could go sideways into an other object of some sort from which you originally came, you could go to an other application, and you have no way to know without learning how each and every application hooks into that button.
[0] that's Apple UI guidelines, although even when applications don't implement it they won't just drop you into an other application "at random".