11

I tested Universal Links in iOS by turning on Airplane mode and saw that the correct application was opened (instead of a website)

This indicates some level of "caching" the apple-app-site-association.

I want to determine the extent to which this is cached, so I can determine

  • What UX edge cases are there (e.g. Offline for x days)
  • What security considerations are there (e.g. MITM / SSLStrip + .well-known/URL)

etc.

Ideally I would like to have details if additional logic is employed (conditional caching if HTTPS employed, DNSSec, etc)

makerofthings7
  • 60,103
  • 53
  • 215
  • 448

2 Answers2

36

The exact behavior here is (intentionally?) unclear from Apple. Here is my personal experience, gleaned partly from official documentation and partly from helping thousands of apps implement Universal Links at Branch.io.

  • The apple-app-site-association file is cached once when the app is first installed.
  • If this initial scrape fails, in almost all situations it will not be reattempted. The only exception to this is if the initial return is a 5xx error, in which case a limited number of retries may occur. This is not well-documented, and is not covered in Universal Links documentation at all. You can find a mention in the Shared Web Credentials docs.
  • The file is not checked at all when a Universal Link is opened. This is why you are able to get Universal Links behavior in airplane mode.
  • The file does not expire. Once it is cached, it sticks permanently for as long as the app is installed.
  • The file will be re-checked when installing an app update.
  • The file must be accessible via a valid SSL connection at either https://example.com/apple-app-site-association or https://example.com/.well-known/apple-app-site-association. If there are redirects of any kind, this will fail.
  • It is theoretically possible to MITM the request if you are able to install a new SSL certificate directly on the device in question. Charles Proxy for example uses this approach for debugging. I have never seen or heard of this being exploited, and the damage would be quite limited because the domain still has to be specified inside the app itself.
Alex Bauer
  • 13,147
  • 1
  • 27
  • 44
  • Alex, I would consider Branch.IO for my project, but under no condition can my data travel to your servers. If you had a more private solution I could be interested in Branch – makerofthings7 Dec 23 '16 at 19:02
  • 1
    That depends greatly on what you would classify as 'data'. We have a number of [high profile brands](https://branch.io/partners/) using the Branch service, so data privacy and security are taken very seriously. A common approach is using the link as a delivery mechanism for an encrypted token referencing the data on your own backend, instead of storing the data itself in the link. Feel free to [get in contact](https://support.branch.io/support/tickets/new) if you want to talk through any specific concerns! – Alex Bauer Dec 23 '16 at 19:10
0

I found a way to get around the caching issue. The cache is bound to the domain name, so for every time you want iOS to request apple-app-site-association you can create a new subdomain, and configure iOS to use that subdomain as the universal link for your app.

Extremely hacky, but it is the only workaround that worked for me.

mnemon1ck
  • 420
  • 3
  • 12
  • 1
    If you are updating your app, apple says they will fetch the aasa file within 24 hours. Otherwise, it is supposed to be re-downloaded after 7 days https://developer.apple.com/documentation/Xcode/supporting-associated-domains – Trevor Feb 28 '22 at 09:10