What this prompt does
This prompt builds a complete deep linking system for an iOS and Android app, including the cases that usually break. It covers six steps: defining the URL scheme, configuring iOS Universal Links, configuring Android App Links, implementing deferred deep linking for users without the app, building a testing matrix, and wiring up attribution. The structure forces you to handle the app-not-installed and unauthenticated paths instead of assuming the happy case, which is where most deep linking work actually goes wrong.
The variables ground the system in your app. [link_count] and [custom_scheme] plus [domain] define the URI structure, [app_store] and [deferred_link_provider] shape the deferred flow, and [storage_method] decides how the deferred payload survives install. [test_count] sizes the test matrix, [analytics_platform] receives debug and attribution events, and [conversion_event] is what attribution ultimately measures. Because the AASA and assetlinks files must match [domain] exactly, getting these values precise is not optional.
When to use it
- You are adding deep links to a mobile app and need both iOS and Android handled correctly.
- You keep hitting issues when the app is not installed and the link should still work after install.
- You need authenticated content to resolve deep links only after login.
- You want the AASA and assetlinks.json files and intent filters set up properly.
- You need a test matrix covering foreground, background, killed, and uninstalled states.
- You want campaign attribution that traces an install back to its source link.
Example output
Expect a link registry table mapping patterns to screens, required params, optional params, and fallback URLs. The platform steps produce an AASA file plus Associated Domains setup for iOS, an assetlinks.json file plus autoVerify intent filters for Android, and handler code that parses incoming URLs. Later steps add a deferred deep linking flow using [deferred_link_provider], a test matrix of [test_count] scenarios, and an attribution plan feeding [analytics_platform]. It blends config files, handler code, and tables, with each platform's verification requirements spelled out so you know exactly which file goes where and how it is fetched by the operating system.
Pro tips
- Define
[custom_scheme]and[domain]precisely; the AASA and assetlinks files must match your real domain exactly or verification silently fails with no obvious error. - Keep the link registry for all
[link_count]destinations explicit about required vs optional params and fallback URLs. - Don't skip the deferred path; choose a
[deferred_link_provider]and[storage_method]deliberately, since clipboard plus server-side matching has known reliability tradeoffs. - Run the full
[test_count]matrix rather than spot-checking; deep linking bugs hide in the killed-app and unauthenticated states. - Make sure UTM parameters flow through to
[analytics_platform]so[conversion_event]attribution is actually traceable. - Test on real devices, since app-link verification behaves differently than emulators in some cases and can mask failures.
