It’s me again… complaining about in-app browsers and webviews. I’ve covered my dislike for in-app browsers as part of a Behemoth case study in the past. TL;DR Apps like Twitter, Facebook, and Instagram use webviews within their apps which open like browsers when you click on a link but provide limited functionality. This greatly reduces the capabilities of the web and requires developers to provide fallbacks / feature checking the same way they would old browsers in the past. In general, it’s like these apps are running their own restricted version of the Internet. It’s the new “This website runs best in Google Chrome.”

With that bit of complaining out of the way, I wanted to be a bit more proactive. One of the major takeaways from Ruadhán O’Donoghue’s incredible blog on the state of webviews and user-agents is that unlike Facebook and Instagram, Twitter does not identity itself within its Webview’s User-Agent. For the sake of falling back, this makes the Twitter browser look like Safari or Chrome and requires the developer resort to feature detections (or failings) in order to realize their project is being served from a Webview. Take a look at these User-Agents.

Facebook for iOS

Mozilla/5.0 (iPhone; CPU iPhone OS 8_2 like Mac OS X) AppleWebKit/600.1.4 (KHTML, like Gecko) Mobile/12D508 [FBAN/FBIOS;FBAV/27.0.0.10.12;FBBV/8291884;FBDV/iPhone7,1;FBMD/iPhone;FBSN/iPhone OS;FBSV/8.2;FBSS/3; FBCR/vodafoneIE;FBID/phone;FBLC/en_US;FBOP/5]

Facebook identifies itself with several “FB” strings.

Instagram for iOS

Mozilla/5.0 (iPhone; CPU iPhone OS 12_2 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Mobile/15E148 Instagram 93.0.0.14.101 (iPhone10,4; iOS 12_2; en_US; en-US; scale=2.00; gamut=normal; 750x1334; 153868846)

Instagram identifies itself with “Instagram.” Very nice.

Twitter for iOS

Mozilla/5.0 (iPhone; CPU iPhone OS 12_2 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/12.1 Mobile/15E148 Safari/604.1

Looks like Safari to me! 🤦‍♂

Being able to identify the serving application from these user agents is the easiest way to provide a quick fallback to your users and packages like detect-inapp have been built around this exact strategy. If I knew the Webview didn’t support WebRTC, I would rather not wait until the technology failed to let my user know they might be in an unsupported browser and as I learned on Behemoth providing fallbacks can be very tricky. User-agent identification is easy and it’s quick. I can immediately let my user know that the experience runs best when opened directly in their device’s core browser. Here’s a possible fallback message:

This website does not work in Twitter. Please visit directly in your Safari browser.

What do we want?

Twitter, please identify yourself within the User-Agent of your Webview. An adjustment for iOS could look like this.

Mozilla/5.0 (iPhone; CPU iPhone OS 12_2 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/12.1 Mobile/15E148 Twitter

Here’s some articles on how to do that in iOS and Android. This will allow developers to provide better fallbacks for their web apps and more importantly, shut me up for a bit. Thank you!

If you’re passionate about this subject, please share this blog.