I'm trying to set up Associated Domains in my unpublished app for iOS 14. I followed the documentation as good as possible. I'm testing locally with my local dev web server and the app itself in simulator and a real iPhone.
Not only are links not opening in my app, the app does not even attempt to request the file https://mycomputer.local/.well-known/apple-app-site-association from my local web server (I let the web server print a debug message whenever it is requested, but the message is only printed when I manually load it from a web browser).
This is a list of things I have done/checked:
Xcode 12.2:
Under Signing & Capabilities added Associated Domains
Added to Domains: applinks:mycomputer.local?mode=developer (I also tried IP address)
I disabled Automatically manage signing and instead created a Profile on https://developer.apple.com/account/resources/profiles/list (type Development, platform iOS, it has Associated Domains amongst other enabled capabilities and it's linked to my app bundle ID) and selected that profile for the debug build.
I made sure that the URL https://mycomputer.local/.well-known/apple-app-site-association is accessible from all devices involved, i.e. my computer, Safari in simulator, Safari on real iPhone (all are connected to the local network and successfully display my JSON file).
Screenshot:
As mentioned above, I can pretty much rule out that the problem lies with the JSON file itself as I can proof that the device is not even accessing it. Am I missing something or misunderstanding the concept?
My own answer: Using the query string ?mode=developer in the entitlement as described in the documentation simply appears not to work at all.
To verify this I have set up a real server that can be publicly reached on the internet and tried both variants:
applinks:example.com
applinks:example.com?mode=developer
Number 1 works, but the JSON is loaded via Apple's CDN and you cannot use it for local development or for quickly testing different versions of the JSON file as Apple will cache the file for probably one day.
Number 2 does not work at all, no request to the server will be made.
Also, good to know these requirements when testing on actual devices. (And using a domain thats not publicly available in testing period.)
Turn on Developer Mode on the device.
Turn on Associated Domains Development in the Developer settings. (Developer settings will first occur after you have turned on Developer Mode).
Build the app using developer certificate. (Enterprise will not work).
Add ?mode=developer to the domain in entitlements if you are testing with a domain thats not publicly available (Behind VPN..)
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 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.
I am developing an app on Android and IOS and I would like it to support universal links.
I already have an apple-app-site-association file deployed on my PROD server (which is something like www.example.com), but I need to redeploy a new one with some restrictions inside (to NOT allow some paths).
Before redeploying it, I would like to test it on my test server. So I deployed it on the test server (which is www.example.test.local).
To test, I modified my IOS app by changing in Associated Domains the param applinks:.example.com by applinks:.example.test.local. Then I builded my app and tried to click on an url which is www.example.test.local/myPath?myQueryParam=toto (which is not a 'NOT allowed' one). But instead of opening the app, it opened the index of my test server (if I rollback everything and click on an url like www.example.com/myPath, it works perfectly but it is the old apple-app-site-association file).
So did I miss something? What do I have to change to make it work on my test server?
Late to the party here, but most likely your .local server was running on HTTP. You need to use HTTPS, with a valid certificate that the iOS device recognises (try fetching the AASA file by just typing in the URL, including https:// prefix, into Safari; if you get "This Connection Is Not Private", then your cert isn't good enough - stepping through warnings and forcing Safari to visit the site anyway may be enough to get the trust store updated and have the wider system accept your cert).
Unfortunately, like everything to do with app links on iOS and Android, it's a huge pain and exceptionally developer-hostile. There does not seem to be any kind of easier test option for local machine development - or at least, nothing that I can find documented.
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.
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.