Universal link and wildcard

Hi, I have a similar issue.

In an iOS app I am working on I have setup Universal Links. The app hosts multiple domains. Some domains I have set up with a wildcard. These domains do not seem to work. For example, I want to link to

https://news.mydomain.com/

applinks:*.mydomain.com

applinks:news.mydomain.com

So I believe I did set up all correct, the apple-app-site-association file is setup fine. I can even see in both cases (using Charles Proxy) the apple-app-site-association file got retrieved ok.

In the case of the wildcard, the link only opens in Safari.

When I configure the domain without a wildcard, the App opens.

Am I missing something here? I am running iOS 9.3.2 on the device and I am running Xcode 7.3.1 which are today the latest versions.

I have posted this question also on stackoverflow: http://stackoverflow.com/questions/37301392/ios-universal-links-with-wildcards-not-working

We are seeing the same problem. Not realy looking foward to be adding a few hundered domains to the list 😝

Bocaxica, I answered on your question in your stack post. In my way problem was iOS 9.3.1. After updating to 9.3.2 everything works fine. May be you still have 9.3.1 ?

Bertgoethals, it is not a problem to add in list. But release new version for every subdomain, that is a problem ...

Hi Marriage, thank you. I am sure I am on iOS 9.3.2. I am still not sure why it won't work in my case.

I'm having the same issue on iOS 9.3.2.

It's also not working for me with iOS 9.3.2. Is it may be important to put the apple-app-site-association file into subdomain.mysite.com/.well-known/ instead of the root?

I am having the same issue on iOS 9.3.2, 9.3.3, 9.3.4 and iOS 10 beta 6 in that:

applinks:*.mydomain.com

applinks:username.mydomain.com

I've tried having the apple-app-site-association file at both the root directory and in the /.well-known folder off the root. I have reviewed the solution here but that won't work for me seeing how our app is configured to work with the username being a part of the url.

The very peculiar thing is that the wildcard works fine when I run the app configured for our development server. Once I stop pointing to that server, and with identical apple-app-site-association files.

I was finally able to figure out a solution for this problem. It turns out that you need to have the association file also be served from the domain without the wildcard. So, using my example above, the association file also needs to be available from https://mydomain.com as well as https://*.mydomain.com.

Thank you!

You are right, it appears that both the wildcard expression and the domain on top of that is required. In other words, the root of the wildcard must also serve the "apple-app-site-association" file, else it won't work for subdomains not explicitly added as "applinks:subdomain.domain.com" in Xcode.

I guess it makes sense, else iOS would have to fetch the "apple-app-site-association" file each time it would be presented with a new subdomain.

It is, however, a little unfortunate in the presence of the following scenario:

- The main website is hosted at "www.domain.com", with 301 to "www.domain.com" on ***** domain (i.e. "domain.com")

- Now, let's say that we want to use the wildcard "*.domain.com" to access the following servers: app-server-1.domain.com, app-server-2.domain.com...

- For such a setup, we don't have any choice; we need to enter each subdomain explicitly in Xcode, because serving the "apple-app-site-association" file over "domain.com" will not be possible, since the latter redirects to www.domain.com (Universal Links do not allow redirects).

- The workaround I found is simple though (if you are willing to make a little compromise): simply create a main subdomain where the "apple-app-site-association" file is hosted, and then create sub-subdomains for that domain. Here's an example:

- - app.domain.com (this is the main subdomain; it hosts apple-app-site-association file)

- - server1.app.domain.com (this also hosts the apple-app-site-association file)

- - server2.app.domain.com (...)

- - server3.app.domain.com (...)

- That way, in Xcode, you can go on and only explicitly declare "applinks:*.app.domain.com" and it will work. Note, however, that you must also declare "applinks:app.domain.com" if you plan on using it as a real server as well.

I hope this helps. 🙂

Frank

Hi. I have a different problem, where my second-level subdomain doesn't open in the native app.

second.level.domain.com (It's a second level subdomain). The apple-app-site-association file is hosted right on: second.level.domain.com)

Then i also have:

another.domain.com . (first level subdomain). This one works fine, with the identical apple-app-site-association file that's hosted right on: another.domain.com

The two apple-app-site-association files are identical between the two, but the single-level works, and the second-level does NOT work.

I'm not able to get the second level subdomain opening natively in the app. It opens in safari every time.

Would you have any suggestions?

My capabilities contain:

another.domain.com . (works)

second.level.domain.com . (doesn't work)

webcredentials: ... and other entries as well

Also note: The Bundle ID is the same between the two, and the apple-app-site-association files are identical as well. (Our UAT environment has these two domain setups - one on a first-level subdomain, one on a second-level subdomain.)

SSL Certs are valid and are not the problem. There are no redirects taking place. Provisioning or bundle IDs are not the problem because they're identical between the working single-level subdomain and the non working second-level subdomain.

For me it's also not an option to use a wildcard or host a webserver on: level.domain.com

I have a stack overflow question for this as well: https://stackoverflow.com/questions/58665606/ios-universal-link-with-a-second-level-subdomain-doesnt-deep-link-to-native-app

Found the problem: Instead of single quotes, the association file must use double quotes. (Single quotes aren't valid JSON). Had nothing to do with the second.level subdomain.

Hello,

In iOS 13.* or 12.* it's still not working ! I mean "

applinks:*.mydomain.com"

We have to update the application for each added subdomain !

Any solution ???

Be sure non of those subdomains return 404.

Ideally, of course, all of the links on your website are allowed to be opened in the app, regardless of subdomains or www redirects, and then you use the content of apple-app-site-association to limit which ones actually will open in the app.

Let's assume you want everything on your domain (e.g. coursicle.com) to be eligible to be opened as a deep link. Then you'll want to configure your entitlements in Xcode as applinks:*.coursicle.com. No problem because you own coursicle.com, right? But it's very likely that you're redirecting coursicle.com to www.coursicle.com and Apple's going to check coursicle.com/.well-known/apple-app-site-association and/or coursicle.com/apple-app-site-association, which is going to redirect to the www equivalent. Because of Apple's "no redirects" stipulation, your deep links will fail.

@focorner's answer points this out and offers a workaround. We were considering this solution, by making it so that on iPhones any link on our site that we wanted deep linked would have a subdomain link added to it. Moreover, our entitlements would contain applinks:link.coursicle.com and link.coursicle.com/apple-app-site-association would return our JSON without any redirects. This meant for desktop users we'd display www.coursicle.com/unc/?search=math but for iPhone user agents we'd show link.coursicle.com/unc/?search=math. If an iPhone user tapped on a link.coursicle.com/unc/?search=math link and they had the app, it'd open directly in the app. If they didn't, we'd have a redirect rule that takes all link.coursicle.com links and redirects them to www.coursicle.com, allowing our application code to handle this user now that we know they don't have the app.

This solution actually killed two birds with one stone. If the user is on a coursicle.com link in Safari, in order to get a deep link to actually open in the app we need to provide a different subdomain per Apple's requirements, otherwise it's assumed that the user wants to stay in Safari (I this this is pretty silly and I do not understand the reasoning). So because all of the desired deep links were link.coursicle.com and because we could easily host our JSON at link.coursicle.com/apple-app-site-association without any redirects, it works.

There's just one problem: you don't have control over how others link to your site. What happens if someone on desktop sends the link www.coursicle.com/unc/?search=math to someone on an iPhone who has the app installed? Well applinks:coursicle.com isn't in our entitlements so the link would open in Safari.

To get the ideal solution, despite having a www redirect, all you have to do is prevent the www redirection for the specific files you know Apple is going to request. In Apache, it can be done via the following:

# force www. because the local storage/cookies does discriminate
# unless it's the apple-app-site-association which won't tolerate a redirect so we 
# have to have it load the appropriate file directly
RewriteCond %{HTTP_HOST} !^www\.
RewriteCond %{REQUEST_URI} !^/apple-app-site-association$ [NC]
RewriteCond %{REQUEST_URI} !^/.well-known/apple-app-site-association$ [NC]
RewriteRule ^(.*)$ https://www.%{HTTP_HOST}$1 [R=301,L]

This might cause some of your subsequent rules to behave a little funny because you expect a www redirect, so you can always add the following to make it so that if the URL does exactly match apple-app-site-association, you have Apache serve it directly from the file system:

# Manually specify where to find the apple-app-site-association, may not be necessary depending on your configuration
Alias "/apple-app-site-association" "/var/www/coursicle.com/shared/link/nativeDeepLink/apple-app-site-association.php"
Alias "/.well-known/apple-app-site-association" "/var/www/coursicle.com/shared/link/nativeDeepLink/apple-app-site-association.php"