· 7 min
A newborn app, with a newborn
ProbaBaby reached the App Store a week before our baby was born. Becoming our own app’s users, and how our nights rewrote the roadmap.
Part 4 of 7 in the Building ProbaBaby series.
ProbaBaby went live on the App Store on 14 May 2026. About a week later our baby was born. From then on its two most demanding users lived under one roof: my wife Esma, its first user and daily tester, and me.
This part is about building a newborn app while living with a newborn. It’s the part no roadmap had.
| when | the app | our life |
|---|---|---|
| 30 Dec 2025 | pregnancy tracking | |
| 7 Jan 2026 | the postpartum module, the Watch app, widgets | |
| 14 May | live on the App Store | |
| ~1 week later | the flow for ending a pregnancy | our baby is born |
| first week | back to the iPhone’s Clock app for feeds | |
| 4 Jun | Critical Alerts declined; AlarmKit ships | an alarm that rings on a locked, silenced phone |
| ~3 months on | the period tracker, its own module | my wife’s period comes back |
The diagram, step by step:
- 30 Dec 2025: our own pregnancy turns a face predictor into a pregnancy tracker.
- 7 Jan 2026: the postpartum module, the Apple Watch app and the widgets.
- 14 May: ProbaBaby goes live on the App Store.
- About a week later our baby is born. That week’s commits: ending a pregnancy in the app.
- In the first week, we stop trusting the app’s own feed reminder and go back to the Clock app.
- 4 Jun: Apple declines Critical Alerts. An AlarmKit version ships the same day.
- About three months after the birth, my wife’s period comes back. The app gets a period tracker.
From a prediction to a pregnancy
ProbaBaby began as a product idea: a baby-face predictor with real genetics behind it (Part 1). Our own pregnancy is what turned it into something else, and in the commits you can see the product following our life one stage at a time. Pregnancy tracking arrived on 30 December 2025. The postpartum module, the Apple Watch app and the widgets came on 7 January 2026; family sharing, so two parents could follow the same baby, on 11 January; birth preparation on 16 January. By the end of January the README already said “From a parent, for parents”.
The predictor is still in the app, and it’s still the only thing that costs money. Everything else is free.
The spring before
The spring was App Review. Version 1.0 was rejected twice, over a permissions screen at launch that sent people to Settings and a bug that kept throwing the reviewer back to the privacy notice. The resubmission on 24 April also had to answer for CallKit in China, coupons that granted credits outside in-app purchase, explicit consent before photos went to Google’s Gemini, and two long sets of questions about face data and the TrueDepth camera. The TestFlight build counter passed 77 before the first release.
Launch week, birth week
The first release went out on 14 May. For the next few days the repository shows one or two commits a day. Then, in the week our baby was born, the commits are about exactly what we were living through: the flow for ending a pregnancy, “My baby is born” or “I’m no longer pregnant”, and the two-tier modal policy from Part 3. One of those mornings, at 05:41, a commit added a push to the partner’s phone when a labour session starts.
May 2026 has 542 commits and June 360, my two busiest months on the project. My single busiest day, 67 commits, came about a week after the birth: the baby module, a summary for the paediatrician, Live Activities, mom recovery and feeding reminders.
From that week on, the roadmap was whatever hurt at night. The working rule: if a pain hit us, it was hitting every other newborn parent too.
An alarm we didn’t trust
In the first week, my wife and I stopped trusting ProbaBaby’s own next-feed reminder and went back to the iPhone’s Clock app. A notification is one short sound. The silent switch mutes it, and the app’s own loud alarm stopped the moment the phone locked.
The obvious way to ring through the silent switch was Apple’s Critical Alerts entitlement, so I applied on 30 May. On 4 June Apple said no: critical alerts are for “a very restricted number of purposes”.
So I looked elsewhere. iOS 26 had added AlarmKit, which schedules a real system alarm: it rings through silent mode and Focus on a locked phone, shows a full-screen Stop button, and needs no special entitlement. The AlarmKit version shipped the same day as the rejection and rang on a locked, silenced phone. For young babies, with the wake alarm switched on, it also drives a backstop that rings again every ten minutes, up to twelve times, until a feed starts. Its one limit: the volume follows the phone’s alarm slider, and the app can’t make it louder.
| silent switch | locked phone | special entitlement | |
|---|---|---|---|
| a notification, one short sound | mutes it | — | — |
| the app’s loud alarm | — | stops the moment it locks | — |
| Critical Alerts | rings through | — | declined, 4 Jun |
| AlarmKit | rings through, and through Focus | rings, with a full-screen Stop | none needed |
The diagram, step by step:
- A notification is one short sound, and the silent switch mutes it.
- The app’s own loud alarm stopped the moment the phone locked.
- Critical Alerts ring through the silent switch, but need Apple’s entitlement. Declined on 4 June.
- AlarmKit, new in iOS 26: a real system alarm, through silent mode and Focus, on a locked phone. No special entitlement.
Two phones, one baby
Most feeds in our house are logged on my wife’s phone. On 3 June I reported that the next-feed reminder kept going off on my phone after the feed was already logged on my wife’s. Now a feed logged on any phone in the family resets the reminder on the other phones. Later the same idea reached the timers: either parent can stop a session the other one started.
Then the Live Activities. When one parent starts a feed, the other parent’s lock screen shows it. In June that mirror either never appeared or never went away, and a lock screen could keep counting a feed or a nap hours after it had ended. An automated audit confirmed 28 of 30 suspected problems and blamed authentication between the database and the push functions. Then a look at the live database showed that the table that starts the whole chain had zero rows, ever. Session records reached the server only through an offline queue that had delivered nothing in two weeks, while feeds synced through a different path, so everything else looked healthy. The audit was wrong.
Fixing that exposed the next layer, and the next: tokens saved in uppercase and looked up in lowercase; a test token filed as a production one; a sleep session whose ID lived only in memory, which matters because a night’s sleep outlives the app’s process. The lesson: when the database disagrees with the audit, believe the database.
The quiet version of the same job is the “last fed” Live Activity, a card on the lock screen that says when the baby last ate, without opening anything. My wife relies on it. It exists because silent pushes are throttled to two or three an hour and dropped after a force-quit, so before it the honest answer was “open the app to see the last feed”.
Designing for the worst day
Until the week of the birth, there was no way to end a pregnancy in the app. Re-engagement pushes quoted the week and the baby’s size as a fruit. After “My baby is born”, kick-counter and weight reminders kept firing, and pregnancy supplement reminders kept ringing on both our phones after our own baby arrived.
A pregnancy app has to be designed for the day the pregnancy ends, in either direction. The end state now has two paths. A birth moves the family on to the newborn side of the app. A loss never creates a baby, and silences the pregnancy reminders, widgets and Live Activities. A later audit, fanned out across 116 agents, built in one rule: only the active module’s notifications and Live Activities are delivered, apart from deliberate exceptions such as supplement reminders and family alerts. The rating prompt and the engagement cards stay silent after a pregnancy loss, after a high score on the postnatal depression check-in, and while someone is reading emergency information.
- the pregnancy endsuntil the week of the birth, the app had no way to say so
- “My baby is born”the family moves on to the newborn side“I’m no longer pregnant”no baby is created; pregnancy reminders, widgets and Live Activities go silent
- only the active module speaksits notifications and Live Activities, apart from deliberate exceptions
The diagram, step by step:
- Until the week of the birth, there was no way to end a pregnancy in the app.
- A birth moves the family on to the newborn side of the app.
- A loss never creates a baby, and silences the pregnancy reminders, widgets and Live Activities.
- A later audit built in one rule: only the active module’s notifications and Live Activities are delivered.
The period tracker
About three months after the birth, my wife’s period came back, and the app needed somewhere to track it. My wife reviewed the first version and said it didn’t belong inside Mom Recovery, so it got its own Home card. A day later I made it a full module with five tabs, sharing one engine with the Planning module, so the data carries over. The fertile-window view only appears after two regular postpartum cycles, with a plain note that it isn’t a contraceptive. Its Turkish name, Regl Takibi, is the phrase my wife actually uses.
Twins, by surprise
We have one baby. But in June, v1.0.3 shipped per-baby Home cards, Live Activities and widgets, with a short note in What’s New. In August, twin families started arriving: over four weeks, 72% of new pregnancy profiles were for multiples, against a natural rate of about 1.2–1.5% of deliveries. So v1.0.4, on 4 September, became the twins release, and the app’s real growth started there. That story is Part 6.
What it changed in how I work
The newborn weeks changed engineering decisions, too. One rebuild plan deferred a sync-engine refactor because new sync bugs during the newborn period would have been, in its words, poor calculus. And on 22 September I chose polish over new features, because my capacity was limited. A 3D model of the baby in the womb went on the shelf that day.
Where it is now
486 people have signed up. About 110 use the app every day, 205 every week and 360 every month. Total revenue so far is $32, and servers and the website cost about $75–100 a month. Tracking, tools, PDF reports, widgets, the Watch app and family sharing are free; only the optional prediction uses credits, and supporter subscriptions unlock nothing. The supporter page says it the way I mean it: “I’m a parent too, and I’ve spent almost a year building ProbaBaby so that every family can use it — free, with no ads and no investors.”
What we want from it hasn’t changed since those first nights. We want to solve real pains. We don’t want to build an app just to earn money.