Open Radar

 
In-app web browsers are extremely common on iOS, which shouldn’t be surprising at all. They allow developers and users alike to quickly view something on the web without being completely removed from the app they were using just moments prior. Many developers prefer this because it presumably leads to more usage of their applications. Many users like this because it provides a faster and cognitively lighter experience.

But in-app browsers have some pretty massive downsides as well. They can’t access cookies stored by other in-app browsers, nor Safari, requiring the user to repeatedly log in to websites that they should already be authenticated with. iCloud Keychain is great for syncing credentials across devices, but while Safari has access to its data, in-app browsers don’t (which makes sense).

That said, it’s also negligent to ask users to enter passwords into in-app browsers to begin with. Third-party developers can easily access anything that a user types into their applications (http://furbo.org/2014/09/24/in-app-browsers-considered-harmful/), even if the website being accessed is viewed over HTTPS. 

It’s unfortunate that Apple is encouraging this, insisting that developers use in-app browsers for web-based authentication instead of a clunkier-yet-more-secure Safari-based OAuth flow (https://github.com/tumblr/TMTumblrSDK/issues/67#issuecomment-59389152), explicitly favoring user experience over security. There should be an in-between.

It’d be wonderful if Apple provided a “Safari view controller” that developers could present directly from within their applications. This controller would run out of process and work almost exactly like MFMailComposeViewController and MFMessageComposeViewController already do for composing emails and text messages respectively. The app would provide the controller with a URL (and optionally, a tint color), but otherwise what the user does in it would remain secure and isolated from any third-party code, yet fully integrated with Safari.app and Safari controllers presented by other applications.

iOS 8 share and action extensions are further proof that Apple thinks being able to display view controllers from one application inside of another strikes a great balance of security and user experience. Why not let us do the same with Safari as well?

Steps to Reproduce:
Try to display a web browser inside of a third-party application that has the power and security of Safari.app, but the convenience of not kicking you out of the app that you were using.

Expected Results:
A built-in “Safari view controller” class that matches this description would be part of the iOS SDK.

Actual Results:
We must resort to using UIWebView-based custom browser controllers, which are insecure and severely limited when compared to Safari.app