AnalyticsDrop is screen-journey analytics for mobile apps. Add one line of code and watch every screen, path, and drop-off appear — no manual event tracking, and no user text ever stored.
One line to install · UIKit + SwiftUI · No credit card
Onboarding funnel · first session
Biggest drop: Sign up → Paywall (−25%)The problem
You wanted to know where users drop off. Instead you got a tracking plan, an event on every screen, and dashboards that are stale the moment you ship.
Every new screen means another event, another naming debate, another PR — or a gap in your funnel.
The screens you forgot to instrument are exactly the ones quietly losing you users.
Free-text properties and screen captures pull sensitive data into your analytics before anyone notices.
How it's different
AnalyticsDrop captures the screens your users actually see — so the map is complete on day one, not after months of tagging.
Auto-capture
Drop the SDK in, call start() once, and every screen view is captured automatically — UIKit and SwiftUI, side by side, in the app you already have.
import SwiftUI
import AnalyticsDrop
@main
struct PrimusApp: App {
init() {
// one line — every screen is now tracked
AnalyticsDrop.start(apiKey: "ad_live_9f2c…")
}
var body: some Scene {
WindowGroup { ContentView().analyticsDropTracked() }
}
}User timelines
Search a user and replay their exact path — every screen, in order, with how long they spent on each. Identify once and anonymous history stitches to the real account.
Living reports
Screen names live in one place. Rename a screen and it fixes your journey graph, funnels, and every user's history — retroactively, by design. Unnamed screens double as your setup checklist.
The same screen maps to one node across relaunches and rebuilds — even as its data changes.
Every screen shows its exit rate. Screens bleeding users get a red badge you can't miss.
Your onboarding path is found for you, with per-step conversion and the biggest drop called out.
Slice by date range, first session only, and app version to compare releases.
Fire a one-line track() for purchases and key actions, tied back to the journey.
Sub-millisecond hook, work off the main thread, batched uploads. Your users never feel it.
How it works
Add the package and call start(apiKey:) at launch. That's the whole integration.
Your users' screens flow in automatically — captured, fingerprinted, and ordered.
Open the journey graph, spot the red exit badges, and fix the step that's leaking users.
AnalyticsDrop measures the shape of a journey, not its contents. On-screen text is never logged, never transmitted, never stored. Screen previews are redacted boxes rendered on the device — the layout, none of the words.
vs. rolling your own
Manual event tracking can get you here eventually. This is here on day one.
| AnalyticsDrop | Manual event tracking | |
|---|---|---|
| Time to first insight | Minutes | Days to weeks |
| Code you write per screen | None | An event on every screen |
| Catches screens you forgot to tag | ||
| Drop-off & funnels out of the box | ||
| SwiftUI auto-capture | ||
| Stores on-screen text / PII | Never | Usually |
| Renaming applies to past data |
Pricing
Start free. Upgrade when your app grows. Cancel anytime.
For your first app.
For teams shipping fast.
For bigger footprints.
Prices are illustrative for this preview.
FAQ
One line. You add the SDK via Swift Package Manager and call start(apiKey:) at launch. Most teams see their first journey in the dashboard within ten minutes — no per-screen tagging, no tracking plan.
Yes — automatically, in the same app. Screen views are captured for UIKit view controllers and SwiftUI navigation without you naming a single screen. An optional modifier lets you set an exact name where you want one.
Never. On-screen text is never logged or transmitted. Thumbnails are redacted boxes rendered on-device — gray shapes standing in for layout, never the content. It's a hard invariant, enforced by a test that checks generated thumbnails contain no readable text.
No. The capture hook returns in under a millisecond, all real work happens off the main thread, and events are batched and uploaded in the background. There's zero third-party dependency in the SDK.
Each screen gets a stable fingerprint that stays the same across relaunches and rebuilds, even as the data on screen changes — so the same screen always shows up as one node, and renaming it applies to all of its history.
iOS is available today. Other platforms are on the roadmap. If you're shipping an iOS app, you can start now.
Yes. Your events live in Postgres, and data export plus a self-hosted option are available on the Scale plan.
Add one line, ship, and watch the journey build itself. No tracking plan, no credit card.