In-App Web Viewers vs. Safari

I recently got into a bit of a twitter argument with Dan Frakes of Macworld about apps that have links to web pages and open those pages in their own web viewer within the app, instead of handing the link to mobile Safari (hereafter just called Safari as this is an all iOS discussion) and letting it handle it.

Most apps do this because it became the norm when there was no multitasking on iOS. Switching away from an app meant shutting it down. Reopening it sent you back to the beginning. Apps avoided this 'return to the beginning' by opening web pages in a browser built into the app. It worked around this limitation nicely.

But under iOS 4 when an app supports multitasking it can save its state so when reopened it returns to the same exact state it was left in. This means it can send the user to Safari, and when the user returns they resume right where they left off.

When an app with an internal webview works perfectly the workflow is:

• Click link in app
• webview opens
• read web page
• close app's internal web browser
• return to what I was doing

When an app sends the link to Safari the workflow is:

• Click link in app
• Safari opens, read web page
• Double-click home button, click app icon
• return to what I was doing

That double-click home, then click the app icon is the only complaint about this process I've seen that I think holds any water. More on that later.

So why is opening in links in Safari better than opening web pages in an internal page? Because the internal web browsers randomly break on many web pages, plus many actions I typically do when reading web pages aren't available to me.

The number one broken web site on internal browsers is YouTube. I've yet to see any browser but Safari that can open a YouTube page and have the video actually work. Additionally I've seen many other pages break because the internal web browsers User Agent strings are set to something weird which websites don't identify correctly and then present really broken web pages.

The workflow for working with an app that opens links that won't work with it's internal viewer is:

• Click link in app
• webview opens
• Me: "oh it's a YouTube page" (frequently disguised behind a URL shortner)
• Click button to bring up menu of other options
• click button to send web page to Safari
• watch video
• switch back to app
• close app's internal web browser
• return to what I was doing

For an app that always hands off links to Safari the workflow: Click link in app Safari opens, watch video Double-click home button, click app return to what I was doing

One of Dan's points was that with internal webviews context sensitive options are available. In other words when you click a link in a twitter app you're most likely want to do twitter things with that link in the future. This is true occasionally, but far more often because it's a web page I'll want to do many more web things with it than twitter things.

What if I want to make a bookmark to the website so I can read more goodies in the future without waiting for someone to tweet about it? Can't do that with an internal web view, i have to send the link to Safari then bookmark. What if I want to send the link to some other web service? Apps with browsers are pretty good about supporting Instapaper these days, not so good at supporting Read It Later, and pinboard.in support is very rare. But all these are available in my Safari. Future ones not yet invented won't have to wait to get popular enough to be supported by iOS apps, they just need to support Safari and app support is there.

One final pain is when the link is to a website I frequent and when I'm finished I want to comment on the article. But since this isn't Safari I'm not logged in. Now I have either go fetch my password from 1Password in order to login via the internal web page, or send the page over to Safari where I'm already logged in.

Felix Metzger on twitter mentioned that sending links to Safari has the disadvantage that returning to the original app is 3 taps (2 on the home button, one on the app). He's correct, and you'll have to do this every time. My argument is that this is so LESS annoying than randomly having pages not working and then opening them in Safari anyway (frequently requiring 2 or more clicks), that the 3 click return for every link doesn't bother me at all. I already do it for every broken link, plus I have to then additionally close the internal web viewer in the original app -- adding one or two more clicks that wouldn't have been necessary at all.

Sending links to Safari always works (so long as the website itself is in working order). The workflow is consistent every single time, click link, go to safari, read web page, 3 taps to return. Internal web viewers frequently break, I estimate around 10% of the links I get don't work at all and another 10% end up with me opening in safari anyway so I can bookmark or comment or add to pinboard. That means the workflow is sporadic, sometimes it works, sometimes it doesn't. The Mac way has always been to go for the method that "just works". Internal web viewers don't. They should go away.