Apple App Site Association (AASA) and Universal Links Issue

Question

Created 2d

Replies 1

Boosts 0

Participants 2

Hi Everyone

We are seeking inputs regarding an issue we are observing with Apple App Site Association (AASA) and Universal Links in our iOS application.

In our iOS Mobile App, we have a LogIn button which when clicked , opens a webv view to open a login page using WebView. The login flow follows the OAuth mechanism to get the token after successful login.

But despite having a correctly configured AASA file and associated domains setup, our application does not consistently handle Universal Links and we simply end up getting a blank page.So, after successful login the control never gets passed back the iOS Mobile app and flow gets stuck on the browser only that just displays a blank page. Earlier the same OAuth flow was working fine when we were using the 'com.test.app://oauth2redirect' comnvention.

Based on our investigation, we suspect this behavior may be related to the use of in-app browsers or embedded webviews, rather than an issue with our app or server-side configuration.

From our research and observations, it appears that this may be a known iOS behavior and platform limitation, where Universal Links do not automatically work within third-party in-app browsers or webviews (for example, those embedded in apps such as social media or other container applications). Looks like the Universal Links are primarily designed to work when links are opened from system-level contexts such as Safari, Mail, Messages, or Notes, under specific conditions.

Given this, we wanted to confirm with you:

If you have developed a mobile app earlier that uses the (AASA) and Universal Links in iOS application.
Join us with a quick call and we can walkthrough what we have done and see if there is anything missing.

Thanks Rahul

Boost

Answer 1

DTS Engineer OP

Apple

10h

Thanks for the post.

Yes, absolutely. Your understanding of the situation is largely correct, and this is a very common point of confusion and frustration when working with Universal Links, WebViews, and OAuth flows in iOS.

I have indeed developed mobile apps that extensively use Apple App Site Association (AASA) and Universal Links in iOS, and I've encountered this exact scenario many times with browsers that are not safari. I always recommend to test using the iOS Notes app to see if the app its open correctly.

Universal Links are primarily designed to work when a link is opened from a system-level context (Safari, Mail, Messages, Notes, or any app that explicitly asks the OS to open a URL, like UIApplication.shared.open(url)). When a WKWebView (or UIWebView for older apps) attempts to navigate to a Universal Link URL, the WebView itself is acting as a miniature browser. It does not automatically hand off the URL to the iOS operating system for Universal Link resolution. Instead, it tries to load that URL internally? You do not have the same result using the Notes app?

Given this limitation, the modern and recommended approach for OAuth flows within iOS apps is to use specific system-provided browser components that do correctly handle redirects back to your app (whether via Universal Links or custom URL schemes).

Can you post a link to your AASA file? To check specifically the applinks section for that path?

Resources: TN3155: Debugging universal links | Apple Developer Documentation

Albert Pascual   Worldwide Developer Relations.

0