∧pex

Which SDK do I need?

Apex Mobile ships with separate SDKs for different app frameworks. The Capacitor plugin pairs with the existing apex.js web snippet to give you "one mental model, one dashboard" for web + Capacitor apps. Other frameworks need their own native wrappers.

The decision matrix

Your appInstallGitHubNotes
Web (browser, PWA, landing pages)apex.js snippetapex-incorporated/apex-jsAlready live — you're using it if you've installed the Apex tracking snippet.
Capacitor (iOS + Android)@apex-inc/capacitor-pluginapex-incorporated/capacitor-pluginRecommended for hybrid apps. Pairs with apex.js in the WebView — shared visitor ID + session + events.
React Native@apex-inc/react-nativeComing Phase 9On the roadmap. Raise in Discord if you need it sooner.
Native iOS (pure Swift / SwiftUI)ApexMobile Swift PackageComing Phase 9On the roadmap.
Native Android (pure Kotlin / Compose)inc.apex:mobile Maven packageComing Phase 9On the roadmap.
Flutter—PlannedRaise in Discord — would ship as apex_mobile on pub.dev.
Xamarin, Cordova, Ionic (non-Capacitor)HTTP events API directly—Hit POST /api/events from your code. No SDK abstraction yet.

Why so many SDKs?

Each platform has its own native APIs that Apex needs to read to do attribution correctly:

  • iOS: IDFA (via ATT), IDFV fallback, SKAdNetwork postbacks, Universal Links, APNS push tokens.
  • Android: Google Advertising ID, Play Install Referrer, App Links, FCM push tokens.
  • Web: navigator.userAgent, cookies, window.location, URL parameters.

A single cross-platform SDK can't express all of these — it'd either miss features on every platform or bloat every app with unused code. The answer is thin per-platform wrappers that share the same backend event shape.

The "unified snippet" promise — what it does and doesn't mean

You may see Apex marketing say "drop in apex.js, add the Capacitor plugin, same events, same dashboard." That's accurate specifically for web + Capacitor. Here's the precise scope:

Info

apex.js (the web snippet) works seamlessly inside Capacitor WebViews. When both apex.js and the Capacitor plugin are loaded, they share the same visitor ID, the same session, and events flow through one pipeline. You get unified analytics across your marketing site and your mobile app.

apex.js alone is NOT enough for Capacitor apps. The plugin is still required for IDFA, install referrer, SKAN, universal links, push tokens — anything that needs native OS access. Install the plugin alongside apex.js.

Not covered by the "one snippet" claim:

  • React Native, Flutter, native iOS/Kotlin — these don't have a JS engine in the same way, so there's no apex.js to load. They need their own native SDK.
  • Framework-less apps using fetch to hit the events API directly — you pick your own integration layer.

The Capacitor footgun

A Capacitor app that has apex.js loaded in the WebView but no @apex-inc/capacitor-plugin installed is the single most common setup mistake. Symptoms:

  • Events arrive on the server but platform is "web" instead of "ios" / "android".
  • No IDFA, no GAID, no install referrer — attribution falls back to UTM params only.
  • The Sensors page shows a yellow "Capacitor plugin not detected" warning on the Apex Mobile card.

The fix is always: npm install @apex-inc/capacitor-plugin and call Apex.initialize() at app startup. See Getting Started for the five-minute walkthrough.

Attribution waterfall

No matter which SDK you use, the attribution engine runs the same four-tier waterfall on every install. From most to least reliable:

Deterministic — click ID match (confidence 1.0)

Play Install Referrer (Android) or deferred deep link URL (iOS) contains a recognized click ID: gclid, fbclid, ttclid, msclkid, li_fat_id, wbraid, gbraid, epik, rdt_cid, or twclid. This is the gold-standard match — any network-first attribution is built on top of this.

Device ID (confidence 0.95)

IDFA (iOS with ATT authorized) or GAID (Android without LAT) matches a known ad-click event within the click-through window (default 7 days). Common for retargeting flows where the user clicked a remarketing ad.

Probabilistic fingerprint (confidence 0.40 – 0.80)

IP + user-agent + time-in-window + geo consistency score the install against recent ad clicks. Used when deterministic + device ID both fail but UTM or other signals suggest a match. Confidence varies based on how many signals agree.

Organic (confidence 0)

No click match inside any window. The install is attributed to the UTM source if one is present (e.g. utm_source=newsletter), otherwise marked fully organic. Soft-organic installs still appear in cohort retention + LTV reports.

Reattribution (re-install within 90 days of a prior install) and reengagement (return after 30+ days inactive) are checked before the waterfall runs — see the attribution deep dive for details.

Next steps

PreviousGetting StartedNextOverview