If Zawinski’s Law applies to desktop software, then I propose a corollary for iPhone apps: every app expands until it includes a web browser. In-app browser design is something I care deeply about, mostly because everybody gets it wrong.

The common implementation, which you’ll see in most apps (notably including Facebook), uses a toolbar with back/forward/refresh controls in addition to the navigation bar.

This is terrible and confusing because users will always hit the wrong back button. I know how the damn things are supposed to work, and I still accidentally back out of the web view instead of navigating back within the view.

Having two back buttons is silly, and it’s obviously a horrible UX decision. There should be exactly one “Back” action, and it should just go take you to whatever you were just previously looking at; your customers shouldn’t need to care about some trivial distinction between a web page within an app and the app itself.

Tweetbot gets this right. (If you don’t use Tweetbot, go buy it now. I’ll wait.)

We did something similar for NYT Now. It’s a simple implementation; on a back button press, we check whether the web view can go back, and if so we tell it to navigate back. Otherwise, we pop the view controller off the nav stack.

This presents one real, obvious problem: what if the web view displays some terrible site that breaks the back button?

We’ve dealt with that, too. If the back button is tapped 5 times, we pop the web view controller off the nav stack regardless of whether the web view could navigate back. Yes, this means you lose the ability to go back 5 or more pages, but this isn’t a common case in our in-app browser, and I’ve heard no complaints about it from customers.

(I think it’s 5 times, anyway. I wrote that code quite a while ago.)

That’s the right way to do things.

Oh, and what about the forward and refresh controls? You don’t need them. When was the last time you used either in an in-app browser? They’re not worth the screen space.