Hacker News Reader

Comment by cfitz | Hacker News Reader

I was surprised to read Facebook's in-app browser accounts for 48% of mobile internet traffic from iOS (versus 34% for Android). Thank you https://twitter.com/BenedictEvans for that stat.

While I am all for escaping the "black box" that is Facebook's in-app browser due to our inability to see what they are loading/tracking on the backend, that likely won't happen until people stop using Facebook all together, as it is more convenient for the everyday user. Simply put, Facebook's in-app browser creates less visual noise than a link opening externally in Safari (where there is often the animation of a new tab being created). This ignores the fact, however, that Facebook requires this behavior and thus I cannot be sure that my above statement "everyday people prefer a more convenient / less UX noisy solution" holds true.

View on HN

Android solved that UX issue with Chrome custom tabs (https://developer.chrome.com/multidevice/android/customtabs). It uses a seamless UI exiting the app and everyone uses the up to date browser on the phone.

iOS also provides a way to have similar UX using Safari View Controller. https://developer.apple.com/videos/play/wwdc2015/504/

there are problems with both, though. i like to click on something and then give a break, and read later. with CCT, I have to consciously go and click on "open in browser", which doesn't work well for me.

Otherwise, CCT and SVC should be the way to go, still much better than FB. Aside from tracking and all, it doesn't get the niceties of a full blown browser.

iOS has Reading List for this purpose, and SFSafariViewController has a button dedicated for this.

I only know detail about the iOS equivalent (https://developer.apple.com/reference/safariservices/sfsafar...) but I'm not expecting Facebook to implement it any time soon as it makes it a lot harder to track where a user goes (you can't access that) and/or inject content into the webview.

On the current Android and iOS implementations a user is far less likely to share on, say, Twitter, because they won't have their Twitter login cookies in the Facebook browser. I suspect Facebook is quite happy to keep things that way.

Android also supports a real Firefox, so one needn't trust one's web browsing to the tender mercies of Google.

I hate every instance of the in-app browser. I always long press on a link and open it in safari whenever that's possible - those integrated browsers don't support my adblock plugin and are already slower than native safari.

TweetBot does a reasonable job here IMHO. It allows you to choose which browser opens links by default -- it supports Firefox, Chrome, Safari as well as its own in-app browser which is a WKWebView, which means it's just as fast as native Safari and respects your content blockers. Choosing a non-default browser is possible by long pressing on a link.

EDIT - (thanks saagarjha) newer versions of Tweetbot appear to use SFSafariViewController not WKWebView.

So I've heard. I've been meaning to install TweetBot for ages, just haven't gotten around to it (and Twitter.ipa is the app in which I most often do the long press to open links).

Actually, it's not that simple. There are a couple ways to load websites on iOS:

* UIWebView: Old, slow, but dead simple.

* WKWebView: The new "WebKit" drop-in replacement for UIWebView. It uses Safari's Nitro engine, and allows for full customization for the chrome, but does not allow for content blocking. Most new apps use this.

* SFSafariViewController: A "Safari view"; you have no control over the UI chrome (or browsing history, etc.), but it uses Nitro and loads content blockers.

* Safari app: The actual app. Loads content blockers.

What advantage does using WKWebView provide for an app over SFSafariViewController? Is it just the ability to change the color and icons to match the rest of the app's style?

Or are apps generally switching over to SFSafariViewController? Curious to hear some iOS folks' thoughts on the matter since I'm uninformed.

Most notably apps can inject arbitrary JS into WKWebView, making it much easier to track The user’s actions.

You can roll your own browser interface using WKWebView — if (for whatever reason) your app supplements the browsing experience, you'd use WKWebView.

SFSafariViewController provides its own Safari-like interface and has an extremely limited set of configuration/customization options.

You may be interested in a little iOS app I wrote that gives you the native Safari experience in almost every app that supports the share sheet: https://itunes.apple.com/us/app/browsecurely-secure-browsing...

Can you actually link to the stat you mention?

Reply on news.ycombinator.com