I use the cordova plugin "ionic-plugin-deeplinks" (to my knowledge also works with a plain cordova app).
On Android, links when clicked let users choice between chrome and my application.
=> I suppose that app links works
=> As I'm able to access window.IonicDeeplink and redirect the user to the right page
I'm not able to have the same behavior on iOS, when I click a link I always get the app open in Safari.
How can I find clue on issues ?
More context:
apple-app-site-association is got with a HTTP 200 (over https only), it's located in /.well-known/apple-app-site-association:
I checked TeamID and BundleID 5 times (at least);
with the branch.io validator i get all validations green:
Your domain is valid (valid DNS).
Your file is served over HTTPS.
Your server does not return error status codes greater than 400.
Your file's 'content-type' header was found :)
Your JSON is validated.
with the apple validator, I got : "Action required
Could not extract required information for Universal Links. Learn how to implement the recommended Universal Links.
Error no apps with domain entitlements
The entitlement data used to verify deep link dual authentication is from the current released version of your app. This data may take 48 hours to update." (but some devs said that working app add the same error) what to do with that result?
when monitoring server's log while installing the app with Xcode I see a request get a HTTP 200 on apple-app-site-association
while installing the app with Xcode I got no logs referring to swcd in Xcode (I read here that I should if I had error while installing the app). Is a successful installation silent?
I followed that guide to setup entitlements, but some things feel odd with it:
Unlike the snapshot in the guide, I didn't found any *.entitlements file in my project. Should I have one with cordova? (my xCode seems to remember my setting though). Is it possible to check that installed app get entitlements?
I did set my domain in Xcode like this: applinks:mydomain.com and the switch is ON. But I never uploaded any thing from my local dev environment to apple services. Should I have? If yes, how ?
My current interrogations are highlighted but any explanations on any lack of understanding will be more than welcome!!!
Until then I started a verification for testFlight looking for more info.
while installing the app with Xcode I got no logs referring to swcd in xCode
I implemented Universal Links manually, but situation was similar. Particularly I mentioned empty swcd process log while installing the app, and it turned out that most likely iOS didn't even try to download apple-app-site-association file, like if responsible process wasn't run. In my case device restart helped and deep-linking began to work.
Thus I think restarting device is one another step in troubleshooting when you are sure about all your setup.
For anyone trying to debug this in development:
In XCode, ensure you're editing the Debug version of Signing & Capabilities.
To bypass the Apple Universal Links CDN, configure your Debug domains like applinks:?mode=developer -- adding that query string in development is important.
On your iOS Device, go to Settings->Developer->Universal Links and ensure the Associated Domains Development toggle is switched on.
On your iOS Device in Settings->Developer->Universal Links->Diagnostics, enter your Universal Links URL and ensure you get a green checkmark.
After following all of these steps, Universal Links work locally.
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).
I have developed & installed an iOS app locally on my device.
And have set custom scheme in the info.plist as mydlink
Set associated domains as weel: applinks:<myapp>.app.goo.gl
Created dynamic link on firebase as:
https://<myapp>.app.goo.gl/?link=http://<mysite.com>/&ibi=<app bundle id>&ius=mydlink&ifl=https://itunes.apple.com/WebObjects/MZStore.woa/wa/viewSoftware?id%3D<app store id>%26mt%3D8&pt=<app store id>
When I open or click on dynamic link, it opens app page in the "App Store" app and not opening app itself though its installed.
What am I missing here?
sometimes we make a mistake in Associated Domains entitlements. There have to be no spaces
applinks:mydomain.page.link
If you are on iOS 9, universal links will be used. Universal links don't work in a lot of cases, like:
If you use a simulator
If you try to open the link directly in safari on a device (typing it into the address field in the browser)
I spent a lot of time trying this and could never get it to work on a simulator in a reliable way. What I end up doing is emailing the link to me and opening it from Inbox. Then it works every time!
I had an issue using iOS 14, running on device in debug mode.
Link has always redirected me to the AppStore app not to my app.
The solution was to enable "Associated Domains Development" on iPhone Settings>Developer>Associated Domains Development
(found it here: https://stackoverflow.com/a/63939770/6689321 ).
I'm sorry for the late reply - I hope your issue has been resolved and that this is helpful to others who may be experiencing the same problem.
There could actually be one or more issues here for iOS 9+; Dynamic Links relies on Apple's Universal Links to open the app on iOS 9+ and these suggestions are aimed at resolving issues with Universal Links and Firebase and have nothing to do with the SDK directly.
Verify that the assoc file is correct at https://app_id.app.goo.gl/apple-app-site-association - it should look similar to https://maps.app.goo.gl/apple-app-site-association but with only one element in "details."
As pointed out by another answer, verify that your team ID is properly set in the Firebase console.
If you've long-pressed the link and then clicked "Open in Safari" or you have clicked the "goo.gl>" button on the status bar of your app after the app opens via a Universal Link, then iOS defaults to opening Universal Links in Safari. This can be fixed by pulling down on the paged opened in Safari and clicking "Open in App" (or similar) on the smart banner.
The "ibi" parameter is not involved in opening the app in a post-install click on iOS 9+, but is in prior versions when the "ius" param is not set.
Regarding iOS 8, can you try running the app and then clicking a link after the app is installed? On versions prior to iOS 9, you can test by copy/pasting the link into safari.
https://firebase.google.com/docs/dynamic-links/ios
Just in case there is still someone out there having this issue, please note the following
Dynamic links now opens on simulator, please copy your link and paste on safari in your emulator.
Chrome and safari opens dynamic differently, safari uses only universal linking while chrome uses both url scheme and universal linking to open dynamic link. Ultimately you should try to get dynamic linking opening via universal link in your app.
If your dynamic link routes to App Store instead of opening your app. there is an issue with your universal link. You can temporarily test using chrome.
To set up opening dynamic link via universal link, please check the following
Ensure your Team id is correctly set In firebase console, get your team id from your membership detail in https://developer.apple.com
Ensure your domain is listed in your associated domain as shown below, no space between the domain
Ensure Associated domain is turned on in your apple developer account
if you are using a custom domain, ensure you add it to the info.plist as shown below.
I make a mistake that not setup Associated Domains for DEBUG, so make sure you setup Associated Domains all both DEBUG & RELEASE
I experienced same problem. Interestingly if you open the dynamic link in Chrome, app starts directly and successfully. But in Safari always it tries to open AppStore although the app is installed. I have no idea why Safari doesn't work in this case.
If none of the above workarounds work for you, please check if you have added activitycontinuation in associated domains or not.
Firebase dynamic links were not working for us (on iOS9 where they use universal links) due to a problem in Firebase's assumptions during setup. Here's how we fixed the problem on our app:
Firebase asks for your "Team ID" when adding your iOS app to Firebase Console Project Settings, and it assumes that your unique app ID will be in the format TeamID.com.foo.bar
However, in our case, that was NOT our unique app ID. When I looked at our provisioning profile (on developer.apple.com I found our provisioning profile and clicked "edit"), I saw that our unique app ID was actually SomethingElse.com.foo.bar
I had to go into Firebase Console and enter that "SomethingElse" in the spot where it asked for Team ID, even though that was NOT our team ID. Once I made that change, Firebase Dynamic Links started working correctly.
It appears Firebase is making an assumption that your unique app ID will always start with your Team ID, which is apparently not always the case.
Note that changing your Team ID can take a significant amount of time to take effect. You can see that the change has happened by checking the appropriate link for your app_id (https://app_id.app.goo.gl/apple-app-site-association).
After integrating Firebase Dynamic links, the sample link started working immediately on a device with iOS 8. For iOS 9 devices Universal links mechanism is used, as mentioned by other answers. This means Apple needs to update the entitlement data used to verify deep link dual authentication. This may take 48 hours, according to Apple's App Search API Validation Tool.
There are more Universal links troubleshooting tips here.
Experienced the same problem.
The solution for me was to use the
Identifiers -> App IDs -> 'my.app.ID' -> Prefix
You can find it on: https://developer.apple.com/account/ios/identifier/bundle
Instead of the 'DevelopmentTeam' number from the .pbxproj which I used and add it to the Team ID for my iOS app in the Firebase console.
And don't forget to download and add a new .plist to the project.
i had same issue with latest flutter sdk and firebase dynamic links plugin.
Tried all solutions the only fix was to manually insert com.apple.developer.associated-domains key to ios/Runner/Running.entitlements file
<key>com.apple.developer.associated-domains</key>
<array>
<string>applinks:abc.page.link</string>
</array>
I have great news.
I always hear that it's IMPOSSIBLE to test a dynamic link on simulator.
But now WE CAN test firebase dynamic link on simulator
https://stackoverflow.com/a/56385506/6273003
When link is open in safari, It shows a "open (project name)"button. If this button is pressed for 2-3 second, It asks for opening that into different apps for first time.It also shows your app name. If you select your app, It opens your app. After doing that if you again open this link and press button in safari, it always work fine.
This fixed the problem for me.
After completing the setup in Firebase and in the Xcode project.
Add below code inside SceneDelegate instead AppDelegate.
func scene(_ scene: UIScene, continue userActivity: NSUserActivity) {
if let incomingURL = userActivity.webpageURL {
print("Incoming URL is \(incomingURL)")
let linkHandled = DynamicLinks.dynamicLinks().handleUniversalLink(incomingURL) { (dynamicLink, error) in
guard error == nil else{
print("Found an error! \(error!.localizedDescription)")
return
}
if let dynamicLink = dynamicLink {
self.handleIncomingDynamicLink(dynamicLink)
}
}
}
Set on your Xcode project the correct form to declare Associated Domain, you must to include applinks:
Make sure you have a Team Id set in the firebase console for you app. (you will then need to download and import the .plist file).
This fixed the problem for me.
We had a similar problem. The issue in our case was that the software that generated the emails with the links generated a new link that had a 304-redirect to our deep link. This did not work in Safari (but in Chrome).
Check that your deep link is actually the first link opened when you click the link in the email.
i had same case and it fixed with after defined ios app on deeplink url;
Dynamic Links -> choose your link -> Edit
make sure that you have defined ios app;
I had the problem, that the AASA file was different at the locations
[domain]/.well-known/apple-app-site-association
[domain]/apple-app-site-association
The validator from branch always checks the file on the non well known path. It was confusing because it always said it was all fine even though is was not.
For Firebase, check your hosting and search in the public dir for a .well-known folder. In my case, I could just delete it, run firebase deploy --only hosting and let Firebase generate all AASA files for me.
https://branch.io/resources/aasa-validator/
If you are sure all your dynamic links config in xcode is correct, link is good, but it still opens Appstore you can try this trick:
Copy the link and paste it into the notes app
Long press on the link in notes to see context menu
If you see button "Open in YourAppName" - try pressing it.
please check associated domains as well: applinks:.app.goo.gl is correct or not? and Dynamic link is easily work on iOS Simulater , I don't get any issues.
So I followed this tutorial exactly and use the same values as the ones provided:
https://blog.branch.io/how-to-setup-universal-links-to-deep-link-on-apple-ios-9
The Apple Association file is also ready in the link directory:
WEB_PAGE:PORT_NUMBER/apple-app-site-association
Everything seems to be set up on this side.
I've added the entitlements, updated the provisioning profile, and everything's set up.
When I run the app on my device, and open the link http://WEB_PAGE:PORT_NUMBER, this always opens Safari.
I even have breakpoints in the following method:
- (BOOL)application:(UIApplication *)application continueUserActivity:(NSUserActivity *)userActivity restorationHandler:(void(^)(NSArray * __nullable restorableObjects))restorationHandler
But zilch.
Has anyone perfected this? Is there something I'm missing?
There are a few possible issues.
Try pasting your domain into this link validator and make sure there are no issues: https://limitless-sierra-4673.herokuapp.com/ (credit to ShortStuffSushi -- see repo)
iOS logs an error message in the system logs if you don't have TLS set up properly on the domain specified in your entitlements. It's buried in the OS logs, not application logs. The error message will look like Sep 21 14:27:01 Derricks-iPhone swcd[2044] <Notice>: 2015-09-21 02:27:01.878907 PM [SWC] ### Rejecting URL 'https://examplecustomdomain.com/apple-app-site-association' for auth method 'NSURLAuthenticationMethodServerTrust': -6754/0xFFFFE59E kAuthenticationErr. Error message pulled from here, quick (incomplete) instructions on using CloudFlare for TLS here.
In my personal testing, clicking/typing in a link in Safari has never once opened the app directly. Clicking from other apps (iMessage, Mail, Slack, etc.) has worked. Others have reported that clicking links in Google search results have opened the app directly.
Note that if a Universal Link succeeds in opening your app and then you click through to Safari (by tapping your site in the top right corner of the nav bar in app), then iOS stops opening the app when you visit that URL. Then in Safari, you can pull down to reveal a banner at the top of the page with "Open". I wasted a lot of time on this. Note that clicking through to the site => disabling UL seems path specific, based on the paths you specify in the apple-app-site-assocation file. So if you have separate routes, yoursite.com/a/* and yoursite.com/b/*, if you click yoursite.com/a/* and it opens your app directly, you then have the option in the top right corner of the app to click through to yoursite.com/a/*. If you do that, subsequent visits to yoursite.com/a/* will open in browser, not app. However, yoursite.com/b/* should be unaffected and still open your app directly.
Let me know if you discover what the issue is. I'm personally very curious about how Universal Links work and what edge cases exist.
There are a lot of ways this can go wrong. Two points caused me trouble:
In Xcode, when you add the Associated Domains entitlement, each entry needs to start with applinks: and then your domain name. E.g. applinks:www.apple.com.
Though Xcode created an entitlements file for me, it did not include in my build: I had to click that box manually.
And yes, after doing that, it wasn't necessary to sign the apple-app-site-association file: it is just plain text, and it works, as long as it's served over HTTPS. (You'll still need to sign it if you're supporting iOS 8, though.)
To help debugging this issue, search for "swcd" in your device's console output when installing your app to see if registering your universal link worked or failed.
Use an actual device, not the simulator.
Delete the app from you device.
Connect the device to your computer, and view the device's console output in xcode. (window -> devices -> [your device] -> open console). Keep this window open.
Install your app and let it launch.
Filter the console output to "swcd". If it's sucessful you will see something like the folowing screenshot. If it fails you'll see something else. If you don't see anything then you messed something fundamental like adding the Associated Domains entitlement.
There is apparently an error in the documentation for making the association file for Universal Links.
Where it says:
The value of the appID key is the app’s team ID and the bundle ID
it should say
The value of the appID key is the app’s Prefix and the bundle ID
For most apps, it seems that the Team ID and app prefixes are the same, but if your app has been in the store for many years, these values can be different.
To find this value, open the Member Center on https://developer.apple.com and look at "Certificates, Identifiers & Profiles", click "Identifiers", then "App IDs" in the table under "Identifiers". Find your app, and use the Prefix value and Bundle ID there to create your AppID for the association file.
To validate apple-app-site-association on the server side, you can
use Apple's official validator.
https://search.developer.apple.com/appsearch-validation-tool/
St.derrick's Answer is informative.
But to enable universal links again to open in app instead of safari we need to do the following thing.
Long press on Universal link in Mail or iMessage, then you will see options whether to open in safari or in App.
I realized that be problem for me was that links to the root directory a (eg. http://example.com/) did not open my app but if I added a path (eg. http://example.com/mypath) it worked. Adding "/" to the paths list sovled it:
{
"applinks": {
"apps": [],
"details": [
{
"appID": "TEAM_ID.BundleIdentifier",
"paths": [ "*", "/" ]
}
]
}
}
As answered by slutsker in this Apple Developer Forums thread.
For anyone who needs to easily test opening (Universal) Links, you can also open the link in your Simulator from the terminal with this command:
xcrun simctl openurl booted yourapp_or_http://yourlink
for example:
xcrun simctl openurl booted https://www.google.com
Quick steps to check whether you have implemented Universal Link correctly.
Tap and hold on the link that you expect to launch the app. You should see a "Open in [your app name]" in the Context Menu.
Open Notes app, type the link you expect to open the app. Tap Done. The link will turn yellow and tapping on the link should open your app, and not Safari.
If the link http://yourDomain.com is not launching the app, try http://yourDomain.com/yourFolder/
In Safari, If the Context Menu shows "Open in [your app name]" in safari, but tapping the link opens the link in safari itself instead of launching the app,
a. Try pulling down on the safari page that opened when the link was clicked like the way you 'pull to refresh'. A banner should appear that can open your app. Tap the banner to open the app, close the app by pressing home button, get back to safari and try launching the app by tapping the link again. This time on, the app should get launched because tapping the banner should have saved the preference to open the link in app.
b. If the app still don't get launched after the step a., try mailing the link to a webmail such as gmail and open the webmail site in safari and try clicking the link. If this works, you may have been trying to launch the app from the same domain as the link. From what I have seen, launching the app from the same domain mostly fails. Probably safari wont care to check whether the destination url is a universal link, when the link is into the same domain that user is on. So try to launch the app from another domain.
It's also super important to increment the project version or build number after integrating universal links. Even if you delete/reinstall, iOS won't pickup the links unless you bump the version.
Universal Links will not work if you paste the link into the browser URL field.
Universal Links work with a user driven <a href="..."> element click across domains. Example: if there is a Universal Link on google.com pointing to bnc.lt, it will open the app.
Universal Links will not work with a user driven <a href="..."> element click on the same domain. Example: if there is a Universal Link on google.com pointing to a different Universal Link on google.com, it will not open the app.
Universal Links cannot be triggered via Javascript (in window.onload or via a .click() call on an <a> element), unless it is part of a user action.
source: https://dev.branch.io/getting-started/universal-app-links/support/ios/#appsbrowsers-that-support-universal-links
The 3rd bullet cost me about a day to figure out.
Incase people here are looking for other solutions, we put together a whole step-by-step on debugging Universal Links as we've seen a lot of issues pop up, causing a LOT of headaches.
Check it out:
Universal Links Debugging Guide
If you're just looking to set up Universal Links fresh, this guide is really helpful:
iOS Deep Linking Setup Guide
Hope they're helpful!
Just thought I would add some things I discovered in case more people encounter the same issues as me in the future. These are mostly related to authentication errors.
Even though apple doesn't explicitly state it, the apple-app-site-association file must be served over https, even if signed. The certificate used for https must also be trusted by apple. So while a certificate added to the device in Settings -> General -> Profiles will allow https in safari, it will not allow universal links to work.
In the device logs, on an authentication error between the device and the server, there will be a value printed like "TrustResultValue" : 4. A TrustResultValue of 5 means the certificate is for the wrong domain (Eg. test.com served from www.test.com). A TrustResultValue of 4 means the certificate is not trusted for this use.
There may be some helpful steps for debugging here. The "Testing access to apple-app-site-association" section is a step by step guide for how to make sure the device is getting the apple-app-site-association file. The steps boil down to:
Uninstall the app. This is necessary because the file is downloaded on install.
Stop the server from properly serving apple-app-site-association.
In xcode, open Window -> Devices and then select your device.
Open the device logs by clicking the triangle at the bottom of the window.
Clear the logs by clicking the trashcan to clear any previous logs that might be related.
Reinstall the app with xcode by clicking the play button.
After the app has launched, if the device is correctly requesting the file then the device logs should contain an error that can be found by searching for "apple-app-site-association".
If the apple-app-site-association file is properly served (step 2 is left out) then there should be no error. An authentication error may instead be displayed if that is the problem.
We've added apple-app-site-association file to this location:
https://example.com/apple-app-site-association
On iOS 9 it worked fine, but on iOS 10 it didn't work.
It appeared that problem was with .well-known path:
https://example.com/.well-known/apple-app-site-association
Because of https://example.com/.well-known/apple-app-site-association path redirected to https://example.com
<Notice>: Allowing redirect 'https://example.com/.well-known/apple-app-site-association' -> 'https://example.com/'
<Notice>: ### Rejecting AASA file size 154466 for URL https://example.com/.well-known/apple-app-site-association
In my opinion if somehow .well-known path doesn't work correctly it breaks universal links.
The most common cause is when user tap on the top right, thus telling iOS to NOT open the app (in this case Uber) in the future.
To fix, pull down to reveal the smart banner and tap on OPEN:
This will subsequently "remember" to open the app.
For ios13, there is a new format - check out here https://developer.apple.com/documentation/safariservices/supporting_associated_domains_in_your_app?language=objc
I updated my file to look like this:
{
"applinks": {
"apps": [],
"details": [
{
"appIDs": ["1234.app.company.appname"],
"appID": "1234.app.company.appname",
"components": [
{
"/": "/login"
}
],
"paths": [ "/login" ]
}
]
},
"webcredentials": {
"apps": ["1234.app.company.appname"]
}
}
After spending a day trying to get this to work, Restarting my phone solved the problem.
Uninstalling/Reinstalling the app didn't work either.
I've managed to make it work, but it took quite some time and struggle. Note that unless you sign the apple-app-site-association file (signing is optional!) tapping on a link in Safari will not open your app (it has caused me a lot of headache).
Sometimes I find that everything is fine with the association file but iOS decides to always open the universal link in Safari. To test if the app recognises the app link I add the URL to Notes or a Calendar entry and then long press it so the contextual menu appears. If it says "Open in {YOUR APP}" then the link is working but iOS is deciding to open it in Safari. Tapping "Open in {YOUR APP}" will tell iOS to open valid universal links via your app from then on.
Took me close to a day to figure this out.
The issue I had was not downloading the updated provisioning profiles in XCode (I also restarted XCode after this).
(Preferences > Accounts > View Details > Download All)
You can test universal links in simulator
From the App Search Programming Guide: Support Universal Links
After two days it turned out for me, that these kind of links (from branch)
applinks:xxxx.app.link
work only after Archiving (also Ad-hoc) the application and install it to the phone.
Hope this helps someone because this took me about two days to figure out.
We had to add www. to our associated-domains in our .entitlements file.
<string>applinks:www.yourdomain.com</string>
<string>activitycontinuation:www.yourdomain.com</string>
Because if we used yourdomain.com instead of www.yourdomain.com our servers did a redirect -> 304 and then didn't include the content-type: application/json for the apple-app-site-association file.
N.B. the universal links still work for yourdomain.com and www.yourdomain.com
If you are hosting your apple-app-site-association on Firebase, make sure to put it in /.well-known/ subdirectory! It appears that Xcode queries that URL first, and if it succeeds, it makes no attempt to query the apple-app-site-association in the root directory. For some reason, firebase engineers made the hosted websites to automatically respond to /.well-known/apple-app-site-association with an empty (but correctly formed) association file that overrides your custom one, leaving you with no clue why nothing works!
Go to developer.apple.com and edit one of your distribution profiles. In the editing page you can open a pop up for App IDs that will show a list of your app names and in () round brackets behind the app's name it reveals all your real App IDs. Some apps might have your team ID as prefix but some do not. Make sure to use exactly what you see in that pop up menu inside the () and put it into the apple-app-site-association details appID field. I had exactly this issue with an app and its universal links.
The issue for me turned out to be the apple-app-site-association file. According to Apple's documentation, only the applinks parameter is required. I added the activitycontinuation parameter and it worked.
{
"activitycontinuation": {
"apps": [
"9JA89QQLNQ.com.apple.wwdc"
]
},
"applinks": {
"apps": [],
"details": [{
"appID": "9JA89QQLNQ.com.apple.wwdc",
"paths": [ "/wwdc/news/", "/videos/wwdc/2015/*" ]
}]
}
}
Haven't really seen the exact same issue/solution combo that got it working for me so might as well add mine incase someone has the same problem!
For my app I am using a custom URL scheme (set in APP_TARGET > Info > URL Types) and set the URL scheme from here into the Firebase console to match but still wasn't working.
My problem was actually two problems:
Watch out if checking Automatically Manage Signing
If you are checking Xcode's "Automatically manage signing" setting like I was, since I was just trying to make a quick demo app, you will want to ensure that the TeamID that is used matches the one in your Firebase console. I originally went to my Apple Developer Account and copied the team ID from my Membership page, but later saw that the actual ID being used by Xcode was different. (You can find this in APP_TARGET > General > Signing > Signing Certificate. For me it looked like iPhone Developer: My Name (TEAM_ID)).
Prefix your TeamID to your Bundle Identifier in your URL Types
After I ensured these matched in my Firebase console and Xcode, my next problem was the identifier for my URL scheme. It's typical to use your bundle identifier here, but Firebase actually prefixes this with the Team ID you gave in your Firebase console, so I had to prefix it to the identifier in the URL types section in Xcode as well.
After these two fixes and re-downloading the GoogleService-Info.plist file I had no problem open up my dynamic links.
After two days of total desperation, I think I've finally fixed it. Here is my solution:
It seems that older apps use a different app prefix than newer apps. Newer apps only use the Team ID for this purpose. If the app prefix and the team ID are not identical, it seems that you need to specify the activity continuation field in the apple app site association file:
{
"activitycontinuation": {
"apps": [
"YOUR_APP_PREFIX.de.company.app"
]
},
"applinks": {
"apps": [],
"details": [
{
"appID": "YOUR_APP_PREFIX.de.company.app",
"paths": ["/*"]
}
]
}
}
Another thing I experienced during my hell ride was that deleting the app and restarting the device seems to be the only way to force refresh this file.
For me, after implementing all the answers from above and testing that the AASA file was indeed being downloaded with mpoisot's answer, my issue was that in Xcode I added the associated domain as:
applinks:example.com
and in my notes app I was trying to use:
Https://example.com
because my AASA is not signed and I wanted to ensure I was serving it through HTTPS. So it worked when in my notes app I tried to use:
example.com
It works for me on a physical device, using iOS 12.1.2 with either a development build from Xcode or a distribution build from Testflight
In my case I needed to make the server serve the apple-app-site-association file using content type: application/pkcs7-mime. In nginx I did it using this approach:
location ~ /.well-known/apple-app-site-association {
default_type application/pkcs7-mime;
}
As other suggested I also had to make sure I:
Use the new iOS apple-app-site-association format https://developer.apple.com/documentation/safariservices/supporting_associated_domains
Use the correct TEAM ID so it becomes "appIDs": [ "TEAM_ID.my-app-bundle-id"],
Make sure in Xcode's entitlements, the app associations start with applinks:
Note that I never saw the "success" messages in the Console app as shown in screenshots by another user. In the console I kept getting Entry [...] needs its JSON updated because the app PI changed, but this was not an issue.
Also note that when trying to open the apple-app-site-association in the browser, the file gets downloaded instead of displayed, but this was not an issue in my case.
And as always, use a real device, re-install app whenever you change things, potentially also restart device and maybe increment app version number.