Built Because It Was Missing
I wrote an iOS app called Calendar Countdown. It exists because nothing else solved a simple problem cleanly and it was an itch I needed to scratch.
My fiancée and I used "Up Ahead" to display countdown widgets on our iPhones of upcoming events. It worked, but it forced everything into its own system. No sync with our actual calendars. Every date had to be entered again. Every change had to be updated twice.
At the same time, our real source of truth was already the built-in iOS Calendar. We had the same events there. We also share a calendar between us. The data already existed, was already maintained, and was already synced across devices.
The friction came from duplication:
- Add event to calendar
- Re-add it to the countdown app
- Update it in both places if there was a change
- Keep them in sync manually
That is unnecessary overhead for something that should be passive.
So the constraint became obvious: stop creating another system. Use the one that already works - Apple's EventKit can be used to pull the information.
Calendar Countdown reads directly from existing calendars. No parallel data model. No re-entry. No de-sync. The countdown is just a different view of what’s already there.
Select a calendar. The app converts every event into a countdown. The widget reflects the same data. Changes propagate automatically because the source is unchanged.
This removes the maintenance layer entirely. The calendar remains the single source of truth.
The design decisions follow from that:
- No accounts
- No syncing layer
- No import/export
- No duplication
- No subscriptions
- No ads
The app does one thing: interpret calendar data as time remaining.
The result is simpler than any alternative I've been able to find. The problem was never “countdowns.” It was redundant data entry.