Migration

Moving to WarpLink brings deep linking, install attribution, and analytics into one service. The steps are the same regardless of where you are coming from: recreate your links, swap the SDK, point your app association files at WarpLink, then cut over on your own schedule.

Choose Your Guide

Each provider has its own concept mapping and shutdown timeline. Start with the one that matches your current setup, then come back here for the general playbook.

Guide	What it covers
Firebase Dynamic Links	Concept mapping, link recreation, and SDK setup after Firebase Dynamic Links shut down
Branch	Mapping Branch links and parameters to WarpLink, and swapping the Branch SDK
AppsFlyer OneLink	Mapping OneLink templates to WarpLink links, and swapping the AppsFlyer SDK
Adjust	Mapping Adjust links and trackers to WarpLink, and swapping the Adjust SDK
Kochava	Mapping Kochava trackers and links to WarpLink, and swapping the Kochava SDK
Airbridge	Mapping Airbridge links and trackers to WarpLink, and swapping the Airbridge SDK

Coming From Another Setup

Don't see your provider above? The playbook below is written to work for any setup: another attribution or deep linking provider, a URL shortener with a deep link feature bolted on, or Universal Links and App Links you built and maintain yourself.

The general shape is the same in every case:

• Map your concepts. Whatever you call a "link," "tracker," or "campaign" today, it becomes a WarpLink link. Whatever destination, fallback, and social preview fields your current setup exposes, find their equivalents among WarpLink's link fields.
• Recreate your links using step 3 below: dashboard, REST API, or MCP server.
• Swap the SDK using step 4: remove your current provider's initialization and deep link handling, add the WarpLink SDK's configure() call with an onLink callback.
• Point your app association at WarpLink using step 5, including the SDK-level domain declaration if you're moving to a custom domain.
• Cut over and verify using steps 6 and 7.

If your current setup has no deep linking at all, hand-rolled or otherwise, start at Set Up WarpLink and work through the same playbook from step 3 onward.

Before You Start

Take an inventory before you touch any code:

• Links. Every link your provider serves today: destination, fallback URLs, and any social preview or UTM data attached to it.
• Domains. The domain each link lives on, and whether it is the provider's default domain or one you own.
• SDK integration points. Where your app calls the provider's SDK today: app launch, deep link handling, and any deferred deep link check.
• Attribution consumers. Who reads your attribution data today, such as a marketing dashboard, a spreadsheet export, or an internal report, so you know what to reconnect after the switch.

The Migration Playbook

1. Set Up WarpLink

Create an account, register your app, and generate an API key. The quickstart walks through all three in order: organization signup, app registration (iOS bundle ID, Android package name, or both), and your first link.

2. Plan Your Domains

Serve new links from your app's own subdomain (yourapp.aplnk.to) or your own custom domain, and you own the link path from day one.

A custom domain you already own is different: once your links are recreated in WarpLink with the same paths, you can repoint the domain's DNS to WarpLink and every existing share link, QR code, and bookmark keeps working.

3. Recreate Your Links

Recreate each link in WarpLink with the same destination and platform behavior. Three ways to do it:

• Dashboard. Create or edit links one at a time at dash.warplink.app.
• REST API. Script the migration with POST /v1/links against the Links API, one request per link.
• MCP server. Point an AI tool such as Claude Code or Cursor at the MCP server and describe the links you need created.

Custom slugs are 2 to 100 characters, lowercase alphanumeric with hyphens (see Short Links). If your provider's slugs do not fit that pattern, decide on a mapping before you start scripting.

4. Swap the SDK

Replace the provider's SDK with the WarpLink SDK for each platform your app supports:

• iOS: WarpLink.configure(apiKey:options:) with an onLink callback, then forward Universal Links via WarpLink.continue(_:) / WarpLink.open(_:) (or the drop-in WarpLinkSceneDelegate) for cold and warm start.
• Android: WarpLink.configure(context, apiKey, options) with an onLink callback; cold start is automatic, and warm start forwards via WarpLink.onNewIntent(intent).
• React Native: WarpLink.configure(options) with an onLink handler; on iOS, the AppDelegate forwards Universal Links via WarpLinkModule.handleIncomingURL(url), and Android needs no host code beyond android:launchMode="singleTask".
• Flutter: await WarpLink.configure(...) with an onLink handler; cold start and warm start arrive there with no host code.

Once onLink is set, cold start, warm start, and deferred results all arrive through it automatically. The method names above are the forwarding calls each platform needs, not a manual sequence you call by hand. See Deferred Deep Links for how the match works, or call checkDeferredDeepLink() directly if you need to run the check yourself.

5. Update App Association

Deep links only open your app if the operating system trusts the domain:

• iOS. Add the domain to the Associated Domains entitlement (applinks:yourapp.aplnk.to, or your custom domain).
• Android. Add the domain to the App Links intent filter, with android:autoVerify="true".

WarpLink hosts and serves the association files (apple-app-site-association and assetlinks.json) for every app subdomain (yourapp.aplnk.to) and every verified custom domain automatically. There is nothing to upload or regenerate on your side.

If you're moving to a custom domain, also declare it to the SDK: linkDomains at configure(), or the WarpLinkDomains plist key / app.warplink.DOMAINS manifest entry. Declaring the domain lets the SDK resolve links on it from the very first launch. See Use it in your app.

6. Run the Cutover

Ship the app update with the WarpLink SDK and the updated app association entries. Keep the old provider live and serving its existing links until enough users have updated, so users on the old app version do not lose deep linking. Once adoption is high enough, move your custom domain's DNS to WarpLink and retire the provider's links.

7. Verify

Before you decommission anything, confirm on each platform:

• The SDK initializes and reports a successful configuration.
• A WarpLink link opens the app on cold start (app not running) and warm start (app in background).
• A deferred deep link (click, then install) resolves after first launch.
• Install attribution appears in the dashboard for a fresh install, not just a deep link open.
• Click analytics record the tap that drove the install.
• The association files resolve: curl https://yourdomain.com/.well-known/apple-app-site-association and curl https://yourdomain.com/.well-known/assetlinks.json.

8. Decommission the Old Provider

Once verification passes and old-app-version traffic has dropped to a level you are comfortable with, remove the provider's SDK, delete its configuration files, and cancel or downgrade its subscription.

Compare Providers

• Branch alternative
• AppsFlyer alternative for small teams
• Adjust alternative for small teams
• Kochava alternative for small app teams
• Firebase Dynamic Links alternative

Next Steps

• Quickstart: create your first link and get an SDK key.
• iOS SDK, Android SDK, React Native SDK, and Flutter SDK: full setup and API reference.