Most apps ship with passengers nobody invited: trackers, analytics and ad SDKs baked into the binary by default. We took the problem the other way around: nothing ships unless the app's owner explicitly turned it on. Here's the engineering, down to the compilation flags.
Quick context: GoodBarber is a no-code app builder (running since 2011). Customers configure an app in a web back office and the platform compiles real native builds, Swift for iOS and Kotlin for Android, plus a PWA. The people who own these apps will never open Xcode. Which makes the question sharper: who decides what code ends up in their binary?
The ghost SDK problem
A ghost SDK is any library that lives in an app's binary without the app's maker having chosen it. The pattern is everywhere, no-code or not:
- Template runtimes. Many app factories compile every app from the same master project. Every feature the platform supports, and every SDK behind it, ships in every binary, used or not.
- Transitive passengers. An SDK pulls its own dependencies. You added a video player; you also got its analytics.
- Default-on integrations. Analytics and crash reporting wired in "for your own good", opt-out at best.
Why it matters, concretely:
- Data can move without anyone deciding it. An embedded SDK is code that runs with your users, and some of it phones home whether or not the feature is used.
- Attack surface. Every library is code you now answer for, including its CVEs.
- Weight. Dead SDKs are dead bytes on every install.
- You can't answer the stores honestly. Apple's privacy manifests and Google Play's Data safety form ask what your app collects. If you don't know what's inside your binary, you're guessing on a compliance document.
The industry default is opt-out. We think a binary should be opt-in.
A library ships only if the feature is on
We call the model on-demand embedded code, and the principle fits in one sentence: a library is embedded in the binary only if the corresponding feature is activated in the app.
How it actually works:
- Every app has a feature graph. Sections, extensions, monetization, push, integrations: the back office knows exactly what an app uses.
- The graph drives conditional compilation. At build time, the feature graph toggles compilation flags (pragmas) that include or exclude whole modules and third-party SDKs from the project. Off doesn't mean disabled or dormant. It means the code is not compiled in at all.
- The Privacy Center is the control tower. One place where the app's owner sees what runs in their app and decides what is allowed to.
- Builds happen on demand. We don't recompile on every toggle. A binary is generated when it's needed, typically when an update is about to be submitted to the stores, with exactly what the app's current configuration requires. For the owner this is transparent: they configure, we tailor the build.
On iOS, for example: AdMob is in the binary only if ads are enabled. The Facebook SDK, only if that integration is on. Even the in-app purchase stack (our StoreKit integration) stays out of the build unless in-app purchases are part of the app.
The consequence is easy to state and rare in practice: the app doesn't just declare less, it contains less.
And it's measurable. An Apps for Kids build, which by construction embeds none of these third-party SDKs, weighs about a third of a full-featured build (from our build data, July 2026).
The data question: hosted by us, in Europe
A clean binary is half the story. The other half is where the data lives.
GoodBarber is its own hosting provider. Customer and end-user data is hosted exclusively on our servers in Europe, and it does not leave the EU. No hyperscaler region to audit, no transfer mechanism to squint at: sovereignty here is one company, one jurisdiction. That baseline is what makes GDPR (and Germany's stricter BDSG) tractable for the small teams who build on the platform.
Consent gets the same treatment. For apps that do turn on ads or analytics, the platform ships an integrated CMP supporting the IAB Transparency & Consent Framework v2, plus Google Funding Choices for ad-monetized apps. So what is in the binary is disclosed, and consented to, per user and per purpose.
What this changes at store review
Apple's privacy manifests and Play's Data safety form stop being archaeology. Our privacy declarations are fed by the same source of truth as the build itself: the feature graph. What we declare is what we compiled, because both derive from the same place. There is no "wait, what does that SDK actually collect?" moment, because an SDK nobody chose is not in the build to begin with.
The extreme case proves the model: Apps for Kids. One declaration in the back office marks an app as a kids' title (Apple Kids Category, Google Play Designed for Families), and the platform disables every feature incompatible with those programs: third-party analytics, behavioral ads, intrusive permissions. The build that comes out is compliant by construction, because compliance is enforced where it's real: in what gets compiled.
Now the honest limits, because a claim like "nothing you didn't invite" deserves its footnotes:
- The iOS push stack is always there. Our pipeline has never been wired to produce an iOS binary without push. Nobody ever needed that build, so that path doesn't exist. If you never use push, its code is still in your binary.
- "Clean" means no uninvited third parties, not zero code. GoodBarber's own runtime is in every build. The difference: we own it, we answer for it, and it is one vendor you already chose.
- We don't make your app compliant by magic. What owners collect through their own content (forms, orders, accounts) is their responsibility. We ship a clean binary, honest declarations and the consent tooling; the rest is theirs.
The takeaway
If you build a platform that compiles other people's apps, the transferable pattern is this: derive everything from one feature graph. Binary contents, privacy declarations, consent configuration, all from the same source of truth. The moment two of those are maintained by hand, they drift, and drift in privacy is how ghost SDKs are born.
More on the platform's privacy stance: goodbarber.com/privacy-compliance.
Questions in the comments. I'll answer with build-level details where I can.
