linkrunway.
Implementation guide

Give your app a destination.

Set up domain associations and link handling on each platform.

Get started
A person working on a laptop at a café table
The essentials

Register your app identifiers and signing details, verify the HTTPS link domain, and add the platform association settings to your app. Resolve incoming links with the native SDK and navigate using the returned app path.

Before you begin.

  • An HTTPS link domain with verified ownership
  • Your iOS team and bundle IDs or Android package and signing fingerprint
  • The Swift or Kotlin SDK from this monorepo

Give the app a verified domain.

Add the domain in Settings, publish its DNS verification record, and point it at the API through your HTTPS hosting setup. Register the app in Integrations with that domain.

  • iOS: inspect /.well-known/apple-app-site-association.
  • Android: inspect /.well-known/assetlinks.json.
  • Serve both files over HTTPS without authentication or a redirect.

Open the destination on iOS.

Add applinks:links.example.com to Associated Domains in Xcode. Handle the incoming browsing activity or SwiftUI onOpenURL, then resolve the URL and navigate using a validated app path.

Swift · inside your link handler
let runway = LinkRunway(
  endpoint: URL(string: "https://links.example.com")!,
  publishableKey: "lr_pk_your_publishable_key"
)
// Only after your consent flow grants collection.
await runway.setConsent(true)
if let destination = try await runway.open(incomingURL) {
  // Allowlist destination.path, then navigate in your app.
}

Verify the link on Android.

Add an autoVerify intent filter for the HTTPS host. Use the SHA-256 certificate of the distributed app, then resolve incoming intents from a coroutine.

AndroidManifest.xml · activity intent filter
<intent-filter android:autoVerify="true">
  <action android:name="android.intent.action.VIEW" />
  <category android:name="android.intent.category.DEFAULT" />
  <category android:name="android.intent.category.BROWSABLE" />
  <data android:scheme="https" android:host="links.example.com" />
</intent-filter>

Test the journey after installation.

Use the Android SDK’s install helper for Play Install Referrer after consent. For explicit referral recovery, create a code before installation and claim it in the app with a stable UUID. iOS matching is not automatic.

  • Installed app: confirm the intended screen opens.
  • Uninstalled app: confirm the store or web fallback works.
  • Consent denied: confirm no attribution token is persisted.
  • Repeat open or claim: confirm retries do not create another install or claim.

Find the missing connection.

iOS opens Safari

Check the entitlement, team ID, bundle ID, domain file, and device association cache.

Android does not verify the link

Compare assetlinks.json with the package and Play App Signing certificate of the installed build.

No post-install context

Test an actual Play install referrer or explicit code claim. A simulator build is not a store-install test.

Platform references.

Reviewed October 10, 2026 · LinkRunway documentation

A little clarity

Good questions.
Clear answers.

Why does an installed app still open the browser?

Check your domain’s association file, app identifiers, signing certificate, and app entitlement or manifest. OS verification can be cached, so retest after reinstalling on a physical device.

Which Android signing fingerprint should I use?

Use the SHA-256 fingerprint of the certificate signing the installed app. For Play-distributed builds with Play App Signing, this is the app signing certificate, not necessarily the upload certificate.

Can I claim a referral without consent?

No. Referral-code creation and claiming require explicit consent. Keep the claim UUID stable across retries to avoid competing claims.

See the platform
Your next chapter

Let’s see where
a little link takes you.

Start for free Explore pricing