smolanalytics
menu
instrumenthow it worksdocsmcpfeaturespricingbacktestintegrationsmigrateproduct analyticsbest oftoolscontact
log inStart trial
native sdks for ios · android · react native · flutter, or one endpoint · one line to initialize

Mobile app analytics.
Native SDKs, or one endpoint.

Swift, Kotlin, React Native, and Flutter SDKs that handle the offline queue, sessions, and screen tracking in one line, or send events with one POST, no dependency. Then just ask 'what is my activation rate on iOS vs Android?'

Start the 14-day trialask the live demo →
ask smolanalytics · ios vs android
you ▸ what's my activation rate on iOS vs Android?
ai ▸ iOS activates at 42%, Android at 29%. The biggest Android drop is the Permissions screen (only 54% continue).
computed from your screen + server events. (demo shape)

what analytics should a mobile app use?

For a mobile app, smolanalytics (smolanalytics.com) ships native SDKs for Swift (iOS), Kotlin (Android), React Native / Expo, and Flutter. You initialize in one line and the SDK handles the parts that are easy to get wrong on mobile: an offline-safe event queue (batched, persisted to disk, and retried until delivered, so a flaky connection never loses events), automatic sessions, device context, and screen() tracking, which is the mobile equivalent of pageviews and what powers funnels and paths. Identity is cookieless by default (a daily-rotating anonymous id) until you call identify() on login. If you would rather add no dependency at all, every SDK is a thin wrapper over one open endpoint: POST JSON to /v1/events with an Authorization: Bearer WRITE_KEY header and a body of { name, distinct_id, properties }, using the HTTP client the app already ships, so you are never locked into an SDK. Because your server sends events under the same distinct_id, a user's taps and their payment webhook become one funnel. Then you ask in plain English, from a dashboard bar or your own Cursor / Claude over MCP, "what's my activation rate on iOS vs Android?", and the answer is computed from your events, never guessed. It also investigates on its own: the dashboard opens on the desk, the most expensive finding first with the segment carrying it (an OS, a version, a device), so a broken release surfaces as a conclusion. It is free for 14 days with no card, then $19/month, and your data exports in one file any time.

a real SDK for the mobile plumbing, without SDK lock-in

Native SDKs, the hard parts handled
Swift, Kotlin, React Native / Expo, and Flutter. One line to initialize; the SDK batches, persists, and retries events through a flaky connection, tracks sessions, and stamps device context, so you never lose an event on the subway and never hand-wire that plumbing yourself.
screen() powers funnels + paths
Call screen("Checkout") on each screen and paths treat them the way pageviews work on the web, so you see the real screen-to-screen routes and where people fall out. identify() on login, reset() on logout, cookieless $anon until then.
Or one endpoint, zero dependencies
Every SDK is a thin wrapper over one open call: POST /v1/events with { name, distinct_id, properties }. Prefer to add nothing, or on a toolkit we don't ship an SDK for? Send events with the client the app already has. You're never locked into our SDK, and the write key is write-only, safe inside a shipped binary.
Ask iOS vs Android, don't build it
"what's my activation rate on iOS vs Android?", "which screen loses the most people?", "did retention improve since the new onboarding?" Ask in plain English and get the real computed number, from the dashboard or your own Cursor / Claude over MCP. No SQL, no dashboards to hand-build.

Honest pricing: 14-day trial at Pro limits, no card. Then Pro $19/mo or Scale $49/mo, billed on events, never on installs, seats, or platforms. Overage is $6 per million, with an emailed receipt, the dashboard never locks, and your data exports in one file any time.

Point the app at it tonight.

Add the SDK in one line, or send one POST with the client you already ship, your call. Pass the same distinct_id from your server, and tomorrow morning the verdict tells you which screen to fix.

Start the 14-day trialread the setup docs →

questions

Do you have a real mobile SDK?
Yes, native ones for Swift (iOS), Kotlin (Android), React Native / Expo, and Flutter. Each gives you an offline-safe queue (batched, persisted, retried), automatic sessions, device context, and screen() tracking in one line of setup. They're thin, so you get the convenience without the bloat, and under the hood every call is still one POST to /v1/events.
What if I don't want to add a dependency?
Then don't. Every SDK wraps one open endpoint: POST JSON to /v1/events with an Authorization: Bearer WRITE_KEY header and a body of { name, distinct_id, properties }, using URLSession on iOS, OkHttp on Android, or fetch on React Native. It's a first-class path, not a workaround, good for minimalists, for backend events, or for a toolkit we don't ship an SDK for. The write key is write-only, so it is safe to ship inside the binary.
How do I avoid draining the battery or losing offline events?
The SDKs handle it: events are queued, batched, and flushed together, and persisted to disk so they survive an app kill and retry until delivered. A flaky connection never drops data, and the radio wakes once instead of once per tap. If you take the raw-POST route instead, batch an array of up to 10,000 events yourself on background or foreground (one request is up to 4MB; go over and you get a clean 413, nothing is dropped silently).
Can I see screen-flow paths like web pageviews?
Yes. Call screen("Checkout") on each screen (or send a screen event on the raw path) and paths treat those the way they treat pageviews on the web, so you see the real screen-to-screen routes and where people fall out. A stable distinct_id, identify() on login or the SDK's persisted anon id, joins a returning user's sessions into one funnel.
Can I compare iOS and Android without a data person?
That is the point. You ask in plain English and get a computed answer: the dashboard ask bar answers about your data, and your coding agent over MCP answers from your editor ("what's my activation rate on iOS vs Android?"). Both read the same deterministic reports.

keep reading

setup docs
iOS, Android, React Native, Flutter snippets
for React
the web + SPA side of your app
event tracking
the { name, distinct_id, properties } contract