I am new to adding universal links to iOS applications. I have read some materials but still have a few questions below. Any pointer will be greatly appreciated!
When exactly Apple will crawl my domain and inspect the [domain]/apple-app-site-association content? I have a new domain, and I'm wondering how Apple's crawler can discover it?
What's the recommended way to test universal links locally before publishing the first version of my app?
Is version control for universal links not possible? For example, the app 1.0 version only supports \item universal link, but app 2.0 version supports one more schema \details . If I specify both paths in apple-app-site-association, then the 1.0 app will break when user navigate to \details. (Edit: I noticed that if the app appropriately set it to be unhandled, then we can still fall back to browser.)
Thanks!
When a device downloads an app, it looks for an entitlements file to list out your associated domains. When it finds that your app has associated domains, it will check those domains for the aasa and download it onto the device. The aasa for that app will only be downloaded on install and update so changes you make will not effect all of your apps.
For testing you can host your AASA on a testing domain or on your production domain. It's up to you but you have to remember to update your entitlements file when you push it to production to ensure that you have the right domain configured. Every time you rebuild the app, it should re-download the aasa so testing shouldn't be too difficult. Always remember to paste the link in notes and not type it into Safari. Universal links only work when they are tapped, not typed in.
For your example you should make sure your new AASA is published at the exact time you publish your app. You should probably use a separate testing domain to host your AASA. You can just include both domains in your entitlements.
Branch actually has testing environment and AASA hosting built in if you'd prefer not to handle all of that on your own. They also leverage URI schemes in cases where Universal Links don't work.
Related
Is it possible to verify the apple app site association file was properly requested and configured for an instance of an installed IOS app? Ideally, we could easily verify that Universal Links are working properly for an instance of a device and installed application for the purpose of debugging. As an alternative, we could leverage a metric that confirms this association occurred properly for the purpose of alarming.
Background
Clicking on a URL associated with an IOS application that has been properly configured Universal Links enabled sometimes does not immediately launch the associated app.
I am aware that there are a few known cases where the app does not launch when it should (eg. Source App use redirect URL for attribution, Association files fail to load etc), but it is not clear at a glance if this behavior is an actual widespread issue and it is not clear how to debug it.
What I have tried?
Followed all steps listed for Support Universal Links to ensure Universal Links are properly configured
Verified URL host with Branch.io AASA Validator
Confirmed there is no Web Server errors when serving these AASA files from /.well-known/apple-app-site-association
Confirmed this behavior works most of the time*
*As an alternative to debugging, we have considered a metric that confirms this association (if it exists)
I have got a problem. There are two instances of app with different bundleID for dev and for prod. This apps can handle universal links. Problem is that where one apps trying to open link in safari, second (if they are both installed on the phone) app handles this link and open it by itself. So when one app wants to open safari another handles it and open itself. For example:
www.dev-domain.maindomain.com/id980 - dev link
www.prod-domain.maindomain.com/id980 - prod link
in project capabilities it's looks like applinks:*.maindomain.com
I was trying to applinks:dev-domain.maindomain.com or prod-domain.maindomain.com for different bundles but in this case handling universal links didn't works at all. AASA file located on www.maindomain.com/apple-app-site-association
How can I handle this situation, so prod app will handle only prod domain links and dev only dev?
Trying to implement universal links in my iOS app running iOS 10, whenever a click a link in my webpage I get the following message in the device log:
Feb 24 15:07:11 iPhone swcd(CoreUtils)[10142] <Notice>: Get info for service 'applinks', app ID '<<NULL>>', domain 'www.redacted...'
My app is setup with the required entitlements and capabilities for this domain. My associated domains entitlements key contains these domains:
applinks:redacted.com
applinks:www.redacted.com
The server is hosting the apple-app-site-association file on the root folder over https. I made sure the content-type of the file is set to application/json and there are no redirects leading to it. The contents of this file are:
{
"applinks": {
"apps": [],
"details": [
{
"appID": "teamid.redacted-app-id",
"paths": ["*"]
}
]
}
}
The way I'm testing this is by going into my site and tapping the first link I find, every time I tap this link I get the message I pasted above and the link opens in safari.
Your description of the problem does not provide any smoking gun indicator of what the issue might be. As I indicated in my previous comment, to really work through Universal Linking issues it is best to know everything that was configured and have a proper test plan that allows the configuration and the testing to be reproduced. There are just too many areas that could be causing problems.
Generally, issues with Universal Linking fall into being either setup issues or testing issues:
Setup Issues
Is the AASA file properly named and properly signed, is it being served from the correct location, are all entitlements correct?
Are the device and provisioning certificates all error-free?
Are you testing with a link that the app has been properly configured to support?
Testing Issues
Are you testing with a physical device? (some say Universal Links now work consistently in the simulator with iOS 10, but I'd still use a physical device)
What links are you testing? You indicate that you are "going into my site and tapping the first link I find." Are these links you are finding in the "redacted.com" domain? I would not use "www.redacted.com" as "www" gets special treatment by many systems and may not work as anticipated.
Could the AASA file have failed to update when the app was first installed/launched due to an issue with the testing environment's network connectivity? I find that the AASA will fail to download if Charles Proxy is capturing traffic, for example. If the AASA file does not make it to the device, Universal Linking will not work.
When testing, it sounds like you are not first pasting the link into Notes and then long-pressing on it. I would strongly recommend that you always test in this fashion first, so as to rule out the issue being related to your website, the application from which you are tapping the link, or the manner in which you are deploying the link (Universal Links will not behave as expected if you paste them into the Safari address bar, for example). When you do test by long-pressing on a link in Notes you should see "Open in App" menu option. If you do see this, but tapping on the link does not open the app, this would indicate that Universal Linking has been disabled on the device.
What is the behavior you are expecting to see when you tap on these links, and what is the actual behavior you are seeing? I often encounter people who believe Universal Linking is broken because they are testing a scenario that Universal Linking does not support. Are you sure the behavior that you are testing for is supported?
Are you using a device and an iOS version that supports Universal Links? Testing should be performed on physical devices, as mentioned earlier, and on iOS versions after 9.0 (where Universal Linking was introduced).
When Universal Linking does not work, there are a lot of things to check. I recommend running through Alex Austen's super blog post on this topic, as doing so may help you spot the problem (here: https://blog.branch.io/how-to-setup-universal-links-to-deep-link-on-apple-ios-9/).
Branch also has a number of tools/resources for identifying Universal Linking issues. They are specifically intended for use with Branch links, but you may still find them helpful:
AASA Validator: https://branch.io/resources/aasa-validator/
Universal Link Validator: https://dev.branch.io/getting-started/universal-linking-validator/guide/
Universal Linking Troubleshooting Guide: https://support.branch.io/support/solutions/articles/6000153326-ios-universal-links-troubleshooting-guide
Look at the logs here is how (taken from SO):
Xcode –> Windows –> Devices & Simulators
Click on device in the left
pane Click Open Console
From there, filter on "swcd" (SharedWebCredential Daemon). Keeping this console open.
You might need to open the console before installing your app dunno if it saves history while closed.
My problem:
I had my apple-app-site-association file hosted on subdomain.mydomain.com but then in Xcode I had Associated Domains set to applinks:*.mydomain.com. In the console mentioned above I saw that in this case the app was trying to get its apple-app-site-association file from mydomain.com. So I changed the Associated Domains to applinks:subdomain.mydomain.com
If none of the above workarounds work for you, please check if you have added activitycontinuation in associated domains or not.
Below is the picture showing the exact place where you have to add that.
(of course you haven't done that already).
Since iOS9, universal links work on iOS, but I am wondering if there is something like that on macOS? We have an application that is a macOS-App with a corresponding Web-App, and we would love links clicked by the user to open in the Mac-App instead of opening the browser with the target-link.
Is that anyhow possible on macOS? I just found samples for iOS, but none for macOS?!?
Supporting Universal Links on macOS requires support from both your app and your website (and macOS 10.15+).
See Apple's documentation Allowing Apps and Websites to Link to Your Content for details (the article deals with iOS, tvOS and macOS deep links), and its sub-articles Enabling Universal Links as well as Handling Universal Links.
Quick overview:
Basically, it's the same as on iOS: you need to create an apple-app-site-association file that is hosted on your server either in the root directory or in the .well-known directory (described in "Enabling Universal Links" linked above). It describes which URL paths can be passed to your app. It's important that this file is valid JSON (validate it!) and is served via HTTPS with a valid certificate and without any redirects!
You need to enable the "Associated Domains" capability in your provisioning profile. Details depend on whether Xcode manages your profiles or not. In your entitlements file (usually editable via the "Signing & Capabilities" tab of your target in Xcode) you need add the corresponding associated domain, like applinks:my.domain.example (no https:// or anything, just the raw domain name).
Then you need to implement application(_:continue:restorationHandler:) in your app delegate to handle the Universal Link.
It can be annoying to make macOS pick up the association for the first time during development. Debugging hints:
Open Console.app and filter for swcd, that's the daemon responsible for associated web credentials and Universal Links. Sometimes you see hints why it did not work (like refusing the apple-app-site-association file).
Also I had to kill the swcd daemon to make it get restarted by launchd and then pick up changes/fixes I did to the apple-app-site-association file. Both iOS and macOS should usually reload this file on "app installation"1 (haven't seen this getting specified more clearly; I guess they mean App Store installs/updates but I don't know about when this is loaded for macOS apps distributed outside the App Store).
Also, be aware that entering a Universal Link in Safari will not hand off to your app: Apple has stated in the dev forums2 that they believe if a user is already in the browser environment they want to stay there and not suddenly move to an app. Therefor, to test the Universal Link, open Notes.app, create a new note and enter/paste the Universal Link you want to test there. You can then click it and get asked whether you want to open this in your app.
1) Sorry, don't have a dev forum link where I read this.
2) Again, sorry, don't have a link right now. Saw this stated at least two times by Apple employees, both cited the Notes trick. Even though they were talking about iOS there, this behaviour is the same on macOS as well.
We have a need to support 100+ domains in our entitlements file for Universal Links.
Example:
applinks:test.myapp.com
applinks:blah.myapp.com
applinks:foo.bar.com
etc...
I know that *.myapp.com will be supported in iOS 9.3, but is there a way to do this elegantly for customers using iOS 9.0 to 9.2 without having to manually add 100+ entries to the entitlements file? Is there a way to do this without having to rebuild and re-release our app every time we need to add a domain to the list?
Thanks!
The new wildcard support in iOS 9.3 is designed for exactly the situation you're describing, so there isn't really a solid alternative in earlier OS versions.
If you don't want to worry about continually updating the list of subdomain applinks entries (or even if you do, but need to wait for App Store review), the best workaround is probably hosting fallback pages on each subdomain with a call-to-action the user can use to continue into the app. That would work as follows:
Assume that you have applinks:mydomain.com configured.
User opens a link to new.mydomain.com/exciting-page (which is NOT covered by the entitlement above).
User sees a custom interstitial, functionally similar to something like this. On this interstitial is a link pointing to mydomain.com/new/exciting-page
User opens the link and the app launches.
The only thing I am not sure about is whether mydomain.com and new.mydomain.com count as 'different domains' for the purpose of Universal Links, since Universal Linking functionality is disabled in Safari for links within the same domain (source). If this turns out not to work, you could easily use something like applinks:mydomain.io and a link to mydomain.io/new/exciting-page in step 3 instead.