7 Universal Link Challenges on iOS 10.3 | AppsFlyer
6 Min. Read

7 Universal Linking Challenges on iOS 10.3 and the OneLink Solution

Avatar Gil Meroz Aug 07, 2017

Beginning with iOS 9, Apple presented a new method for deep linking called Universal Links. Universal Links solved a few problematic user-flows and improved the security and URL uniqueness of deep links while enhancing the user experience. However, Universal Links also introduced new limitations, creating challenges for marketers and developers. 

iOS Deep Linking before iOS 9
Before Universal Links, deep linking utilized URI schemas. Fallbacks to the App Store or a webpage if the app was not installed was accomplished by opening the Safari browser and trying to open the app. If nothing happened after a short delay, the user was redirected to desired the App Store or webpage.

Introducing Universal Links
Universal links are HTTPS links recognized by the iOS system as deep links. These deep links open an app or fallback to open a webpage when the app is not installed.

When a Universal Link is tapped, iOS will identify if the app is installed. If the app is installed, it will open the app directly. This provides the user with an easy way to navigate back to the previous app via a button that appears on the top right of the screen.

By having the app point to a website domain, and having the website domain point to the app, Apple introduced a unique handshake between the deep link URL and the app. Before universal links, developers could register their app to any deep link scheme (e.g.ebay://). By doing so, their app could open links also used by other apps. Without a two-way handshake, several apps could use the same deep link. Because universal links are tied to a unique website and require the developer to place a file on the website listing the apps which are permitted to be opened by that domain’s link, universal links offer a more secure solution.

Universal Link Limitations

  1. Complex Implementation and QA

    Universal Links require that several parameters are properly configured. This multi-step flow introduces several places where the flow can break.

    Universal Link Setup Process

    1. The app developer enables Universal Links in the app provisioning file on Apple’s Developer Center.
    2. The app updates this provisioning in the app.
    3. The app should point to a website domain.
    4. The website should have a unique file that specifies that the stated app can deep link using their domain.

    Developers often miss or misconfigure one of these components. Furthermore, because the website and mobile apps are often managed by different teams, troubleshooting configurations can be a slow process.

  2. Falling Back to the App Store When The App is Not Installed

    Often, marketers want to redirect users who do have their app installed to the App Store.

    Since iOS 9, there has not been a way to programmatically check if an app is installed on the device. Whereas in the past this was done by attempting to open URI schemes on Safari, Safari now prevents other actions if the URI schema does not respond.

    To address this need, we developed a unique solution that redirects to the App Store, even on iOS 10.1 and 10.2. We have setup our server as the fallback website, and have our server redirect the users to the App Store when the desired app fails to launch.

    However, on iOS 10.3 Apple added a new limitation – redirecting to another app (including the App Store) now requires a confirmation dialog.


    The introduction of this dialog and the need for an additional click negatively affected both the user experience and install conversion rates. To compound this challenge, users in a native app’s internal browser who click the cancel button are left a black page. Our OneLink platform loads a fallback webpage on the browser to avoid this scenario.

  3. The Navigation Arrow that Breaks Deep Linking

    Shortly after Apple released Universal Links, they added a navigation arrow at the top right of the screen. This new arrow allows users to leave the app and navigate to the attached website. While this delivers a strong user experience, there are times that app developers would like to avoid opening a website, such as when using the website fallback to redirect users to the App Store.

    This new arrow cannot be hidden programmatically. To take this a step further, once the user taps the arrow, iOS will “remember” the website as the default route for that Universal Link! From that moment on, any tap on that specific link will redirect to the fallback website instead of to the app. This experience gets even worse when the website redirects automatically to the App Store.

    This scenario often confuses both developers and marketers, leaving the impression that their deep linking stopped working for their app – when in reality, their test devices are simply recognizing the deep link and remembering their preferences.

    When testing a deep link, remember to reset your preferences for each link by long tapping on the link, and selecting Open in My App from the options.

  4. HTTP Redirects and Link Shortening Break Universal Links

    By definition, Universal Links do not work when they are redirected from another URL. This limit is meant as a security measure, preventing a website from opening apps without explicit user intention. Redirections will only open an app from a Universal Link only if the user tapped a URL from the same domain as the redirected URL.

    App developers and marketers are accustomed to using HTTP redirection to manage their links. HTTP redirection changes the routing logic on the server side. HTTP redirects are commonly used to create marketing and social media-friendly short links. In most cases, Universal Links will break when run through shortening services like bit.ly, or through apps (like Twitter) that automatically apply their own link shortening, as the user has not previously tapped a URL from the same domain as the redirected URL.

  5. Universal Links Don’t Load in When Pasted Into Browsers

    Universal Links require a user to actually tap on a link. This can not be hacked programmatically.

    This creates confusion for developers and marketers trying to test their own links. Pasting a link into the browser address bar will not load the Universal Links, often leading the developer/marketers to think there is a technical error.

  6. Opening Universal Links for Other Apps

    Many apps open an internal browser when an HTTP link is clicked. Most of the time, developers and product managers utilize this functionality to keep the user engaged with their app – going “back” will open the app rather than the home screen or previous tab.

    In this scenario, because there is no tap on a link on the domain in the webview, loading the URL will open the website as if the app is not installed. This is true for whether both for pages loaded using SFSafariViewController or a webview.

    Apple implemented this measure because it is possible to change and manipulate the browser’s address by using Javascript code running within the browser. Changing a URL is a legitimate action on the web. On mobile however, automatically opening other apps is a bit more intrusive and prone to misuse. Apple decided to limit this functionality, ensuring that the user intended to load the app in question.

    This limitation is also the reason why some social and email apps do not support proper deep linking. There are two potential workarounds to accommodate these scenarios:

    • Use HTTP redirect to send the URLs to the App Store. When a user who already has the app lands on App Store page, the store will show the “Open” button. Because this solution involves a second click, conversion rates may be a bit lower.
    • Have the link point to a landing page that has a Universal Link on it. When the user clicks the Universal Link within the browser, it will load the app. Once again, conversion rates may be a bit lower because of the second click.

    OneLink supports both of these options out of the box.

  7. Social Apps

    As we explored above, Universal Links break on most leading social apps. In most cases, the two workarounds we mentioned above will work.

    Here are the main issues our team has encountered in today’s popular social apps:

    • Facebook
      It is not possible to deep link from posts to the Facebook feed. Clicking on a Universal Link inside the news feed will open the link in Facebook’s internal browser (the native Safari view controller) which will try to open the link as a web page.
    • Twitter
      Twitter automatically generates their own short links for links inside tweets. Once a link is changed, it will not be able to deep link. In addition, because Twitter opens links in Safari Reader, deep linking to an app is not possible. The same is true for links from Twitter profiles.
    • WeChat
      WeChat uses their own built-in webview. WeChat’s integrated webview does not support Universal Links. The ideal solution is to redirect users to the App Store.
    • Instagram
      In instagram it is possible to set a URL in the user profile description. This is a tactic often used by influencers to direct users to their websites. Unfortunately, it is not possible to deep link from Instagram profiles into apps, as these links will open an internal browser with the limitations mentioned above.

Over the last few years, we have helped thousands of the world’s largest developers and marketers recognize the full potential of deep linking with OneLink™, improving both their user experience and conversion rates. While these are the seven most common issues developers and marketers face when implementing universal links on iOS, we welcome your questions, suggestions and feedback.

To learn more about OneLink’s complimentary deep linking capabilities, schedule your AppsFlyer demo today. We look forward to speaking with you!