This year, Apple announced that starting with iOS 11, all instances of Safari will no longer share the same cookie space. This means that cookies set in the main Safari browser app are no longer readable from an instance of Safari within another app that could be created within a native app via the SFSafariViewController. This change was a sharp reversal from iOS 9 and 10, where the main Safari app shared the same cookies with the native app instance of Safari via the view controller. Here’s a quick diagram, modified from Apple’s slides, that can help visualize this change:
On the surface, this seems like a tiny change not worth anyone’s time, but this change will have a very lasting impact on the future of mobile web. In fact, this fragmentation will destroy mobile web.
The original shared cookie space was very powerful for a number of reasons. First off, it helped companies (like Branch) carry user context from the web through the App Store with 100% certainty, as we introduced in 2015. If users were logged into a mobile website in Safari and then went to install the native app, the native app could open an instance of Safari to read your session cookie and automatically log you in. The functionality created a beautifully seamless transition between the mobile web and the native app.
However, this is just one facet of solving fragmentation in mobile. Breaking the cookie space up across apps makes this much, much worse.
Why Mobile Web Sucks
When people think about the internet, the image most people have is a browser. A browser is the portal into the Internet. It exposes a bunch of important functionalities to make the web appear more seamless—most relevantly, the ability to set cookies, which maintains context across browsing sessions. When Internet users type in “facebook.com”, they expect to immediately see their news feeds. Without cookies, they will be asked to sign in with their credentials every time they load the page.
Mobile web sucks because there are at least five different browsers on a user’s phone. Most popular mobile apps want to make sure you stay engaged with the app and don’t drift off, so they’ve built in-app browsers. For example, on iOS, Facebook, Twitter, Gmail, and Pinterest have all built browsers to show web content without exiting the app.
Before iOS 9, each of these unique browsers had their own unique cookie spaces. This meant that if a user logged into an Amazon account in the main Safari app, then clicked on an Amazon link in Gmail, that user would need to log in again. It was an extremely frustrating user experience, and I believe, one of the biggest contributors to the rise of the native app, where your session is maintained more or less forever.
The Safari View Controller, with its shared cookie space introduced in iOS 9, allowed users to enjoy unified browsing experiences no matter the browser(s). Unfortunately, it took many platforms (Gmail and Twitter) a very long time to adopt it, so the benefits took a while to start to be seen. Despite this, trends showed the ecosystem moving to resolve the terrible fragmentation plaguing mobile web.
Now, with iOS 11, the unification of these browsing experiences is dashed. Users should expect to be asked to log in every step of the way, across the many different browsers on their phone or just download the native app and forget the web forever. It’s a bad sign for the future of the web.
What Does This Change Mean
Practically, this means that your most engaged mobile web users should expect to get a much worse experience on iOS 11 than on iOS 10 and earlier. They’ll be prompted to log in across each browser every time they show up, making it difficult to engage with your brand. Specifically, as an example, any iOS 11 users that click on a link in an email via the Gmail app will be sent to a not-logged-in browser experience, increasing the drop off rate dramatically. As such, you can expect mobile web conversion rates to drop across iOS.
It also means that you’ll be unable to pass data through the App Store to a newly installed app instance with 100% certainty, since the Safari View Controller cookie space is now distinct from the core Safari app or any other apps from which the user might originate. If you had plans to build deferred deep linking to help personalize the onboarding experience, you’re out of luck, as it’s no longer possible without building some sort of fingerprinting system.
For those of you that care dearly for accurate attribution—which is likely most of you—expect to see your total number of unique new users to jump up dramatically. This will happen because a single person will be counted as a unique user depending on where they engage with your brand. The user visiting your site from Gmail will look totally different than that same user in Safari, which will look totally different than when that user visits your site from Facebook. Not the mention attribution from web to app being impossible from a deterministic perspective, due to the in-app Safari View Controller restriction.
This also means that counts of unique mobile web visitors should definitely be taken with a grain of salt. Maybe you’ve already adopted this practice, but it’ll be hard to trust decisions made entirely on analytics data from iOS 11 users. For app install attribution, you’ll be left to depend on fingerprinting methodologies, which are historically inaccurate and unreliable.
Strategies To Deal With It
Overall, no matter what strategy you pursue to deal with these inconsistencies due to fragmentation, you must realize that there’s no silver bullet. At best, you can hope to reduce duplication and repetitive asks just a fraction of the time. We at Branch recommend that you consider your native app a sanctuary from the tyranny of fragmentation, and that you continue to upsell it at every opportunity.
Branch’s Journeys web to app optimization platform can help substantially in driving users to your sanctuary, as we’ve designed the product to stitch together the various fragments of the mobile ecosystem, allowing you to build continuous user experiences across browsers. You can design custom audiences around user properties like whether they have the app or not, how many custom events they’ve completed, and much more. The beauty of these audiences is that Branch stitches this user profile across all of the different fragments. A single person will be represented by many different cookies so that we know it’s the same person as they travel to your site across many different browsers.
Don’t worry about losing the 100% match rate passthrough functionality—Branch has you covered there, too. Because we unify this concept of the person across many identifiers, we have a large pool of these identifiers that allow us to pass data through with certainty. When our deep link routing handler is called back inside your native app, we return a boolean called match_guaranteed, which will tell you that we matched that user with 100% certainty. This gives you the confidence to do things like automatically login your users and other neat functionality.
Additionally, attribution needs to properly de-duplicate across these different browsers. You’re going to start investing in tools to help you unify this concept of a user so that your internal reports can report more accurately. Branch does this as well, to help provide much more accurate attribution. We represent users as many cookies and can unify the not-logged-in web visits across browser to yield more accuracy.
Fragmentation is the biggest challenge that mobile-focused companies face, and should be a key discussion point in every prioritization decision in the years ahead. Without it, you’ll be delivering terrible user experiences and misjudging your attribution. Luckily, Branch can help—get started today at branch.io, or request a Branch demo to meet with one of our mobile experts.