Sharing in the World of the in-app Web View

Alastair Coote
3 min readFeb 17, 2015

The mobile web is weird in a myriad of ways, but one of the weirdest things about it is that if you have a lot of social traffic, your users aren’t actually viewing your mobile web site in a browser. Well, not quite. On iOS (and sometimes Android) they are in a web view, housed inside the Facebook or Twitter apps. After looking at this chart from Flurry you could be forgiven for assuming that the web is entirely dead:

via Flurry: http://www.flurry.com/bid/109749/Apps-Solidify-Leadership-Six-Years-into-the-Mobile-Revolution

when in reality, people’s web usage is shifting from Safari to Facebook. (Unfortunately, only Facebook knows how much time is spent inside app views vs. web views, so we can’t draw any conclusions about the death of the web… yet.)

So what?

I’ve written before about the steps you can do to better serve users inside web views, but wanted to expand further on one point. These app web views are an island — they share no data or user information with each other, nor with Safari itself. That means that a user inside a Facebook web view is not logged into Twitter, and vice versa. It won’t surprise you to learn that many users give up on the idea of sharing your link when they are confronted with a login screen, so why not tailor their experience to only show relevant share buttons?

This is especially important as many of these apps will hook into the share buttons on your site and show the native interface, not the web version. Just compare Twitter to Tumblr:

User agent to the rescue

All web browsers send a “user agent” when they request a web site — it’s a small identifier indicating what software you are using. Most of these app web views have customised their user agent, allowing us to detect them. Let’s compare the user agent of normal, vanilla Safari:

Mozilla/5.0 (iPod touch; CPU iPhone OS 8_1 like Mac OS X) AppleWebKit/600.1.4 (KHTML, like Gecko) Version/8.0 Mobile/12B411 Safari/600.1.4

to that of Facebook:

Mozilla/5.0 (iPod touch; CPU iPhone OS 8_1 like Mac OS X) AppleWebKit/600.1.4 (KHTML, like Gecko) Mobile/12B411 [FBAN/FBIOS;FBAV/24.0.0.12.7;FBBV/6890242;FBDV/iPod5,1;FBMD/iPod touch;FBSN/iPhone OS;FBSV/8.1;FBSS/2; FBCR/;FBID/phone;FBLC/en_US;FBOP/5]

and Pinterest:

Mozilla/5.0 (iPod touch; CPU iPhone OS 8_1 like Mac OS X) AppleWebKit/600.1.4 (KHTML, like Gecko) Version/8.0 Mobile/12B411 [Pinterest/iOS]

In amongst all that insanity, you’ll see that both networks have added some custom text of their own that we can detect.

Even when they don’t

Some apps don’t alter their user agent — Twitter and Tumblr being two examples that immediately come to mind. But it’s not all bad news: all web views omit the “Safari/xxx.x.x” string at the end. If we combine that with referral data — another small piece of data indicating where the user came from — we can still get a likely match.

Put it all together

So, we can create a JS snippet that looks something like this:

and then use CSS classes on the <body> tag to change which share buttons we show.

In conclusion

Working inside web views like this is still extremely difficult, but there are small moments where you can use it to your advantage. So, do. That is, until Facebook kills us all.

--

--

Alastair Coote

Doing mobile news-y stuff at @nytimes. Previously of @gdnmobilelab.