Search code examples
iosdeep-linkingios-universal-links

Universal deeplinks do not open the app the first time they are tried

When the app installs, I see a request to https://example.com/.well-known/apple-app-site-association, which gets a 200 response with the proper json response.

Odd thing 1: the app then goes on to try to request /apple-app-site-association which fails as the file not there in the root. Why would it fall-back to this file if it already has the .well-known one?

After the app finishes opening, I can go into Notes or something and click on a deeplink e.g. https://example.com/some/path, this will open in safari.

Odd thing 2: before the site opens in safari, there are several requests to both .well-known/apple-app-site-association and /apple-app-site-association. I am pretty sure that the .well-known request comes first, and there is one more to the .well-known version than the root one.

After that, I can now go back to Notes and click on the deeplink and it now will correctly open the app. All is right with the world.

Any ideas what could be wrong with the first .well-known responses that causes them to not work and to generate the fallback requests? Anyone else with this problem or any ideas?

Below is a redacted screenshot from Charles (app install finishes at 11:24:18), and a redacted response from .well-known/apple-app-site-association.

enter image description here

HTTP/1.1 200 OK
Content-Type: application/json
Last-Modified: Tue, 06 Jun 2017 00:50:40 GMT
Accept-Ranges: bytes
ETag: "[redacted]"
Content-Length: 156
Connection: Keep-alive

{
    "applinks": {
        "apps": [],
        "details": [
            {
                "appID": "[redacted].com.[redacted]",
                "paths": [ "*" ]
            }
        ]
    }
}
Solution

  • This is an issue that you are encountering only because you are proxying the connection (using Charles Proxy - but any proxying would cause the issue). Apple is detecting that the connection was proxied and is not trusting the downloaded file.

    In real-world scenarios you will not actually have this issue, as your users won't be using Charles Proxy.