SDKs

Open source SDKs for iOS, Android, and React Native

WarpLink ships three open source SDKs, for iOS, Android, and React Native, each MIT licensed with zero third-party dependencies and a single configure() call that wires up deep links, deferred deep links, and install attribution. Deep linking, install attribution, and real-time analytics all come from that one integration, on every platform you ship, instead of from separate SDKs you would have to keep in step.

Start building, freeSDK documentationPricing

One SDK per platform

How the deep linking SDKs work

  1. Install

    Add the SDK the way you already add dependencies: Swift Package Manager on iOS, Maven Central on Android, npm on React Native. Every package is MIT licensed with zero third-party dependencies, so nothing else enters your build. A React Native app installs one package that bridges to both native SDKs.

  2. Configure

    Call configure() once, as early in the app lifecycle as you can, with your SDK key and an onLink callback. That single call wires up cold start, warm start, and the deferred deep link check on first launch. Each of the three is opt-out with a flag when you would rather drive the flow yourself.

  3. Handle the link

    Your onLink callback receives every resolved link, whether the tap opened an app that was already installed or the link survived a store install. Check isDeferred to tell those two apart, then route to the screen the link named. The attribution result, with its match type and confidence score, lands on the same first launch.

One SDK call

iOS (Swift)
import WarpLink

WarpLink.configure(
    apiKey: "wl_live_xxx",
    options: WarpLinkOptions(onLink: { result in
        guard case .success(let deepLink) = result, let deepLink else { return }
        navigate(to: deepLink.destination)
    })
)
Android (Kotlin)
WarpLink.configure(
    context = this,
    apiKey = "wl_live_xxx",
    options = WarpLinkOptions(onLink = { result ->
        result.onSuccess { deepLink -> navigateTo(deepLink.destination) }
        result.onFailure { error -> Log.e("WarpLink", error.toString()) }
    })
)
React Native
import { WarpLink } from '@warplink/react-native'

WarpLink.configure({ apiKey: 'wl_live_xxx' })

WarpLink.onDeepLink((event) => {
    if (event.deepLink) {
        navigation.navigate(event.deepLink.destination)
    }
})
Open source SDKs·Sub-10ms redirects·Never blocked·MCP server, free on all plans

Frequently Asked Questions

Yes. All three are MIT licensed, and the full source of each one lives in a public repository under the WarpLinkApp organization on GitHub, so you can read every line before you ship it, fork it, or send a fix back. Nothing about how a link resolves or how an install is matched sits hidden inside a binary.

All SDKs are under 200KB gzipped with zero third-party dependencies. The iOS SDK is distributed via SPM, Android via Maven Central, and React Native via npm. Each is MIT licensed so you can inspect every line.

Yes, with a development build. The SDK ships native modules, which Expo Go cannot load, so install it with expo install, run expo prebuild, then declare the associated domains and the intent filter in app.json. There is no WarpLink config plugin, and a clean prebuild, or any build that starts without an ios directory, writes the AppDelegate from the template, so add the iOS delegate calls from your own config plugin with withAppDelegate to keep them.

No. Install only the SDK for each platform you ship: a React Native app installs a single package that bridges to both native SDKs, so it does not need the iOS and Android packages as well. One app in WarpLink holds the iOS and the Android configuration together, so shipping on both platforms still uses a single app from your plan. The plan limits are at warplink.app/pricing.

The signals attribution needs, and nothing more. On first launch it sends the device language and timezone, plus the vendor identifier (IDFV) on iOS or the Play Install Referrer on Android, all over HTTPS. It collects no advertising identifier, no location, no contacts, no app usage, no user agent, and no screen dimensions, and the address the request came from is read server-side rather than sent by the SDK.

Related guides

Your links should open the app.
Your data should tell you why.

Set up deep linking, attribution, and analytics in minutes. Free to start.

Start building, free

Have a question?