Bringing the Crash Reports Home
18 August 2026
When one of our apps hits a fault we did not anticipate, it sends us a report so that we can fix it. That is the only reason we ever hear about most problems. The alternative is not a simpler app, it is an app whose faults you learn about when somebody writes in to tell you, which for a children's game usually means never. Until this summer, the piece of software doing that reporting was not ours.
In May we wrote about spending a month pulling outside components out of our games, and this one did not go with them. That was not reluctance, it was arithmetic. A crash reporter is an unusually awkward thing to replace. It runs inside the app at the worst possible moment and has to survive the very failure it is describing. It has to work when the device is somewhere with no signal, holding the report and sending it later when there is. It has to do all of that the same way on six games across every kind of device we support. Get it wrong in one direction and you have made the app worse for the player, which is the thing we were trying to avoid in the first place. Get it wrong in the other and you have blinded yourself, and you will not find out until the day something breaks and nobody tells you. So we took our time. We measured what the old one cost us first, so that we would know if we had made anything worse. We moved our own servers over before we touched a single app. And only when that had been running quietly for a while did we ship it to players.
It is worth being clear about why we did it at all, because the obvious reason is not the real one. We did not move because we distrusted the company we were using. They are a serious outfit, they handle this kind of data carefully, and the reports were already being kept inside the European Union. We moved because a report we hand to somebody else is a report we no longer control. Our customers' devices were opening connections to a vendor's servers, and every question we might later be asked about that data, what is kept, for how long, who can see it, what happens if the terms change, had an answer that was not ours to give. We are not claiming self-sufficiency here. Our servers are rented, our code is stored in a repository we do not own, and there is plenty more besides. The distinction we care about is between running our own software on a machine we rent, where what gets collected and how long it lives are our decisions, and sending our players' data into somebody else's product, where those decisions belong to them. We hold ourselves to a standard we cannot meet by proxy.
One thing that follows is worth saying plainly. We know exactly what a report contains, because we wrote the thing that builds it: the error, the technical trace showing where in our own code it happened, the device details, the app version, and the time it occurred. Not your progress, not your scores, not anything you have typed. Our privacy page says the same, and it is now a description of our own software rather than a promise about somebody else's.
A fault that reaches one player usually reaches a great many, so the service fingerprints every report as it arrives and recognizes when two of them are the same underlying problem, even when they turn up from different games on different devices. One fault becomes one ticket, with a count on it. The count is the part that matters. It is what tells us whether we are looking at something a single player hit once on an unusual phone, or something quietly spoiling the game for thousands, and it is how we decide what to fix first.
One part of this we built, measured, and then removed. The step that reads a new report and works out what it means is called triage, and we shipped it with an AI model doing the first pass. We use AI tools where they earn their place, and we are neither precious nor evangelical about them. Here it did not earn its place. A model looking at a crash report sees the error and the trail of function names leading to it and has never seen the code itself, so what it produces reads like a diagnosis without being one. In one real case it read the failure, correctly narrowed it to a permissions change somewhere in our own infrastructure, and stopped at suggesting we go and confirm which. The person who picked it up afterward found the exact change, in a different project, made days earlier, along with the reason none of our tests would have caught it. We ran it, compared what it produced against what a person with the code open produced, and took it out. That was a judgment about the value AI provided us and our players, and nothing else.
What we are left with is a standard we can actually hold ourselves to: we should not see the same error twice. Every report that arrives ends in one of two places. Either it is a defect, and the fix comes with a test that would have failed before that fix existed, or it is one of the unavoidable facts of running software in the world, a network that dropped or a device that ran out of memory, and it gets a tolerance instead, so the next one is handled rather than reported. "We are not going to fix that" is not one of the options.
None of this is something you will see. The download is no different and the games play the same. But when one of our games stumbles on your child's tablet, we want to be able to tell you exactly what we learned about it, exactly where that went, and exactly what we did next. That is a great deal easier to say honestly when the path from the moment it breaks to the ticket somebody picks up in the morning belongs to us.