> Going back on Android is easy, and back can mean multiple things.
For me, this is one of the worst things about Android. There is zero consistency in what the 'back' button does. Even as a developer this is something I struggle with, what should the back button do in a specific case? Does it go back to the previous screen or does it go back one level in a drill-down navigation (which can sometimes, but not necessarily always, be the same thing).
Sometimes it's up one level in the navigation structure, sometimes it's go to the previous screen. Sometimes it's close a dialog. Sometimes it's even close the application. Depending on the context it could any of these, and it can be unclear which one if multiple could apply. The only way to find out is press the back button and see what happens.
I hate ambiguous user interface elements. When I click on something I'd like to know what action it will trigger.
I'd argue this is a good thing. In Android UX guidelines, the "back" button's "promise" is not that you go back to a specific item, it's that you unwind your most recent action (notably, not unwind state, it's not an "undo" button, just that it unwinds the most recent action).
Apps get to decide what metaphor makes sense for an "action" (maybe it's a page, a screen, a dialog, etc). But users can be confident that the "back" button always takes them "backwards", even if the metaphor various apps use may differ.
Users can feel reasonably safe that the "back" button will take them "back" one 'step' or one 'action' worth, even if the app is using panels instead of pages, or modal dialogs instead of inline alerts
I think the Android approach is: the back button usually does what you want, unless what you want is consistency.
Thoughtfully designed apps tend to set up clear expectations and deliver on them. Thoughtless or malicious apps can be confusing or intentionally mislead.
I disagree, and side with the sibling comments consensus: having switched from Android to iOS this summer, this was the largest friction for me – this and the bad onscreen keyboard, and the buggy text selection (editing URLs is a chore, holding the spacebar to move the cursor is broken when you move too far...)
Also this has always bothered me before switching whenever I used a friend's iPhone for a moment.
The trouble alread begins when some link in Safari opens a 3rd party app.
Sounds weird, but Apple could really learn a lot about UX from Google regarding this "go back" interaction.
It really was a joy how reliable it works even for inception-level nested app interactions.
On iPhone, half of app switches (at least) require me to swipe up or go to the home screen.
And positioning the unreliable sometimes-available back button at the top left has made me drop my phone at least once.
For all that's to like about iOS, "navigation patterns" are not one of them for me.
I don't know what you find bad about the iOS keyboard. I don't think it's brilliant either but I find it much better than Android's.
> the buggy text selection (editing URLs is a chore, holding the spacebar to move the cursor is broken when you move too far...)
I'm right there with you on these.
> positioning the unreliable sometimes-available back button at the top left has made me drop my phone at least once.
As a person with small hands, I hear you. I miss the days of the original iPhone which was probably >90% usable with a single hand.
Even the discontinued iPhone Mini was too large - which I suspect has been most of the reason of its "failure". Comparing with larger phones, the smaller screen is a downside, and it came without the upside of actually being a single-hand device so it's more or less lose-lose.
You can swipe left/right on the very bottom of the screen to switch "back" to apps. The back swipe gesture is for "in app" navigation and is much better than what Android has. The Android back button can do like a million things: dismiss keyboard, go back a page, switch apps, go home, etc. It's a mess.
Thanks, didn't use this before.
I'm not a big fan of so many similar gestures though. I already sometimes accidentally switch tabs in Safari by swiping. Using this app-switch gesture from safari seems like a nightmare when first trying. And generally pretty fiddly. Maybe it needs getting used to.
The swipe area is very small on the vertical axis and there's also some risk of hitting in-app buttons, especially if apps place buttons at the bottom — although I guess this is discouraged. It's especially annoying when using a phone cover. And I like mine - iPhone would be unusable for me without it because it's also much more fragile than all my previous budget Android phones.
Will try getting used to it though.
Re your "It's a mess" comment: I've never had a problem with the android back button, it always did exactly what I expected and it was easy to build an intuition for it.
The context-dependand behavior always seemed very well thought-out to me, because I never ever had to think about it.
It's analogous to the browser navigation. It's entirely to the app to decide which screens and interactions are part of the navigation tree and which are not.
For me, this is one of the worst things about Android. There is zero consistency in what the 'back' button does. Even as a developer this is something I struggle with, what should the back button do in a specific case? Does it go back to the previous screen or does it go back one level in a drill-down navigation (which can sometimes, but not necessarily always, be the same thing).
Sometimes it's up one level in the navigation structure, sometimes it's go to the previous screen. Sometimes it's close a dialog. Sometimes it's even close the application. Depending on the context it could any of these, and it can be unclear which one if multiple could apply. The only way to find out is press the back button and see what happens.
I hate ambiguous user interface elements. When I click on something I'd like to know what action it will trigger.