What Apple's Kids Category Kept Out of PlaySori
PlaySori went to App Review in the Kids Category this week. That meant cutting my purchase SDK and crash reporting, and building a few things myself.
On Wednesday I submitted PlaySori 1.0 to App Review. It's a set of calm digital toys for young kids, and it's going into Apple's Kids Category, in the 5 and Under age band.
I wrote a couple weeks ago about designing for users who can't read yet. That post was about the interface. This one is about everything under it, because the Kids Category changed my stack more than it changed my screens.
The Rule That Did Most of the Work
Apple's guidelines are short on this. Kids Category apps "should not include third-party analytics or third-party advertising," and they "may not send personally identifiable information or device information to third parties."
No ads was never a question. The second half is the one that bites, because a lot of standard SDKs send device information without you ever asking them to. You don't find out until you read their privacy manifests, and I'd already planned around two of them.
RevenueCat Came Out of the Plan
My original plan used RevenueCat for subscriptions. I've used it before, it handles both stores, and it would have let me tune the free tier remotely without shipping an update.
Then I went through what it actually sends. The iOS SDK includes the device's vendor identifier in a request header, and there's no public setting to turn that off. Its privacy manifest also declares purchase history. That meant my App Store privacy label couldn't honestly say "Data Not Collected," and reading the Kids rule literally, it was a third-party SDK sending device information. That's the kind of thing I'd rather not argue about with a reviewer.
So I wrote the purchase layer myself: StoreKit 2 on iOS, Play Billing on Android, and a thin facade so the game code doesn't care which one it's talking to. Purchases are verified on the device, and there's no receipt server, because there's no server at all.
It cost me two things. Remote free-tier settings now come from a static JSON file on the PlaySori website instead of a dashboard. And restoring a purchase across platforms is harder than it would have been, since there's no shared account to hang it on.
No Crash Reporting SDK
The plan also had Unity's built-in crash reporting. It collects a unique install ID that can't be configured away, and that's a persistent identifier, the exact thing I was trying not to send anywhere.
So there's no crash SDK. I get the crash reports Apple and Google collect in their own consoles, and that's it. It's less detail than I'm used to. For an app with no accounts and no network-dependent features, I think it's enough, but I'll know more once real kids are tapping on it.
I also turned off every Unity data service and added a test that fails the build if any of them get switched back on. Settings like that have a way of quietly resetting during an engine upgrade, and I'd rather find out from a red build than from a review rejection.
On Android, the manifest force-removes the advertising ID permission, even if some future dependency asks for it.
No Accounts, and One Locked Door
PlaySori doesn't have accounts, logins, or a parent dashboard. Those were cut early, and it made almost everything else simpler. Free-play timing lives on the device. The only network call besides the stores is a plain request for that config file, with no identifiers attached.
The only place a grown-up needs to go is the purchase screen, so that's the only thing behind the parental gate. To get in, you hold a spot for three seconds, then answer a multiplication question written out in words, like "What is seven times six?" One wrong answer closes it quietly. The privacy policy and terms links sit behind the same gate, so there's no way for a kid to tap out to a browser.
One thing I had to keep straight: Apple says a parental gate is generally not the same as getting parental consent. It keeps a kid from wandering into the purchase screen. It doesn't make collecting data okay. That's another reason to not collect any.
What I'd Tell Anyone Starting a Kids App
The simplest way to comply is to collect nothing, and you have to decide that before you pick your SDKs, not after. Every one of these changes was cheap because I made it during planning, before any of it was in the code. Pulling RevenueCat out of a shipped app with real subscribers would have been a very different week.
Read the privacy manifests of everything you plan to include, and assume anything with an analytics or diagnostics feature is sending an identifier until you've confirmed it isn't.
Now it's in Apple's hands. The Kids review is known for being slower and stricter, and I've budgeted for at least one rejection. If you're planning an app with rules like these, I build mobile apps and I'm happy to talk through it.
Working on something like this? See mobile app development or what XenneX has built.
Keep reading
- Designing for Users Who Can't Read YetMy next app is for kids as young as two. No text, no menus, no settings. Building it has meant unlearning most of what I know about interface design.
- Why I Still Read Every Single App Store ReviewSix live products, years of reviews, and I still read every one manually instead of just scanning the star average. Here's what that catches that sentiment analysis doesn't.
- Summer Is When Indie Apps Actually Grow. Here's Why.The conventional wisdom says summer is a slow period for app downloads. It's wrong. Here's what actually happens to indie app discovery from June through August — and how to position your app to catch it.