In olden times, when mobile apps wanted to show web content, they would open the URL in the default browser. This caused the browser to become the active application, and depending on the platform, may have also required the user to perform more than just a single tap to return to the previous app. Keep in mind that this was happening while apps were just beginning to gain traction and marketers were scrambling to identify valuable metrics in this new app space. In the effort to keep metrics going “up and to the right”, it was only natural that publishers would want users to stay in “their” app for as long as possible, and lo! The in-app browser was conceived as a means to this end.*
*Kirk’s completely fabricated in-app browser origin story
What are in-app browsers and what problems do they solve?
In-app browsers on iOS and Android are similar in many ways. Both are usually created by making instances of WebViews (supported in Android v1, iOS 2+) and by loading either a public URL or some content from your app’s resources, or a string of HTML into this instance via public methods. Both provide public methods for crude navigational controls (e.g. go back or forward), access to the JavaScript environment from native code, as well as a means for customizing the User Agent string. Each also offers their own platform-specific methods for enabling/disabling bits of functionality (e.g. enable Web Storage API, allow inline and automatic video playback).
What do Facebook and Twitter do for in-app browsing?
The most popular examples of apps that use bespoke in-app browsers are probably Facebook and Twitter. Twitter on iOS and Facebook on Android feature a read-only navigation bar, iOS Facebook’s navigation bar accepts user-input and does more than just search the web. Both browsers provide crude navigation controls for forward and back: no bookmarks, tabs, shared sessions, or shared cookies. Facebook offers a way to “save” URLs but this is separate from the default browser bookmarking experience. Both browsers sport “share action sheets” which are confined to sharing URLs on their individual platforms and for opening pages in other browsers. Analytics platforms refer to these experiences as “Safari (in-app)” rather than enumerating the source applications. Twitter on Android appears to use Chrome Custom Tabs, which is discussed in more detail below.
What security risks do custom in-app browsers present for users?
When browsing content from in-app browsers, users may not be aware of the security risks they face. Before its whitelisting restriction in iOS 9, apps could use the method “canOpenURL” to detect the presence of thousands of installed apps via custom schemes to serve targeted advertisements, later deemed a violation of privacy. In a similar way in-app browsers might also put too much power in the hands of publishers, for example SSL errors can be bypassed or ignored (on Android) and the JavaScript environment is accessible (callable) from native code on both platforms. What this means for users is that unscrupulous publishers can bypass some security features normally available on default browsers in order to gain access to potentially sensitive data.
How hard is it to create your own in-app browser?
Creating your own in-app browser is not a difficult task, however making a “great” in-app browser is nontrivial. Out of the box there is no WebView “chrome” at all: no navigation bar or buttons, just the loaded HTML page consuming as much screen real estate as you choose, controlled programmatically by the host application. You can customize the UI to differentiate from the default browser, but you likely don’t have as much time, resources, or research as the real browser vendors do, so achieving greatness may be difficult. Basic features such as bookmarking, tabs, shared sessions and cookies, reader mode, and private browsing are “free” when using the default browser, but require significant effort to duplicate and/or improve upon. And while you can enable some advanced options that may be crucial to your app’s use cases via platform-specific WebView APIs, you are now also the maintainer of a browser in addition to focusing on whatever else it is your app is doing.
Have platforms provided any recent solutions for in-app browsing?
In Android, users have always had the hardware “Back” button, but this hasn’t always been the case with iOS. So even while the Android physical “Back” button is generally expected to return the user to the previous app for the price of a single tap, iOS did not receive this functionality until iOS 9 (as an “afterthought”) with the very small “Back to App” button that appears in the top leading edge of iOS to return a user back to an app that has opened a current foregrounded app. Right at the same time (since Android 45 and iOS 9), both platforms also began to provide superior in-app browser experiences via Chrome Custom Tabs (CCT) and Safari ViewController (SFSVC), henceforth collectively referred to as Integrated In-App Browsers (IIAB).
How are IIAB different from traditional webviews?
IIAB provide a simple API for creating in-app browsers when your app isn’t primarily focused on providing a unique browsing experience. Both provide a read-only, link-driven navigation experience, including forward & back buttons, bookmark & sharing integrations, a button to close the IIAB (to return focus to the app), and the ability to customize some UI colors. iOS additionally provides reader mode and content blocker integration, and neither offering includes an interface for viewing multiple tabs simultaneously. One of the primary user-benefits of IIAB is the sandboxing of the browser functionality, meaning that the app does not have access to potentially sensitive user data. Additionally, the JavaScript environment is not callable from the main application, and SSL cannot be ignored or bypassed, so the experience is significantly more trustworthy for users. Finally, integration with the default browser’s sessions and cookies as well as auto-filling of passwords and other similar features provide extra delights for users.
How are the Android & iOS offerings different from each other?
For developers, while IIAB are generally similar, there are a couple of areas where they differentiate significantly from each other. For example, on iOS you also have the ability to programmatically close the SFSVC, but Android does not currently support this operation (although there is an open ticket to address this functionality). Additionally, if you wish to open your app from a URL from inside the IIAB via deep-linking, on Android this requires a physical user gesture (iOS does not at the time of this writing). Although iOS also provides the “mechanical” ability to create a detached, invisible SFSVC to create a seamless “magic” authentication experience for your users (not achievable with CCT), you are expressly forbidden from doing so in App Store submitted apps per article 5.1.1 Data Collection and Storage, section vi of the iOS App Store Review Guidelines.
In 2017, if you’re still using a hand-rolled in-app browser within your native mobile application, hopefully you are providing a vastly superior experience for your users. If this is not the case, you should immediately look into using Chrome Custom Tabs and Safari ViewController to provide your in-app web browsing experiences. Doing so is easy and will provide improved trust and security as well as a better browsing experience for your users.
Kirk is on twitter at @dmvjs.