Three lines of code. That's how attribution should work.
Last October, a developer emailed us: "I spent four hours setting up Branch. Your SDK took me nine minutes." She wasn't exaggerating. We timed it. And that moment crystallised everything we'd been trying to build into Attribr.
The integration tax nobody talks about
Most attribution SDKs treat setup as an afterthought. You follow a 15-step guide. You configure an API key. You add delegates. You wait for a Slack response from support because something failed silently. It eats a day. Sometimes two.
When we started building Attribr, we knew we were building for people like that developer. Indie studios. Solo iOS devs. Teams of four or five. People who have zero time to debug integration problems and don't have a growth team to hand off to. The math was simple: if setup takes four hours, you lose people before they see if the product even works.
So we asked ourselves a harder question. What if we reversed it? What if you could see attribution data running in under ten minutes, then decide if you wanted to dig deeper?
How three lines actually covers everything
The three-line integration looks like this in Swift:
import Attribr
Attribr.start(appKey: "your-key")
Attribr.logInstall()
Three lines. That's it. You get install-source attribution, deterministic matching where it's available, probabilistic fallback when it isn't, and retention cohort tracking at day 7, 14, and 30. The 50KB SDK sits on your device with zero third-party dependencies, so it launches in under 50 milliseconds. No bloat. No framework conflicts.
But here's what catches people off guard: it also works on iOS 14.5+ without needing ATT permission. That matters. Users hate permission prompts. Fewer prompts means better completion rates and cleaner data. We built deterministic matching first (checking whether Apple reported the source via SKAdNetwork), then fall back to probabilistic signals only if we need to. It's backwards from how fingerprinting-first SDKs work.
Kotlin developers get the same story. Three lines. Same speed. Same coverage.
The Rippl bridge lives here
When we launched Attribr, we knew our biggest differentiator wasn't just speed or size. It was the direct wire we'd built into Rippl, our performance-marketing platform. If you're running a CPI campaign with a Rippl promoter, you can see exactly which install came from which creator. Not anonymised. Not batched and delayed. Per-install, in real time.
That bridge starts in these three lines too. Once your app reports an install, Attribr automatically checks whether a Rippl CPI campaign drove it. If one did, you see the promoter name, the campaign ID, the cost per install. You can then cross-reference it against your retention cohorts on the Attribr dashboard.
It's table-stakes for community-driven growth. And it's only here.
Integration, then depth
The genius of starting with three lines is that you're not locked in. If you need fraud signals, ad-network roll-up, or custom event tracking, you add those incrementally. Pro tier unlocks fraud scoring and network-level data slicing. You can integrate your own ad networks if you want. None of it requires ripping out the foundation and starting over.
We also built the dashboard to assume you'd start simple. A cohort chart showing retention by install source. A funnel view. A retention grid. Not a 40-tab analytics suite that requires a wiki to understand. Indie developers need to answer three questions quickly: where did this install come from, is the user still active, and if I paid for it, what was it worth? The dashboard answers those before you ever hit a settings menu.
Why this matters to your ship date
When you're launching an app, every day counts. You need to know if your beta testers are organic or if they came from that Reddit post. You need to see retention before your metrics go stale. You don't have time for a two-week integration sprint.
One studio we work with integrated Attribr on a Tuesday morning, shipped their app on Wednesday, and had their first retention cohort by Friday. By the following Wednesday, they'd already killed one ad network because the cohort data showed zero day-7 retention. They wouldn't have known that for three weeks with a traditional setup.
Three lines. That's what bought them that time.
If you're building an app and you've been putting off attribution because the setup feels like a second project, ask yourself this: what would you do with your install data if you could see it today, not in two weeks?