Deep LinkingIndustry InsightsTechnical

Apple iOS 10 Update Deep Linking Review

By June 24, 2016 9 Comments

With every new operating system version on iOS or Android, comes substantial changes to even the most basic functionality of the operating system. As developers trying to build a business in mobile, we have to pay attention to these details, lest our users be delivered broken experiences.

At Branch, we think about mobile linking for 18 hours a day and dream about it for the last 6. As soon as iOS 10 was released, we had multiple phones loaded with the beta to test any required updates. We thought we’d share some of our learnings while playing around with the new OS betas.

What’s New On iOS10

If you’re worried about having to change your linking mechanisms to support iOS 10, you can put your mind at ease. There’s almost no significant behavior change from iOS 9.3 to iOS 10. The same deep linking mechanism you’re using for iOS 9.3 will work for iOS 10.

The major change for linking is that your shared links now appear like rich media when placed in Messages. See an example below where I shared a Branch link to a monster I created in our test app, Branch Monster Factory.messages ios 10

Messages now crawls the link to read the Open Graph metadata in order to show rich media inside the message. For those of you who want to filter or track this robot, the iOS 10 Messages User Agent string is below:

In order to prepare, make sure that your Open Graph tags are properly formatted and reflect the content you’re sharing.

Notable Deep Linking Behavior

The most significant complication in mobile linking is handling users with the app installed. This is referred to as deep linking. We’ve taken inventory of some of the most typical mechanisms for opening up the app and verified functionality on iOS 10.

iFrame Source Method Still Unsupported

The most substantial change in iOS 9.3 was that the iFrame source method of deep linking was blocked. We’ve confirmed that this mechanism is still blocked in iOS 10.

To see how it worked, you can see an example code snippet below:

The gist of the mechanism was that it would try to open up the app, but safely fallback to the App Store when the app was not installed. The redirect could be handled by setting the source URL of an iFrame to a deep link, to trigger Safari to open the app. You’d need redirect to the App Store soon thereafter because when the app wasn’t installed, an error message would show to the user.

This was the only way to safely deep link for over 6 years prior, and was used universally. For those of us who grew up deep linking with this Javascript snippet on iOS, it’s time to say good bye.

Window Location Not Usable With URI Schemes

You probably thought to yourself: “if iFrame source doesn’t work, why not use window.location?”. Good thinking. Unfortunately, this mechanism is also unusable on iOS 10. Here’s an example code snippet:

This mechanism actually works in the case where the app is installed. It presents the user with a modal that asks them to ‘Open App’. However, if you try the same code snippet with a user who does not have the app, they are presented with the error message like so:

open app ios 10It’s an awful user experience to deliver to users who don’t have your app installed, and we recommend you avoid this mechanism like the plague.

3XX Series Redirects To App Store Don’t Show Modal

Now, let’s say you want to send a user to the App Store when they express interest in downloading your app. Apple introduced the awful modal seen below in iOS 9, where a user is presented with a choice.

open app store ios 10A user has already expressed intent to download the app, and then Apple has to slap with them with another prompt to check if they really, really want it. It’s annoying.

Fortunately, you have two options to avoid this modal. You can either use a 3XX series redirect to the App Store URL or link directly to the App Store. Either one will skip the modal entirely, taking the user smoothly to the App Store page. Just don’t use Javascript to perform this redirect.

No Change in Universal Link Behavior

Introduced in iOS 9, Universal Links appear to exhibit the exact same behavior on iOS 10 and remain the preferred (and only functional) way to deep link. All Branch links behave as Universal Links on your behalf, and you can configure your own domain to do the same. When a Universal Link is clicked (and the environment supports it), it will immediately open up the app when installed without opening the browser. It’s a beautiful experience.

Unfortunately, iOS 10 doesn’t relieve  a multitude of issues with Universal Links that prevent you from using them everywhere. Facebook, Twitter, Gmail and all other third party apps still don’t support them. Additionally, when a user pastes in a web link to Safari, they are ignored and the website is loaded. We’ve captured all of the issues in a documentation page supporting Universal Links.

If you don’t want to worry about these types of details, we at Branch would love to help you with all of your linking infrastructure.  We’ll help you cover these edge cases, and keep your links working through any and all updates.

  • bdennyw

    Is this true now that the app review guidelines prohibit hiding the SafariViewController?

  • Troy Sherman

    @disqus_bl1M5LqGXp:disqus any idea if iOS 10 broke conventional deep linking? i.e redirecting to ://appName/token/129313 from safarI?

    Thanks

    • Alex Austin

      Hey @troysherman:disqus – Thanks for the question! According to all of our tests, URI schemes still work from Safari.. however! You can’t use them in practical situations. The reason being is that when the app is not installed, Safari shows a *blocking* Javascript “Page not found” error that the user must dismiss. You can’t redirect away from this error unfortunately. Because of how poor a user experience this edge case is (all of your non-app users), Branch prefers to depend on Universal Links in Safari. You can see a bit more about how Branch selectively chooses the deep link scheme depending on the browser in our docs section here: https://dev.branch.io/getting-started/link-behavior/guide/#behavior-when-the-app-is-installed

      • Troy Sherman

        @disqus_W4Xl8rZCYZ:disqus
        But in situations where the app is installed, it seems that safari isn’t able to process any deep links with a suffix in iOS10. For example:

        appName://id=123 opens in iOS9, but in iOS10 safari displays that “the url can’t be shown” for the exact same URL.
        They will both work however for the URL scheme alone (appName://)

        You can even test this on your devices/simulator to see. Perhaps the change is in safari?

        • Alex Austin

          Ah interesting find! I just tested a few ways and it seems to reject typed-in URI schemes with a deep link host & path, but you can still trigger them in JS and click them on page. You just can’t type it in for some reason.

          • Troy Sherman

            Thanks Alex, this appears to be a change in Safari on iOS 10! Worked my way around it, but it was good to figure out before I released a version that relied on this.

            Appreciate the time and help.

  • elemelemele

    I think i found a bug with iframe, deep linking and Safari.
    In my iframe automatically opening native app like this: window.location = “urischeme://open”; doesn’t work, also if i try to exit iframe with top:
    window.top.location = “urischeme://open” – nothing happened

    only physically click on button work with attribute target=”_top”: Button

    also document.getElementById(‘button’).click() doesn’t work.

    Any ideas how to open automatically app from iframe ?

    Thanks

    • Alex Austin

      iFrames handling in Safari has continued to have significant security restrictions added to ensure you cannot do this. You only have 1 option to open up the app from within an iFrame: physically click a Universal Link. The other option we’ve found works is a 307 to the App Store will work to get the user a bit closer to your app, but not open it. Hope this helps!