I have a pet peeve. In the past couple of years, it’s become increasingly common for apps to use built-in browsers rather than directing you to Chrome, Safari, or your browser of choice when you open a link. This is annoying at best, and counterproductive at worst – and it should stop being the default behavior for most apps that do so.
Note: This largely applies to both Android and iOS, but since I use Android 99% of the time, that’s the perspective I’m writing from.
I do a lot of work on my phone. I research pages, draft articles, compose emails, send messages, whathaveyou. Half of that work happens in a browser (Chrome), the other within apps.
When the two start to mix, things get messy.
Google itself is one of the worst offenders. Say I’m reading through my Gmail inbox, or searching for something on the Google app. The default behavior for both of these apps is to open links in a browser built into the app.
In this case, it’s technically a Chrome Custom Tab, which carries over many of Chrome’s features and lets you switch over to that browser quickly if you need to. Google actually created Custom Tabs to improve on the even-worse WebViews apps used to use – and sometimes still do (more on this later).
It was a welcome improvement. But I still think it’s more annoying than simply, you know, opening the link in Chrome.
For reference, Chrome Custom Tabs look something like this:
It’s all fine and dandy if I only ever open a link for a quick, one-stop perusal. But often, opening a link means I’ll be doing further research, or at least spend some time browsing. If someone sends me a Wikipedia article, for instance, chances are it’s going to send me down a tab-tastic research rabbit hole.
Problem is, you can’t open multiple tabs within an in-app browser. You can’t type in a new URL either. You can’t go back and to read another email without losing your place or any information you’ve filled out. The same goes if you accidentally close the site.
If you want to do anything other than the most basic browsing, you’ll have to tap the menu button and then ‘Open in Chrome,’ which adds two unnecessary taps. Thankfully, most apps let you disable the feature altogether (it’s usually buried somewhere in the settings).
It gets worse in apps like Facebook, which don’t use Chrome Custom Tabs, but instead implement their own WebView interface. Your bookmarks won’t carry over to your browsers. Your login information isn’t saved on websites. You miss out on common features like ‘find in page’ or ‘open desktop site.’ And sometimes web pages don’t even load properly.
Theoretically, in-app browsers are supposed to smooth the transition between app and web. Chrome Custom Tabs, for example, allow you to theme the browser to your app (see the bright red in the Gmail example), and are supposed to reduce load times by allowing apps to pre-start Chrome and pre-fetch content.
But I’ve certainly never noticed a significant difference in speed, and again, I usually end up opening the tabs in Chrome anyway. After all, very few apps use in-app browsers on PCs, and they get by just fine.
Sometime’s it’s not so bad. Twitter’s mobile app, for example, uses Chrome Custom Tabs, but lets you tweet directly from where the URL bar would be in a browser. I never use it and would still argue against it, but it adds some functionality you won’t get in Chrome. And other apps only use built-in browsers to access their own domains, such as for support documentation, or to help enable logins or payment information. That’s fine.
But more often than not, in-app browsers are simply there to keep you from leaving. Roughly speaking, the more time you spend in an app, the more money its developers can make, especially when ad views are at stake. I just caution developers to consider whether spending the time to code an in-app browser is really enhancing the user experience or simply adding more clutter.
Update 9:36 AM ET: Added a bit of background information.
The Next Web’s 2018 conference is just a few months away, and it’ll be ??. Find out all about our tracks here.