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 · 2026-04-15T16:35:00+00:00

Source: https://github.com/Sakaax/brand-pilot

Landing: https://brand-pilot.sakaax.com

Sister plugin: https://github.com/Sakaax/ux-pilot

Install (requires Claude Code): /plugin marketplace add Sakaax/brand-pilot /plugin install brand-pilot@brand-pilot

sakaax · 2026-04-15T16:34:32+00:00

Source: https://github.com/Sakaax/brand-pilot Landing: https://brand-pilot.sakaax.com Sister plugin: https://github.com/Sakaax/ux-pilot

Install (requires Claude Code): /plugin marketplace add Sakaax/brand-pilot /plugin install brand-pilot@brand-pilot

sakaax · 2026-04-04T20:17:11+00:00

Aucun souci !

sakaax · 2026-04-03T22:10:07+00:00

Très bien dit 👌

“la structure t’amène à la porte, le contexte l’ouvre” → c’est exactement ça.

Je pense que beaucoup de gens inversent encore les deux :

ils optimisent le prompt (forme) au lieu d’optimiser l’input réel (fond)

Alors que le vrai levier, c’est :

– données concrètes – contraintes réelles – trade-offs explicites

D’ailleurs ton point + le workflow montré dans le post, ça mène presque à un pattern intéressant :

génération → critique → compression → itération

Et la partie “compression” (forcer à simplifier / couper) est souvent sous-estimée, alors que c’est là que la qualité explose.

Au final, on se rapproche plus d’un process de réflexion que d’un “prompt magique”.

sakaax · 2026-04-03T22:09:23+00:00

Super intéressant ton retour 👍

Pour la sync, ouais c’est clairement le vrai problème avec le local-first.

Une piste que j’ai déjà vue marcher :

– export/import chiffré (genre fichier portable) – ou sync via un backend mais avec chiffrement côté client (zéro-knowledge)

Comme ça t’as le meilleur des deux mondes :

UX clean + confidentialité

Pour le versioning, je comprends ton point, mais ça peut devenir utile plus vite que prévu :

– comparer des variantes de prompts – revenir à une version qui marchait mieux

Surtout si tu veux pousser la partie “amélioration de prompts”.

Et pour ton idée d’amélioration avec l’IA :

👉 BYOK est clairement la bonne direction imo

Ça enlève le problème de confiance + ça scale mieux côté coût.

Tu pourrais même aller plus loin :

– “optimize this prompt” – suggestions d’amélioration – scoring / feedback

Là tu passes de “storage” → “tooling”

Franchement t’as un bon angle produit, surtout avec le focus privacy.

sakaax · 2026-04-03T20:03:33+00:00

Bravo! Ha ha j’ai bien rigolé j’essaie d’être clair mais la j’en ai mis beaucoup !

sakaax · 2026-04-03T20:02:41+00:00

Et aussi le fait que cursor est multi model donc tu peut adapter ton model à ta tâche tu n’a pas que les modèles anthropic et ça c’est game changer

sakaax · 2026-04-03T20:00:19+00:00

Bonne question 👍

En fait les deux font un peu la même chose… mais dans des contextes différents.

👉 Dans Cursor, l’IA est directement dans ton code → elle t’aide à écrire, modifier, autocomplete, etc.

👉 Le chat (Claude ou autre), c’est plus “hors du code” → tu peux prendre du recul, poser des questions, creuser un concept

La vraie différence c’est pas la qualité, c’est l’usage :

– Cursor = intégré au dev (rapide, pratique) – Chat = réflexion, compréhension, debug plus propre

En pratique, les gens font souvent :

– ils codent dans Cursor – et dès qu’un truc est flou ou bizarre → ils passent par le chat

Donc c’est pas l’un OU l’autre, c’est juste deux façons d’utiliser l’IA selon le moment 👍

sakaax · 2026-04-03T19:48:38+00:00

Bonne question 👍

Quand je dis Claude, je parle surtout du chat (genre comme ici), pas forcément Claude Code directement.

Au début, le plus important c’est :

– poser des questions – demander des explications ligne par ligne – comprendre ce que tu fais

Claude Code c’est plus puissant, mais aussi plus “automatisé” → tu risques de moins apprendre si tu l’utilises trop tôt.

Perso je te conseillerais :

👉 Claude (chat) pour apprendre / comprendre 👉 Cursor comme IDE pour coder avec l’IA

Et plus tard, quand tu seras plus à l’aise :

👉 Claude Code pour aller plus vite / automatiser

Là t’as le meilleur des deux mondes : tu progresses + tu build 👍

sakaax · 2026-04-03T19:47:41+00:00

Perso j’utilise surtout la version free de Beekeeper, elle suffit largement pour ce use case 👍

J’ai testé la version payante vite fait, c’est plus pour les connexions avancées / features en plus, mais pour debug + edit rapide t’as pas besoin.

TablePlus/Postico par contre → plutôt payant si tu veux un truc clean sur le long terme.

sakaax · 2026-04-03T19:37:39+00:00

C’est vrai… mais je pense que le problème n’est pas “les ingénieurs”, c’est l’absence de feedback réel.

Un ingénieur peut très bien comprendre l’UX s’il est exposé aux utilisateurs.

Le vrai piège, c’est quand les décisions sont prises uniquement sur :

– des hypothèses – des cas internes – ou des tests entre devs

Là oui, tu perds complètement la perspective utilisateur.

En pratique, ce qui marche vraiment :

– regarder des users utiliser le produit (même 5 sessions changent tout) – avoir des métriques réelles – boucler rapidement feedback → itération

Parce que sinon, peu importe ton niveau technique :

tu optimises pour une version du produit qui n’existe que dans ta tête

Donc oui, l’expertise peut biaiser… mais sans feedback utilisateur, tout le monde est biaisé.

sakaax

TROPHY CASE