LaunchLint Academy

The short answer
- Universal Links and Android App Links connect HTTPS URLs to a verified app domain. They are more robust than freely claimable custom schemes, but they do not replace validation of the incoming route.
- Treat every link as untrusted input: parse strictly, allow known destinations only, require authentication and confirmation for sensitive actions, and keep website files, app configuration, and release identity aligned.
- This checklist is not a one-time content exercise. Run it before the first store upload, after relevant dependency or configuration changes, and again immediately before release. Engineering, product, and the person controlling the store console must assess the same build. Static repository signals are valuable because they are reproducible, but they do not prove runtime behavior or backend responses. Combine them with tests of the signed artifact, official store declarations, and a recorded release decision.
1. Inventory links and threats
List schemes, domains, hosts, paths, parameters, and actions, marking login, payment, deletion, invitations, and password reset as sensitive.
Treat inventory links and threats as a reviewable property of the exact release candidate. Link the decision to the responsible file, store field, or reproducible device test. Record expected and observed behavior separately, assign an owner, and stop publication while a security or review contradiction remains unresolved.
Release review evidence
- Production state for inventory links and threats identified
- Affected project file or store setting linked
- Check repeated on a clean device
- iOS and Android differences recorded
- Every open question has an owner and date
- Evidence contains no secrets or personal test data
2. Establish domain trust
Apple Associated Domains and Android intent filters must reference a controlled HTTPS domain and the correct production identity.
Treat establish domain trust as a reviewable property of the exact release candidate. Link the decision to the responsible file, store field, or reproducible device test. Record expected and observed behavior separately, assign an owner, and stop publication while a security or review contradiction remains unresolved.
Release review evidence
- Production state for establish domain trust identified
- Affected project file or store setting linked
- Check repeated on a clean device
- iOS and Android differences recorded
- Every open question has an owner and date
- Evidence contains no secrets or personal test data
3. Publish association files
AASA and `assetlinks.json` need correct content, reliable HTTPS delivery, matching app or signing data, and understood caching.
Treat publish association files as a reviewable property of the exact release candidate. Link the decision to the responsible file, store field, or reproducible device test. Record expected and observed behavior separately, assign an owner, and stop publication while a security or review contradiction remains unresolved.
Release review evidence
- Production state for publish association files identified
- Affected project file or store setting linked
- Check repeated on a clean device
- iOS and Android differences recorded
- Every open question has an owner and date
- Evidence contains no secrets or personal test data
4. Validate input strictly
Use platform URL parsers, normalize host and path, reject unknown parameters, and allowlist reachable screens.
Treat validate input strictly as a reviewable property of the exact release candidate. Link the decision to the responsible file, store field, or reproducible device test. Record expected and observed behavior separately, assign an owner, and stop publication while a security or review contradiction remains unresolved.
Release review evidence
- Production state for validate input strictly identified
- Affected project file or store setting linked
- Check repeated on a clean device
- iOS and Android differences recorded
- Every open question has an owner and date
- Evidence contains no secrets or personal test data
5. Protect sensitive actions
A link must not independently trigger payment, deletion, email change, or privilege; check session, server state, and explicit confirmation.
Treat protect sensitive actions as a reviewable property of the exact release candidate. Link the decision to the responsible file, store field, or reproducible device test. Record expected and observed behavior separately, assign an owner, and stop publication while a security or review contradiction remains unresolved.
Release review evidence
- Production state for protect sensitive actions identified
- Affected project file or store setting linked
- Check repeated on a clean device
- iOS and Android differences recorded
- Every open question has an owner and date
- Evidence contains no secrets or personal test data
6. Design fallbacks and failures
Define behavior without the app, with expired tokens, the wrong account, offline state, and unsupported app versions.
Treat design fallbacks and failures as a reviewable property of the exact release candidate. Link the decision to the responsible file, store field, or reproducible device test. Record expected and observed behavior separately, assign an owner, and stop publication while a security or review contradiction remains unresolved.
Release review evidence
- Production state for design fallbacks and failures identified
- Affected project file or store setting linked
- Check repeated on a clean device
- iOS and Android differences recorded
- Every open question has an owner and date
- Evidence contains no secrets or personal test data
7. Separate staging and production
Test domains, bundle IDs, package names, and signatures must not claim production links or share actionable tokens.
Treat separate staging and production as a reviewable property of the exact release candidate. Link the decision to the responsible file, store field, or reproducible device test. Record expected and observed behavior separately, assign an owner, and stop publication while a security or review contradiction remains unresolved.
Release review evidence
- Production state for separate staging and production identified
- Affected project file or store setting linked
- Check repeated on a clean device
- iOS and Android differences recorded
- Every open question has an owner and date
- Evidence contains no secrets or personal test data
8. Test the release matrix
Cover cold start, background, reinstall, browsers, messages, email, multiple apps, redirects, and old links on supported OS versions.
Treat test the release matrix as a reviewable property of the exact release candidate. Link the decision to the responsible file, store field, or reproducible device test. Record expected and observed behavior separately, assign an owner, and stop publication while a security or review contradiction remains unresolved.
Release review evidence
- Production state for test the release matrix identified
- Affected project file or store setting linked
- Check repeated on a clean device
- iOS and Android differences recorded
- Every open question has an owner and date
- Evidence contains no secrets or personal test data
Frequently asked questions
Are Universal Links automatically secure?
They verify domain-to-app association, not the authorization or intent of a route.
Should custom URL schemes be removed?
Prefer verified HTTPS links for web content. Remaining schemes need strict validation.
Can a magic link sign in immediately?
Use a short-lived, one-time, server-validated token bound to the intended operation; sensitive follow-up actions need more control.
Can LaunchLint open every link?
No. It reviews configuration statically; devices, browsers, and backends require runtime tests.