I built my daughter a geography app. It took 67 days and zero dependencies.

Eric Guan — Wed, 13 May 2026 06:17:15 +0000

Two months ago, I started building an iOS app for my daughter. This week, I shipped it.

MapSprout is a US geography app for kids — they learn the 50 states + DC through quizzes and a 3D map road-trip mode. It took 67 days from first commit, 920 commits total, pure SwiftUI with zero third-party dependencies, and it's in Apple's Made-for-Kids 9–11 category.

Here's what shipping solo actually taught me.

Why I built this in the first place

My daughter Emma is at the age where she's starting to learn US geography. I looked at what was on the App Store. Nothing felt right.

So I built the thing I wanted her to have.

The build

67 days from first commit to launch. 920 commits. Six commits on day one — welcome screen, home screen, state list, and a first cut of the quiz all landed on the first afternoon. The shape of the app didn't really change after that. Everything since was polish, content authoring, and the App Store machinery itself.

A few decisions I made early ended up shaping everything:

Submitting to the Made-for-Kids 9–11 category. This is a one-way decision per Apple — once approved, every future update has to honor the Kids category guidelines, or you have to register a brand-new app. It closed a lot of doors. No behavioral analytics. No third-party SDKs. No free-text input on the kid side. The feedback form is gated behind a parent check (a multiplication problem) so kids can't submit unsupervised. I said no to a lot of "obvious" features early because Kids guidelines closed the door on them.

Zero external dependencies. Pure SwiftUI plus Apple frameworks only. No analytics SDK, no crash reporter beyond Xcode Organizer. Every time I felt the urge to reach for a library, I asked whether Apple's framework could do it. Usually yes, if I was willing to write 50 more lines. Total dep-management cost over the build: 0 hours.

What took the time

The interactive US map. The map is 50 custom SwiftUI Shapes plus DC, not a MapKit view. Each is its own tappable region with point-in-path hit testing (not bounding-box, or you'd register a tap on Wyoming when you meant Colorado). Smallest states render last so they draw on top of bigger ones for tap priority — otherwise New York eats Vermont's tap area. On questions where the kid has to tap the state on the map, the map zooms toward the target so DC and Rhode Island actually have something to hit. AK and HI use inset boxes; geographic position would put HI a thousand pixels to the left of the mainland. Interior state borders are a separate overlay because filled Shapes double up at every shared edge. Region highlighting (Northeast / South / Midwest / West) is yet another overlay layer. I rebuilt the rendering pipeline twice.

Cold-start performance. First builds did all setup synchronously in the launch path: load saved progress, build 50+ state shape paths, pre-compute the map sort order, warm the sound synthesizer (no bundled audio files; tones are generated at runtime). Welcome screen lagged on a real device — kids tap the icon and want movement instantly. Refactored to a two-phase startup: Phase 1 loads only what's needed to show the welcome screen and gets the UI on screen; Phase 2 warms everything else in a detached background task at .userInitiated priority after the UI is visible. The user is already interacting before the heavier work finishes. Cold start now feels instant.

What I got wrong

Algorithmic hints aren't enough. I started with the standard moves — "remove two wrong answers", "reveal first letter", "highlight a region." Realized late that kids actually needed a written nudge anchored to a fact they'd already seen in the app. So I authored a written hint for every question, capped at 80 chars, Grade 3 vocab.

Then I audited the catalog and caught a whole class of accidental hint→answer leaks I'd written without thinking: "small stone you might skip" → Little Rock. "agreement or harmony" → Concord. "north of South Carolina" → North Carolina. "three-word name beside a giant salty lake" → Salt Lake City.

A hint that maps to exactly one answer with zero recall isn't a hint, it's a free pass. Re-audit took two evenings.

The privacy and listing legal layer is its own project. What looked like one afternoon of policy writing turned into: GDPR section, COPPA section, UK Age-Appropriate Design Code section, App Privacy questionnaire (which is not the same as the privacy policy, and Apple checks both), a deploy pipeline for the legal pages, DNS hardening across two domains, Google Workspace migration for the support inbox. Probably 20% of total project hours, and almost none of it touches the app binary.

Some technical surprises I had to discover the hard way:

SwiftUI's withAnimation interpolates .position(CGPoint) linearly between start and end — even when the CGPoint comes from a curve-sampling helper. I burned an evening trying to animate a marker along a Bézier path before figuring this out. The fix is an AnimatableModifier whose animatableData is the scalar t, so SwiftUI interpolates t and re-samples the curve every frame.
The .storekit config file is only loaded by the Xcode scheme, not by simctl launch. I tried to capture a paywall screenshot via the simulator CLI and the price showed "Loading price…" forever.
TestFlight IAP bypasses the sandbox tester flow entirely. Sandbox tester accounts (the ones you create in App Store Connect) are useless inside TestFlight builds.
CloudKit's public DB _world role is forced read-only. Spent an hour trying to give anonymous users write access to a feedback bucket. CloudKit doesn't let you.

The Apple review wrinkle

Submitted May 7 at 8:46 PM PT. About 36 hours later I got a Guideline 2.1 Information Needed message about our Made-for-Kids (1.3) data practices.

The App Privacy questionnaire I'd filed said "No" to all data collection. But App Review noticed CloudKit was writing user-generated quiz answers off-device. Even though they're anonymous, even though it's the user's own private database — that still counts as "collection" in App Privacy terms.

Reply went out same day. I flipped the questionnaire to "Yes" with three Not-Linked / App-Functionality categories. Approved May 11. The actual app didn't change. The disclosure did.

The App Privacy questionnaire and the privacy policy are two different things. Disclose anything that leaves the device on both. The questionnaire is what the review team reads first.

Launch day itself

Faster than I expected. The "Release This Version" click → "Ready for Distribution" status flip → public App Store URL returning HTTP 200 took about 2.5 minutes of CDN propagation. I polled the URL every 30 seconds until the title and price showed up. The post-launch admin (README badge, privacy policy revision note, calendar reminder to capture the keyword ranking baseline at 48h) took longer than the release itself.

Where I'm going with this

Launch isn't the verification. The first 30 days of real-user data is. I deferred a few polish items that are queued for v1.0.1, shipping within two weeks.

I've been studying the existing kids' geography apps in the category. Most of them haven't shipped meaningful updates in over a year. I have fewer features today but I think I can build them. Instead of going wide and starting more apps, I'm going deep on this one.

For the next month: watch first-week signal (App Store Analytics, reviews, crashes, in-app feedback), ship v1.0.1 with the deferred polish items, and start on v1.1.

If you want to take a look, MapSprout is on the App Store at apps.apple.com/app/id6766167316.

I'm Eric Guan, an indie iOS developer building under Vectory LLC. MapSprout is my first app. I'll keep posting here as I learn — drop a follow if shipping-solo retros are useful to you.

DEV Community: Eric Guan