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