AASA passes, but Universal Links still open Safari: a diagnostic checklist

1. Record the journey that fails

Before changing configuration, capture the exact link, including its host, path and query. Write down the installed app's version, iOS version, and the app or browser where the tap started. Describe what happened: stayed in Safari, opened a store page, opened the app's home screen, or showed an error.

Use one test URL throughout the investigation. A successful check of the domain's homepage does not answer a report about a particular product path. If your failing journey starts at a short link, record its redirects and the eventual URL separately.

2. Check the website side of the association

Match the hostname exactly. For a link on links.example.com, inspect https://links.example.com/.well-known/apple-app-site-association. Apple requires HTTPS with a valid certificate and no redirect for this file. An entry for one specific host does not automatically configure another. See Apple's associated-domains setup.

Check the app identifier and URL matching rules, including exclusions. Apple documents identifiers as <Application Identifier Prefix>.<Bundle Identifier>; compare against your app's actual identifier instead of guessing the prefix. The association must name the app you are testing and cover the URL you recorded.

The free URX validator inspects the public file, its response and Apple's CDN copy. Save which hostname you checked and when. Its report cannot inspect your installed app's signed entitlement or prove the device has the same association state.

3. Check the build actually installed on the device

Confirm the app target has Associated Domains configured with an entry such as applinks:links.example.com. It contains a domain, not an HTTPS scheme, path or trailing slash. Check the installed build's configuration, not only the source project you currently have open. Apple explains both sides of this configuration.

Keep a copy of the app's configuration evidence with the file report. Otherwise, a teammate can fix the website while someone else tests an older build, and both report different results without knowing why.

Apple's CDN and a device's association state are separate checks. Apple documents reinstalling as a way for a device to request the CDN copy again, but provides no direct CDN invalidation control. Follow TN3155 after confirming the file you need is available; do not treat repeated reinstalls as a guaranteed fix.

4. Test a tap that can open the app

Apple recommends pasting the URL in Notes and long-pressing it to inspect the available open actions. Record the action you choose because it can affect later behavior. Typing a URL into a browser address bar is browser navigation, not this test. Use Apple's documented test procedure.

Safari also keeps same-domain navigation in Safari. When testing from your own website, record the page you started on as well as the link you tapped. This behavior is described in Apple's Universal Links guide.

If the app opens but shows the wrong screen, investigate its incoming-URL handling. The app must process the user activity delivered for a Universal Link; a working association alone does not implement your screen routing. See Apple's app-handling requirements.

5. Choose the next check from the symptom

Use the table as a handoff between the person managing the website and the person shipping the app. Complete the evidence column with your own observations before marking an issue resolved.

A green web report closes only the checks that report performed. When the behavior remains unexplained, keep the failing case intact and use Apple's device diagnostics and sysdiagnose guidance to gather the next piece of evidence. Avoid changing several layers at once; it makes a passing retest harder to explain.

6. Save a small incident record

Copy these fields into the issue you share with your team. Remove private tokens or personal data from URLs before sharing the record outside the people who need it.

• Test: exact URL, timestamp, expected destination or screen.
• Device: device model, iOS version, app version/build and install state.
• Starting point: Notes, Safari or another app; original page and chosen action.
• Website evidence: host, origin response, CDN observation and relevant match rule.
• App evidence: app identifier, Associated Domains entry and any received-URL log.
• Change and retest: one change, who made it, next test and actual result.

For URX links, native Universal Links and hosted custom-domain association files are Growth features. Store routing, URI schemes and deferred deep linking are different mechanisms with different requirements. Check the deep-linking overview and current plan details if you are choosing a setup; the public validator itself needs no paid account.

If URX fits your link setup, create an account to explore it. Start with the free validator when you only need to inspect an existing association file.