iOS Back Button Confusion

Since I purchased my iPhone in September, I’ve had a consistent issue that is prevalent in many iOS apps. While small, it is a source of frustration nonetheless. My issue: back button confusion with embedded, in-app browsers.

Let me explain what I mean.

When a link is opened, many apps utilize an embedded web browser to display the web page instead of exiting to Safari (e.g. tapping a link in a tweet in the Twitter app). Upon opening, a traditional “app” back button is placed in the top left (let’s call this the “app back button”) which exits the browser to the screen where the link was tapped. The browser also gets it’s own back button for going backwards in the web browsing history (let’s call this the “browser back button”) placed at the bottom of the screen. This results in two back buttons on the same screen.

While this design is functional, having multiple back buttons on the same screen means I have to choose which one to use: do I want to go back in the app or browser history. While this is a simple decision that makes sense after conscious thought, it doesn’t feel natural. Since I wasn’t in a browser to begin with (remember, I tapped a link in an app), the website feels like an extension of that app and therefore I instinctually reach for the app back button, regardless of whether I wanted to go back in the app or the browser history. If I wanted to go back in the browser history, then I’ve made a mistake. This results in the browsing history being lost with no way to easily undo it; the only way to get back to the last web page is following all of the links again which is both annoying and takes time.

I’ve thought of two possible solutions to this problem (though I know there are far more out there) which I believe would fit nicely with the existing UI paradigms in iOS, and solve the problem explained above.

1. A single back button
2. The ability to undo exiting the browser

A Single Back Button

This solution would remove the confusion by having the app back button as the only back button; the browser back button wouldn’t exist. This button would go back through your web history until the first web page, then exit the browser back to the app. There is a major flaw, though; repeatedly tapping the back button could take too long if you’ve built up a history larger than a few pages in that browsing session (not unusual, especially for power users).

The Ability to Undo

This option would give the user a method to undo their action of exiting the browser, returning them to where they were before they tapped the wrong button.

To accomplish this, I propose that tapping the original link in the app immediately after exiting the browser would return the user to the same web page, with the browsing history restored. If, however, you tap another link or change screens in the app, that browsing session would be lost.

An example scenario for this solution would consist of the following steps:

1. Tap a link to an article in a tweet
2. Embedded browser opens the link in-app
3. Tap a link in that article to read supporting information
4. Want to return to the original article to continue reading, but accidentally tap app back button
5. Returned to the tweet and realizing the mistake, quickly tap again on the link to the article
6. Embedded browser opens to the supporting information, not the article, with the browsing history restored
7. Tap on the back button for browser history to return to the original article and continue reading

I believe this behaviour would feel very natural to users and is similar in concept to fast app switching since state is being restored.