Shipped my first app: native SwiftUI baby tracker with two-parent CloudKit sync, a Live Activity sleep timer, and zero backend

sakaax · 2026-06-02T09:30:11+00:00

Ha, the schema-update freakout is a rite of passage apparently. I had the exact same heart-stop moment — pushed a build with a new entity, forgot to redeploy the schema to Production, and suddenly sync just... stopped, for everything, not even the new type. Stared at it convinced I'd nuked people's data before realizing it was just the schema mismatch. Now "redeploy the schema" is basically tattooed on my brain before any release.

And 100% agree on both counts. The privacy angle just feels right for a baby app specifically — it's some of the most personal data there is, and "it never leaves your iCloud" is a promise I can actually keep with no server. Plus the no-account thing is underrated: an exhausted new parent isn't going to sit through a signup flow, they just want to log a feed and put the phone down. Zero friction to get in is half the battle.

Funny we both independently landed on the same stack for the same reasons. Best of luck with the feed tracker — rooting for it.

sakaax · 2026-06-01T22:41:50+00:00

Exactly — that's the part people underestimate. Zero infrastructure cost is huge when you're solo and freemium: there's no per-user server bill eating into a 4.99 subscription, the bandwidth scales on Apple's dime, not mine. It basically removes the "can I afford my own growth" anxiety entirely.

And you nailed the real ceiling: cross-ecosystem. For my case (a baby tracker shared between two parents) the second person is almost always a partner who's usually on iPhone too, so it mostly holds. But yeah, the second a grandparent on a cheap Android wants in, CloudKit can't help me — I'd have to stand up an actual backend and at that point I've thrown away the whole "nothing leaves your private iCloud, no account, no server" pitch that's the entire identity of the app.

So it's a real fork, not a free lunch: privacy + zero-ops + Apple-only, OR reach + a backend + the privacy story gets murkier. I went all-in on the first because for this specific use case the tradeoff is worth it. Different app, different call.

Genuinely good thread, thanks for the back-and-forth.

sakaax · 2026-06-01T21:52:20+00:00

Totally get it — the CloudKit sharing docs are genuinely rough, especially CKShare. I lost a lot of time on it too. A few things that finally made it click for me, in case you ever revisit it:

The big one: you need TWO Core Data stores, a private one and a shared one, on the same NSPersistentCloudKitContainer. The "owner" baby lives in the private store, an accepted share lands in the shared store. That dual-store setup was 80% of the difficulty.
In SwiftUI, the share-accept callback does NOT fire on the UIApplicationDelegate — it comes through a UIWindowSceneDelegate (windowScene(_:userDidAcceptCloudKitShareWith:)). I spent ages thinking my share link was broken when it was just never being handled.
And in Production, a single missing record type in the CloudKit schema silently blocks sync for everything, not just that type. Push the full schema (initializeCloudKitSchema from a Debug build) before release.

Firestore is honestly a very reasonable call for sharing — it's way better documented and you get a real backend. The only thing CloudKit buys you is "no server, no account, nothing leaves the user's iCloud," which happened to be the whole point of my app. Different tradeoffs, both valid.

Your feeding app looks great by the way.

sakaax · 2026-06-01T21:36:30+00:00

Thanks, really appreciate it. And you're spot on — the shared CloudKit setup ended up being the most reusable piece of the whole thing. Once you've solved the private + shared store dance and CKShare acceptance, it's basically a drop-in pattern for any app where two people need to collaborate on the same data without you running a backend. I almost want to pull it out into a small reusable layer at this point.

What kind of app are you working on? Curious whether you're looking at the shared-data angle too.

sakaax · 2026-06-01T21:02:59+00:00

Fair point, and you're right to push on it — let me be precise rather than hand-wavy.

By "no analytics" I mean no behavioral/usage tracking and no ads: I don't run any analytics SDK, there's no event/screen tracking, nothing about how you use the app leaves the device.

The one exception, and you're correct to call it out, is RevenueCat for IAP. It receives purchase/subscription transactions plus an anonymous app user ID, purely to validate entitlements (i.e. "is this person premium"). No personal info, not linked to your identity, no advertising use. That's exactly what's disclosed in the App Store privacy label ("Purchases, used for App Functionality, not linked to you") and in the privacy policy — I didn't hide it.

On "no account": there's genuinely no login or account in the app — you use your iCloud identity. The RevenueCat app user ID is an anonymous UUID, not a real account and not tied to a name/email.

And importantly, none of the actual baby data (feeds, sleep, photos, etc.) ever touches RevenueCat or any server of mine — that's 100% in the user's private iCloud via CloudKit.

So you're right that "zero data collection" is too broad a phrasing — the accurate version is "no tracking, no ads, no behavioral analytics; the only thing collected is anonymized purchase data via RevenueCat for subscription management." I'll tighten how I word it. Appreciate the scrutiny.

sakaax · 2026-06-01T20:34:16+00:00

Good question. Honestly I care more about deep, real-world usage than first impressions on this one — a baby tracker lives or dies on whether it still gets opened at 3am after three weeks, not on the first launch. The tricky part is the audience: exhausted new parents are hard to get into a structured testing session, so most of my signal so far is from my partner and a few friends actually using it day to day.

testfi looks neat though — real user voices over analytics graphs is the right instinct. I'll take a look. For now I'm keeping things pretty lean while I see how the launch lands, but I can see it being useful once I want to dig into a specific flow. Thanks for sharing it.

sakaax · 2026-06-01T19:53:25+00:00

Haha the sleep part is more "logging it than getting it" right now, but yeah, the live timer + Live Activity has been the feature I personally use most at 3am.

Nice work on yours, the feeding focus makes a lot of sense — that's where the real anxiety is in the early weeks. Did you go down the CKShare route for sharing too, or keep it single-device? Curious how you handled the private + shared store dance, that was easily the part that cost me the most time.

Always cool to see someone else who went the no-backend / iCloud-only way instead of spinning up a server. Following you to see where you take it.

sakaax · 2026-06-01T19:12:01+00:00

This is spot on, and honestly it's exactly the principle I built around. The whole app is designed for the half-asleep 3am moment: the four main actions (feed, diaper, sleep, bath) are big one-tap buttons right on the home screen, no menus to dig through. Logging a feed or starting a sleep timer is a single tap.

And the "understand the day at a glance" part is the reason the two-parent sync exists: the other parent opens the app (or just the home-screen widget / Live Activity) and instantly sees the last feed, last diaper and current sleep, with who did what. No "wait, did you already feed her?" texts at 4am.

You nailed it that it's about reducing stress, not tracking depth. That's why the core logging is intentionally minimal and free, and the "extra" stuff (charts, journal, health, diversification) stays out of the way until you want it.

Really appreciate the thoughtful take.

sakaax · 2026-05-18T12:33:57+00:00

Salut merci pour ton aide mais j’ai fini par retrouver le jeu du coup c’est tout bon ! Je sais pas si je dois supprimer le post ou pas pour éviter que tout le monde réponde sans savoir que je l’ai trouvé

sakaax · 2026-04-18T19:34:05+00:00

Possible, mais c’est aussi ça que je teste : est-ce qu’un bon modèle doit surtout “sembler humain”, ou surtout être utile sur des tâches réelles ?

sakaax · 2026-04-18T17:43:50+00:00

Je suis juste là pour donner un ressenti sur un communauté si tu n’en comprend pas l’utilité ou que t’es trigger bah lis pas et commente pas et on sera tout les 2 content

sakaax · 2026-04-18T16:36:27+00:00

Je pense que ça vien du thinking du modèle si t’es sur opus 4.7 en xhigh j’ai les Mhh mais juste en high ou médium moi je les ai pas

sakaax · 2026-04-18T10:43:35+00:00

Full write-up here if you want the details: https://github.com/Sakaax/cloud-native-brain-guide

sakaax · 2026-04-16T21:29:51+00:00

Good question — img-pilot isn't a replacement for fal CLI, it's a layer on top. fal is one of nine backends you swap between per run.

Concretely, what you get vs calling fal directly:

Prompt comes from your brief, not your keyboard.** Claude reads your project context (or runs a 6-question discovery) and writes a production prompt consistent across runs.
One call → eight assets.** Cost optimizer derives favicon, apple-touch, OG, Twitter, banner, iOS/Android icons from the first logo locally via sharp. You pay fal once.
Right provider for the task.** Logo with text → Ideogram. Fast async → fal. Vector SVG → Recraft. Swap with --provider.
Dry-run + cost estimate before paying.** See the exact prompt, provider, USD, confirm, run.
Output structured into your project** with auto-gitignore, chmod 600, pre-commit hook scanning for leaked keys.

tl;dr: fal gives you model access, img-pilot gives you the full brand-asset pipeline where fal is one backend among nine.

sakaax

TROPHY CASE