> ## Documentation Index > Fetch the complete documentation index at: https://learn.biq.li/llms.txt > Use this file to discover all available pages before exploring further. # Mobile deep-link quickstart > Configure a domain, Mobile App, short link, and SDK for verified mobile deep linking. Mobile deep linking is in **Public Beta**. Complete the store-install tests in [Testing and troubleshooting](/developers/mobile/testing-troubleshooting) before production use. This procedure creates one verified HTTPS link that can open your installed app and preserve attribution through a supported store install. ## Before you begin You need: * workspace owner access; * a custom domain with verified DNS and active HTTPS in Biqli; * the iOS bundle ID and ten-character Apple Team ID for iOS; * the Android package name and SHA-256 signing-certificate fingerprints for Android; * a public `apps.apple.com` URL for the Mobile App, an optional per-link TestFlight fallback for testing, and a Google Play URL for Android; and * an in-app route that your application can validate and handle. You may register iOS, Android, or both. At least one complete platform configuration is required. ## 1. Register the Mobile App Open **Workspace settings → Mobile Apps**, select **New Mobile App**, and enter: | Setting | Requirement | | :------------------------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | App name | A workspace-facing name for the app. | | Custom domains | From one to twenty domains available to the workspace. Use verified domains with active HTTPS. | | Allowed paths | Up to fifty rules per domain, one per line and at most 500 characters each. A rule starts with one `/`, contains no query or fragment, and may end in `*`. Use `/*` only when the app should handle every short-link path on the hostname. | | Apple Team ID | Exactly ten uppercase letters or digits. Required with the iOS bundle ID. | | iOS bundle ID | The exact app target bundle identifier. | | App Store ID | Optional numeric store identifier. | | App Store URL | Required when iOS is configured. Use the public App Store URL. | | Android package | The exact application ID. | | SHA-256 fingerprints | One to twenty uppercase, colon-separated signing-certificate fingerprints. | | Google Play URL | Required when Android is configured; its `id` must equal the Android package. | | Exact handoff lifetime | From 15 to 10,080 minutes. The default is 1,440 minutes. | | Probabilistic iOS fallback | Off by default. Enable only after privacy review and consent design. | Save the app, then copy its `biq_mapp_...` app ID and `biqli_mobile_pk_...` mobile publishable key. The key is public and app-scoped, but you should still avoid posting it outside the application and documentation where it is needed. ## 2. Publish and inspect association files Biqli can generate both files from the active Mobile Apps attached to the exact hostname: ```text theme={null} https://go.example.com/.well-known/apple-app-site-association https://go.example.com/.well-known/assetlinks.json ``` Open the Mobile App detail page and use **Preview association files**, then **Verify public files**. Each URL must return the canonical JSON directly with HTTPS status `200`, an `application/json` content type, and no redirect. Generated mode is recommended. Custom mode replaces the generated JSON completely; Biqli does not merge custom entries with registered apps. Every exact hostname needs its own association file. ## 3. Configure the native application For iOS, add `applinks:go.example.com` to the target's **Associated Domains** capability and forward `NSUserActivityTypeBrowsingWeb` URLs to Biqli. See the [iOS SDK reference](/docs/api-reference/sdks/ios). For Android, add an HTTPS `VIEW` intent filter with `DEFAULT`, `BROWSABLE`, and `android:autoVerify="true"` for the domain. See the [Android SDK reference](/docs/api-reference/sdks/android). Do not place a secret `biqli_...` workspace API key in either app. Native apps use only the Mobile App ID and `biqli_mobile_pk_...` key. ## 4. Configure the short link Create or edit a short link on the same custom domain and open **Mobile Deep Linking & Deep View**. 1. Enable **Mobile Deep Linking**. 2. Select the registered Mobile App. 3. Enter the in-app route, such as `/invite/accepted`. 4. Add an optional referral code and a safe metadata JSON object. 5. List only the dynamic query keys you intend to forward. 6. Optionally override the Mobile App's platform store fallback URLs for this link. 7. Enable **iOS Deep View** when you need exact iOS deferred attribution. 8. Save the link. The route must begin with `/`, contain no query or fragment, contain no double slash, and be no longer than 500 characters. Treat it as untrusted input in the app: map recognized routes to safe screens instead of executing arbitrary actions. Read [Configure mobile deep linking](/help/links/mobile-deep-linking) for every dashboard field and limit. ## 5. Install and configure an SDK Android: ```kotlin theme={null} dependencies { implementation("li.biq:biqli-android:1.0.0") } ``` iOS Swift Package Manager URL: ```text theme={null} https://github.com/BiqliLLC/biqli-ios.git ``` Select version `1.0.0` or later within the same major version. Configure the SDK once at application startup and pass incoming verified links through the platform lifecycle methods. Keep attribution non-blocking: an offline or transient failure can retry on a later cold launch. ## 6. Verify the result Test the installed-app path first. A successful request returns `matchedBy: exact_app_link`, the configured route, and the link attribution. Then perform the real deferred-install tests through Google Play and TestFlight. Success means: * the operating system opens the installed app for the verified hostname; * a device without the app reaches the correct store; * the first launch can return the expected exact deferred match after the required handoff; * the app routes only recognized paths; * the backend verifies a signed attribution receipt before granting a reward; and * Mobile App analytics show the new resolution event. ## External platform references * [Google Play Install Referrer](https://developer.android.com/google/play/installreferrer) * [Verify Android App Links](https://developer.android.com/training/app-links/verify-applinks) * [Apple: Supporting associated domains](https://developer.apple.com/documentation/xcode/supporting-associated-domains) * [Apple: Supporting Universal Links in your app](https://developer.apple.com/documentation/xcode/supporting-universal-links-in-your-app)