1. Background description
1.1 What are Universal Links?
Support Universal Links talks about what Universal Links is, what to pay attention to, and how to configure it. To put it simply, it is
When you support Universal Links, iOS users can click a link to your website and be seamlessly redirected to your installed app
In plain English, users can directly invoke the corresponding app by clicking on a link. The purpose of providing such a function is to attract network users (commonly known as traffic drainage).
(Note that changes in the URL must be caused by user clicks! Using js to trigger it is invalid).
1.2 How to configure Universal Links
Simply put, configuring Universal Links involves two aspects: domain name server and app:
① The apple-app-site-association file (also known as AASA file) must be configured on the domain name server
After creating the apple-app-site-association file, upload it to the root directory or subdirectory of the HTTPS web server .well-known. The file needs to be accessible via HTTPS (without any redirects) at https:///apple-app-site-association or https:///.well-known/apple-app-site-association. Next, you need to handle universal links in your application
That is, after it is configured, there are three links that must be accessed successfully:
https://你的域名.com/apple-app-site-association
https://你的域名.com/.well-known/apple-app-site-association
https://app-site-association.cdn-apple.com/a/v1/你的域名.com
The last link is the Apple CDN link. It can be understood that as long as this address returns to normal as shown below, it means that there is no problem with the AASA file we configured.
② On the app, applinks must be configured in Associated Domains of Xcode
Both aspects must be configured before Universal Links can be used to invoke the app. After the configuration is OK, the app can be invoked directly through the configured domain name in DingTalk, WeChat, safari browser, scanner, etc.
2. Problem occurrence and debugging
Yesterday at 17:00, I found that Universal Links could not activate the app normally. Open those 3 links for debugging and find that only the first one can be accessed normally.
https://你的域名.com/apple-app-site-association
https://你的域名.com/.well-known/apple-app-site-association
https://app-site-association.cdn-apple.com/a/v1/你的域名.com
The third one shows Not Found
running in the shell:
curl -v https://app-site-association.cdn-apple.com/a/v1/你的域名.com
Details of the request can be seen:
< Apple-Failure-Details: {
"status":"405 Not Allowed"}
< Apple-Failure-Reason: SWCERR00101 Bad HTTP Response: 405 Method Not Allowed
3. Repair summary
-
This Universal Links has been accessible normally before, and the relevant configuration has not been changed when the ios app is released. Why did it fail?
-
The first two links can be accessed normally, that is, the configuration of apple-app-site-association is OK. The problem is on the last connection, Not Allowed. It may be that our server does not allow access to app-site-association.cdn-apple.com
-
Thinking that the server was under attack a few days ago, the operation and maintenance adjusted the security policy. Sometimes, security prompts can be displayed under our domain name. After confirming with the operation and maintenance, I learned that the operation and maintenance has banned all foreign IP access .
-
But after the operation and maintenance is liberalized, access to
https://app-site-association.cdn-apple.com/a/v1/你的域名.com
Still Not Found, nothing seems to have changed.
-
It just so happened that I got off work in a few minutes at that time, and I still had to get the daily cloud effect and daily report, so I didn't worry about that for now. After going to work today, I found that the link was accessible.
Recall that it may be a cache problem. When I configured the AASA file before, I learned that the AASA file is cached, or it is the cache of Apple CDN . After modifying the AASA file, accessing it from https://app-site-association.cdn-apple.com/a/v1/ may not be updated immediately. The specific time of this cache is uncertain, it may vary from a few hours to a few days .
-
In other words, even if we modify the apple-app-site-association file on our server, when tested with the app, we may not immediately achieve the effect we want. For example, we initially configured this in the AASA file:
"paths": [
"*"
]
This means that all URLs under the current domain name will evoke our app
But if you modify it:
"paths": [
"NOT *-wx-*",
"*"
]
This means that we want the url containing -wx- in the current domain name to not trigger the app. But when we modify the AASA file and update it to the server, we also make sure that the server file is updated.
You may still find that the test effect is not what we predicted, and the URL containing -wx- will still evoke the app. At this time, check
https://app-site-association.cdn-apple.com/a/v1/你的域名.com
You will find that it is still
"paths": [
"*"
]
- Just like the caching of file content, I feel that after we opened up access to foreign IP addresses, https://app-site-association.cdn-apple.com/a/v1/ or apple CDN did not have immediate access updates. So it didn't take effect at the time, but the cache update took effect the next day.
4. Points to note
When a user is browsing your site in Safari and clicks a universal link that points to a URL on the same domain as the current page, iOS respects the user's most likely intent and opens the link in Safari.
If a user clicks a universal link that points to a URL in a different domain, iOS opens the link in your app.
The meaning of this paragraph in the document is that if we have a domain name A configured with Universal Links.
At that time, when the user opened domain name A from domain name A (A->A), the APP jump would not be triggered.
Only when the user clicks on another B domain name to go to the A domain name (B->A), the APP jump will be triggered. The B domain name is an ordinary domain name.