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.
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.
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.
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.
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.
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).
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.