Fewer Strangers in the Room
28 May 2026
Almost no app is written entirely by the company whose name is on it. Modern software is assembled: you write the parts that make your product what it is, and for everything else you reach for a ready-made component that somebody else has already built and shared. Need to know which model of phone you're running on? There's a library for that. Need to scan a QR code, talk to a cloud service, or ask the operating system to sign someone in? There's a library for each of those too. This is ordinary, sensible practice, and we do it as much as anyone.
The trouble is that every one of those components is code we did not write, shipped inside our app, running on your device with the same permissions our own code has. Most of them are maintained by thoughtful people with good intentions. But we cannot read every line of every one, we do not control what a future version of them will do, and a surprising number of components in the wider ecosystem quietly collect usage data as a default behaviour. When the app in question is a children's game, that is a lot of strangers to have in the room.
So we went through the list and started removing. Out went the component that told us the device model and operating system version, replaced by a small piece of code we wrote ourselves that asks the operating system directly and returns only what we actually need. Out went the one that reported the app's own version number, which turned out to be something we could simply stamp in at build time. Out went a QR-code library and a camera-scanning library that we had brought in while exploring one way of moving an account between devices, and that we no longer needed once we settled on a simpler approach. Out went the third-party toolkit we had been using to talk to Amazon's cloud services, in favour of our own code that speaks the same protocols. That last one alone meant reworking around twenty different places in our codebase.
The biggest of them was our sign-in. When we launched passkey support in March, the cryptography was ours but the piece that actually talks to the operating system's passkey system was a third-party plugin. That felt wrong for something as sensitive as authentication, so we wrote our own, one implementation per platform, talking directly to Apple's, Google's, and Microsoft's own passkey machinery with nothing in between. It was easily the most work of anything in this list, and it is the one we would have regretted skipping.
None of this makes a visible difference the next time you open one of our games. The download is a little smaller and the app asks for less from your device, but nobody is going to notice. We did it because our privacy policy makes a promise about what we collect and what leaves your device, and that promise is only worth as much as our ability to actually verify it. A component we have not read and do not control is a promise we are making on somebody else's behalf.
We are a small, independent Swedish company, and doing the plumbing ourselves is genuinely slower than pulling in someone else's. We think that is the right trade. The families who install our games are trusting us with their children's screen time, and the least we can do is be able to say, honestly and specifically, what is inside the thing we handed them. Trust built on "we assume it's fine" is not really trust at all.