One file for each domain, both www.example.com and example.com need separate files:
{
"applinks": {
"apps": [],
"details": {
"9JA89QQLNQ.com.apple.wwdc": {
"paths": [
"/wwdc/news/",
"/videos/wwdc/2015/*"
]
}
}
}
}
- Fall back gracefully
- If cannot handle, open Safari
UIApplication.sharedApplication().openURL(webURL)
There is no guarantee that the user experience with custom URL schemes will remain the same in the future. Smart App Banners afford the preferred experience.
https://developer.apple.com/videos/wwdc/2015/?id=509
<head>
<meta name="apple-itunes-app" content="app-id=640199958, app-argument=https://developer.apple.com/wwdc/schedule, affiliate- data=optionalAffiliateData">
</head>
I've found that the apple-app-site-association file is fetched when the app is installed on the device. So essentially, every install/update will trigger a download of the file. You can simulate this by deleting the app from your device and reinstalling it.
@eyekay234 i would just simplify your life forever, and i'm just recommending because you're already using everything that makes this simple. Not a lot of people do this but mostly because they aren't aware you can. I actually serve this file direct from cloudfront, it doesn't even hit an s3 origin.
Pro tips
sockets.mydomain.tld
, usemydomain.tld/sockets
ORsockets.mydomain.tld/sockets
. Don't useimages.mydomain.tld
usemydomain.tld/images
ORimages.mydomain.tld/images
annoying-crawler-files
withrobots.txt
,sitemaps.xml
,subdomain.robots.txt
, create a behavior for/robots.txt
, even in the most complex cases, attach a simple 3 line CF function to that behavior to select the correct file path based on hostnameTLDR:
A
andAAAA
with alias pointing to a single CloudFront distribution.Unrelated, but makes these critical/annoying/fragile tasks so much easier to work with from a simple static site, to full size production multi-origin, multi-service, serverless to monolith service.
@jenipharachel sorry years late, i have to look with what i ended up with