The things I hate (and you should know) about Apple Universal Links

Originally posted on Medium:

Hello! For those reading from me for the first time, my name is Austin and I work on product and sales things at Branch.

In the short time I’ve been in mobile, I’ve worked with over 1,000 different apps to setup deeplinking — this ranges the gamut from some apps you’ve probably never heard of to some of your favorites like Airbnb, Jet, Instacart and more.

One thing that always comes up with the partners I advise is Universal Links and most notably the lack of understanding around Universal Links. Given that they are becoming an integral part of the mobile ecosystem, I thought a deep dive was in order.

Explaining Universal Links

For the purposes of explanation, let’s talk about Universal Links from the perspective of the app Imgur — one of my favorites.

Generically, a Universal Link is any link that, when tapped, takes the user directly to the app. It does this by retrieving the Apple App Site Association (AASA) file from the domain of the link when you download Imgur.

Try it out. Just visit the domain, follow by apple-app-site-association:

  1. AASA:
  2. Imgur Subdomain — (Reserved for and CNAME’ing to Branch):

This AASA file contains a type of map of where to send the user when they tap the link in the future.

You can have Universal Links on any domain — it’s just a file hosted on a domain (ex: accompanied by a small change inside the Entitlements/Associated Domains file inside the iOS app. For example, Imgur has Universal Links enabled on

Third parties, like Branch, can also have Universal Links on their partners behalf, as showcased above.

For example, Branch hosts an AASA for Imgur on the Imgur subdomain (, which CNAMEs to Branch). When these links get tapped by a user on iOS 9+ who has the app installed, it will automatically open the app. Branch goes two steps further:

  1. It deeplinks the user to the right spot.
  2. It gives the vendor click and open attribution data.

Herein lies an important point, Apple doesn’t provide attribution on Universal Links. So, if you thought it was an awesome idea to turn on Universal Links on your home domain (,, etc.) — think again…you’re kissing your sweet attribution data goodbye.

The Biggest Issues with Universal Links

Beyond the obvious lack of attribution, Apple, in their brilliance, also designed some great ways to frustrate users with Universal Links.

Specifically, you can actively choose to default to the app experience or to the website experience when you click a Universal Link— this is called “setting your entitlement.” By default when a user taps a link, and has the app, it will take them to the app. But in the top corners, there will be two options:

< “Back to Safari” and “” >.

Image for post
The one on the left, Back to Safari, takes you back to Safari and doesn’t change the User’s entitlement preference. The button on the right, “” > changes your entitlement and sets the phone’s preference to go to the website.

If a user hits this button, then until they “reset” their entitlement, they will prefer to go to the website rather than the app. This means if they tap a Universal Link in the future, they will go to the App Store and have to hit open.

PUNCHLINE: Resetting entitlement = User always has to go to the app store and hit “Open.”

More importantly, if Universal Links aren’t setup properly on Branch or other 3rd parties, this is the behavior you will see.

Another issue is that Universal Links don’t work if they are wrapped in any other link. Apple designed these links to have “User Intent” meaning the user has to click the link itself. There cannot be any other click tracking, rerouting or redirecting wrapped around the Branch link.

This is actually the crux of the reason why email marketing is broken on mobile. I could spend another 5 pages talking about this in detail, but I’ll simplify — because of the inability to wrap Universal Links, most email and mobile marketing teams are missing out on thousands of dollars of additional revenue.

PUNCHLINE: Don’t wrap Universal Links in any additional type of click or attribution tracking links.

There’s only one way for the user to reset this behavior — the user has to do it. There’s nothing you, as an app can do for your customer: The user must tap and long press a link and choose actively to “Open in the App.”

Here’s what that looks like for Postmates from an SMS:

Image for post
If a user clicks “Open in Postmates” it will take the user to the app. If they tap “Open in Safari” it will take them to the website, and set the phone’s entitlement to prefer going to the website.

The Phantom Banner

One of the things I hate the most about Universal Links is the injected “phantom banner.”

When an iOS device holds an AASA from a particular domain and visits that domain in Safari, Apple forces a banner at the top of the website to take the user to the app and therein “reset the entitlement” to prefer the app.

This can be extremely confusing to both the user and the app developer.

For the user, they have no idea why this banner is showing and that it’s about to reset their entitlement.

For the companies, it’s a giant WTF?! Lots of apps design and build their own app banners, even outside of the one Branch provides. More fundamentally, however, Apple is injecting a generic UX for all companies on their actual website without permission.

The worst part of all this, is that this banner provides NO attribution. That means if you setup Universal Links on your main domain, you’ll literally have no idea how many people are clicking on the banner.

Image for post
You can imagine that having a floating forced banner makes it hard to design web to app strategy. Thanks Apple…

PUNCHLINE: If you enable Universal Links on your domain, Apple will force this generic app banner on your site for users who have the app. It doesn’t provide attribution, isn’t customizable, and there is nothing you can do about it.

Let me repeat: There is NOTHING you can do about the phantom banner if you enable Universal Links on your main domain. Well, you could use Branch links through a tool like Journeys or our Web SDK and choose instead to forgo using Universal Links on your main domain.


Okay… so, now that we understand the problem(s), let’s talk solutions.

1.) No Link Wrapping or Redirection: Get rid of any tracking around your emails or website buttons and rely on Branch or another supported 3rd party for your Universal Links instead.

You must make it so the link is clickable in the button. I would advise deliberately setting the <a href=”universal link”>. Remove any server side rendering where you change the button behavior based on different things.

If you’re thinking about using Universal Links in emails, I highly advise you check out integrating your Branch instance directly with your CMS provider.

Image for post

In this case, with Imgur, there is a floating button which is a Branch link and a Universal Link. Since the user can’t tap and long press, as demonstrated above, they will always be forced to go to the App Store if they ever set their entitlements to prefer the Website.

Image for post

2.) Educate your support team so that when users write in complaining you can tell them about Apple’s design and show them how to fix it by long pressing and clicking “open in the app.”

2.) Triggering URI’s is not the solution: It seems that a lot of apps still try to trigger their URI from the browser. This works okay for Android and for older versions of iOS, but with the advent of iOS 10, this is quickly going to fade from existence. If you want to see a real life example, check out Quora on iOS Safari.

They are trigging the URI Quora:// and then redirecting. This is outdated (+1 year old) and it causes all sorts of problems. On iOS 9 Safari this hits you with a massive error. On Android with specific browsers it breaks.

Branch designed our system specifically to fix these types of edge cases :)

Image for post
Quora has old code on their website from the pre-Universal Links era. It works by setting a timer, launching, capturing the error before if it exists, then falling back to the App Store if it does. This doesn’t work in iOS 9+ because Safari transitioned to non-blocking Javascript.

4.) Phantom Banner Fixes: The best advice I have is to look at using Journeys or the Branch Web SDK to design or DIY on a custom web to app flow. Enable Universal Links with Branch (or to be fair, another attribution provider) and get your attribution and UX from them. Then, TURN OFF Universal Links on your main domain.


Universal Links are an interesting attempt to make the mobile UX better on iOS. They fail in their complexity, difficulty to setup and test, and their seemingly “random” quirks which confuse and frustrate even the most technical product managers.

More problematic is the fact that consumers often associate Universal Link behaviors with the apps they are using, rather than the OS.

App developers and product managers, not Apple, get the blame for a crappy user and confusing experience. This sucks, bothers the hell out of me, and is wrong.

Products should be built with simplicity and accountability in mind and Universal Links utterly fail on these front.

Tim Cook — if you read this, let me know! I and the many app developers Branch represent have some great thoughts on Universal Links and believe we can help you fix this uneven aspect of the iOS ecosystem. :)