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/. If I add the following to the list of associated domains:
applinks:*.mydomain.com-> Does not work
applinks:news.mydomain.com-> works fine
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-> Does not work
applinks:username.mydomain.com-> works fine
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.
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 naked 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.
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.