The Weight Problem Nobody Talks About

The bloat creep nobody plans for

When you're shipping your first app, you don't think about SDK weight. You think about features, bugs, and whether anyone will actually download your thing. You grab an attribution SDK because you need to know where installs came from. Then you add analytics. Then a crash reporter. Then a performance monitor. Then ads. By month three, you're carrying 8MB of third-party code you barely interact with, all running on someone else's schedule, with their network calls firing on their timeline.

The real cost isn't just the megabytes. It's the launch overhead. Every SDK wants to phone home on startup. Every one has its own HTTP client, its own JSON parser, sometimes its own networking stack. They fight each other for CPU cycles on a cold start. Users feel it as a half-second stall before your app responds. On older phones, it's worse.

We built Attribr because we got tired of watching indie developers choose between knowing where their users came from and keeping their app feeling fast.

50KB and nothing else

Attribr weighs 50KB. That's smaller than a single screenshot in your app store listing. It has zero third-party dependencies. No external HTTP library. No JSON parser pulled from GitHub. No surprise transitive deps that get updated without your knowledge. Everything you need to answer the three questions that actually matter for indie studios is built in, compiled straight into your binary.

Launch overhead is sub-50ms on real hardware. We benchmarked on an iPhone SE (second generation) and a Pixel 4a. The SDK initialises, checks what it needs to check, and gets out of the way. That overhead disappears into the noise of your own startup code. You don't see it. Your users don't feel it.

This wasn't accidental. It came from a very deliberate choice early on: we would not pretend to be an enterprise SDK. We would not try to do fingerprinting, probabilistic fallback logic, fraud rings, and behavioural cohorts all at once. We would do three things exceptionally well and do them without bloat.

Deterministic and probabilistic, without the weight

After iOS 14.5, Apple added AppTrackingTransparency. Most attribution services responded by panicking. They spun up probabilistic fingerprinting stacks to guess where installs came from when ATT permission was denied. Those stacks are heavy. They need context, signals, historical data, statistical models running client-side. We took a different approach.

Attribr works without ATT permission, but it doesn't pretend to be magic. When deterministic data is available (you clicked an install link from a newsletter, a Discord server, a Reddit thread, a Rippl promoter), we use it. When it's not, we fall back to probabilistic matching that's been tuned to be accurate without burning CPU or battery. The result is that most indie developers get attribution data that's reliable enough to make real decisions, without carrying a machine-learning stack in their app.

And because we built it small from the start, we could afford to be honest about what probabilistic matching can and cannot do. We don't oversell it. We show you confidence signals. We tell you when you're in the probabilistic zone.

Integration that doesn't require a consultant

Three lines of code. That's the integration. In Swift, you call one function on launch. In Kotlin, same thing. You pass in your app ID and you're done. The SDK handles the rest: detecting install source, tracking day 7/14/30 retention cohorts, bridging to Rippl if you're using it for CPI promotion.

We made this a non-negotiable. Enterprise SDKs require you to hire someone who knows how to configure them. They have 47 parameters and a setup guide that's 30 pages long. We're not building for that audience. We're building for the developer who has 90 minutes free on a Thursday afternoon and wants to ship attribution tracking before the weekend.

Because the SDK is small and dependency-free, there's nothing hidden to configure. No transitive breakages across other libraries. No version conflicts. No 'we changed our networking layer and now it clashes with your analytics SDK' emails. You add Attribr, it works, you move on.

The Rippl bridge changes the math

Here's what makes Attribr different from just being a lightweight attribution layer: it talks to Rippl. Rippl is a performance marketing platform for indie games and apps. Promoters list available inventory on Rippl. You bid for their traffic. When an install happens through a Rippl promoter, Attribr knows who drove it and can tell you the CPI and retention breakout for that specific channel.

No other attribution SDK has this bridge. It's not a small thing. For indie studios running performance campaigns, it means you can answer 'which promoter is actually driving retained users' and not just 'which promoter sent the most installs'. That's a completely different conversation with your marketing spend.

The dashboard shows you cohort breakdowns, funnel charts, and retention curves. The Pro tier adds fraud signals and ad-network roll-ups so you can see which networks are sending real users versus bot traffic. But the core story is the same: lightweight, fast, and connected to a platform designed for people building at indie scale.

What this actually costs

The free tier gets you 1,000 installs per month. It's real. No seat limits. No time limit. If you're prototyping or you've shipped something that's just finding its audience, you're covered. Growth tier is £29 a month and handles up to 25,000 installs. Pro is £99 for 100,000 monthly installs plus the fraud and ad-network features. If you're running a company-wide operation with multiple apps and unlimited volume, that's a conversation with us.

The price isn't a trap. It's not 'free' until you hit 50,001 installs and suddenly owe £500. The tiers are honest. You move up when you actually need more, and the jump is proportional to what you're gaining.