Deep Link Setup
A deep link opens a specific screen of the app from a URL outside it, such as a link in a message or a tapped push notification. You set it up once, in the
native section of akan.config.ts: deepLinks names the links, and ios and android hold what verifies a domain.Two Kinds Of Link
Deep link is the feature;
schemes and domains are the two usual ways to build it. You can declare both:Scheme link ·
schemesshop://orders/1An app-only link. It needs no verification, so it is the easy one to test during development.
Domain link ·
domainshttps://shop.example.com/orders/1Works like a normal web link but needs iOS and Android verification. Best for sharing, email and push URLs.
Declare It
Write
deepLinks in native, and the values that verify a domain in its ios and android sections:apps/myapp/akan.config.ts
- Every target takes them. A target that sets
schemesordomainsreplaces that list; it does not add to it. - Hosts only in
domains. Writeshop.example.com; anhttps://or a path you add is dropped. ios.teamIdandandroid.sha256CertFingerprintsservedomains. If you only use scheme links, leave both out.- Rerun the app to apply. After a change, run
akan start-iosorakan start-androidagain.
Where A Link Lands
A scheme link, a domain link and a push notification's
data.url all open the same CSR route:Incoming linkWhat it opens
shop://orders/1
Scheme link.
orders becomes the first path segment, so it opens /orders/1.https://shop.example.com/orders/1
Domain link. The path is used as is and opens
/orders/1.data.url = "/orders/1"
A tapped push notification. It opens
/orders/1 the same way.Back works after a cold start. When a link launches the app, the parent screen or the start screen is stacked first, so back stays inside the app.
Link Fields
Every field is optional. Each platform reads only what it needs, so declare only what your link style requires:
deepLinks.schemesstring[]
App-only URL schemes, such as
shop in shop://orders/1.deepLinks.domainsstring[]
Hosts whose HTTPS links open the app once iOS and Android verify them.
ios.teamIdstring
Your Apple Developer Team ID. iOS uses it to verify
domains.android.sha256CertFingerprintsstring[]
SHA-256 fingerprints of the certificates that sign the app. Android uses them to verify
domains.What Each Link Style Needs
Scheme links need one field. Domain links need three, and each platform reads its own part:
Field
iOS
Android
Scheme links
deepLinks.schemes
✓
✓
Domain links
deepLinks.domains
✓
✓
ios.teamId
✓
android.
✓
✓Read by this platformNot read
Domain Verification
A domain link opens the app only after the platform confirms that the app belongs to the domain. It checks a file served from that domain:
- The Akan server serves both files. It answers
/.well-known/apple-app-site-associationand/.well-known/assetlinks.jsonfrom these fields, so point the domain at your app's server and redeploy it after a change. - iOS checks the Team ID and appId. The file lists
<teamId>.<appId>fromios.teamIdand the target'sappId, so both must be your real values. - Android checks the signing certificate. Debug and release builds are signed by different keys, so list both fingerprints.
- A debug build verifies only against a non-main server. Its package ends in
.debug, whichassetlinks.jsonlists only whenAKAN_PUBLIC_ENVis notmain. The debug key's SHA-256 must also be insha256CertFingerprints.
Getting The Android Fingerprint
Read it from the keystore that signs the build. Debug builds are signed with the runtime's own debug keystore, created by the first Android build:
Terminal
Release builds are signed with the upload key akan release-android reads from the environment:
Terminal
- With Play App Signing, add Google's key too. Play re-signs what you upload, so the installed app carries the app signing key: copy its SHA-256 from Play Console (Setup, App signing) and list it next to the upload and debug ones.
A domain link that fails verification opens in the browser, not the app. The fingerprint of the key that signed the installed build must be in the list.