SDKs
Traqio SDKs: which one, and what each does
Nine SDKs for iOS and Android apps, and a browser SDK plus Node.js, PHP and Python server SDKs for websites — and what each supports today.
A Traqio SDK is the library your app embeds so Traqio can attribute its installs and measure what happens after. Every SDK does the same three jobs: it reports the install once with the evidence its platform provides (the Google Play Install Referrer on Android, SKAdNetwork on iOS), it queues the events you track and sends them in batches that survive restarts and bad networks, and it resolves deep links from Traqio tracking links. None of them fingerprints the device, and none reads an advertising identifier unless you turn that on (iOS, Android and React Native for now).
Choose by how your app is built#
Use one Traqio SDK per app: two would each report the install and count every event twice.
For a website#
A website takes two SDKs, one per half: the browser SDK keeps the ad click id from the landing page to the sign-up form, and a server SDK on your backend reports the sign-up with it — web attribution explains the chain, and the web quickstart sets it up.
Each half takes its own key, never the app key: a public web key for the browser, a secret server key for the backend. Web events and server conversions are never attached to an app install.
What each SDK supports today#
Measured in each SDK's code, not promised. Once: the Install Referrer is read on first launch without the React Native SDK's retry when Google Play is momentarily unavailable — such an install is then reported organic. Host: supported, with your app passing the lifecycle event or the URL to the SDK (each SDK page shows the line). —: not applicable on that platform.
| RN / Expo | Android | iOS | Flutter | Capacitor | KMP | MAUI | Unity | |
|---|---|---|---|---|---|---|---|---|
| Android: Play Install Referrer | Yes | Yes | — | Once | Once | Once | Once | Once |
| iOS: SKAdNetwork registration | Yes | — | Yes | Yes | Yes | Yes | Yes | Yes |
| iOS: conversion values from your mapping | Yes | — | Yes | No | Yes | No | No | No |
| iOS: Apple Ads attribution | Yes | — | Yes | No | Yes | No | No | No |
| Events with value and currency | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes |
| Store transaction id on purchases | Yes | No | No | No | Yes | No | No | No |
| AdMob ad revenue | Yes | No | No | No | Yes | No | No | No |
| Deep links, direct and deferred | Yes | Yes | Host | Yes | Host | Host | Yes | Yes |
| App opens (retention) | Yes | Yes | Yes | Yes | Host | Host | Host | Yes |
| Ad-sharing consent | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes |
| In-app erasure (forgetMe) | Yes | No | No | No | Yes | No | No | No |
| Offline queue and retries | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes |
The React Native / Expo SDK is the most complete because it runs the shared JavaScript engine, @traqio/core, which also powers Capacitor. On the other SDKs, what is missing is missing in the app, not on the server: in-app erasure has a server-side equivalent, and revenue can always arrive through RevenueCat.
How far each SDK is proven#
A capability in the code is not the same as a capability seen working. This is the strongest evidence each SDK has today:
| SDK | Package | Registry | Proven |
|---|---|---|---|
| React Native / Expo | @traqio/react-native | npm | Verified on a device |
| Android | io.khufu.traqio:traqio-android | Maven Central | Compiled in CI |
| iOS | TraqioSDK | SPM / CocoaPods | Compiled in CI |
| Flutter | traqio | pub.dev | Type-checked in CI |
| Capacitor | @traqio/capacitor | npm | Type-checked in CI |
| Kotlin Multiplatform | io.khufu.traqio:traqio-kmp | Maven Central | Compiled in CI |
| .NET MAUI | Traqio.Maui | NuGet | Compiled in CI |
| Unity | app.traqio.sdk | UPM | No automated build yet |
“Verified on a device” means the full chain — a click on a tracking link, an install from Google Play, the Install Referrer read by the SDK, an install attributed deterministically — has been run end to end on a real Android runtime. “Compiled in CI” means the SDK's own toolchain builds it on every change, but no app has yet run it against production.
Early access
Supported today#
The app SDKs measure iOS and Android apps. Each targets the mobile platforms its framework builds for: a .NET MAUI or Kotlin Multiplatform project is measured on its Android and iOS targets, a Unity game on its Android and iOS builds. The web SDKs measure websites: @traqio/web in any browser, and the server SDKs on Node.js 18+, PHP 8.1+ (Laravel 12 and 13) and Python 3.9+.
Frequently asked questions#
- Which Traqio SDK should I use?
- The one that matches the language your app's startup code is written in: @traqio/expo for an Expo app, @traqio/react-native for a bare React Native app, the Kotlin SDK for a native Android app, TraqioSDK for a native iOS app, and the Flutter, Capacitor, Kotlin Multiplatform, .NET MAUI or Unity package for apps built with those. Use exactly one Traqio SDK per app.
- Do all the SDKs do the same thing?
- They share the same contract — report the install once, queue and retry events, resolve deep links, carry the user's consent — but not every capability. SKAdNetwork conversion values, Apple Ads attribution, store transaction ids, AdMob ad revenue and in-app erasure are complete in the React Native / Expo and Capacitor SDKs (and partly in the native iOS SDK); the matrix on this page lists each one.
- Can I use two Traqio SDKs in the same app?
- No. Two SDKs would each report the install and run their own event queue, so every install and event would be counted twice. @traqio/expo and @traqio/react-native are the same module under two names: install one of them.