Five Days Later: The Road to Launching hora Calendar

Five days after I first wrote about hora, the app had crossed an important line. I was no longer opening it to admire a prototype. I was opening it because my next meeting was there.

That felt like progress. It also made the remaining work harder to ignore.

The calendar worked on my Mac. Launching it for other people meant proving that it could survive accounts, network conditions, and schedules I did not control.

This is the state of the project as I recorded it on March 31, 2026. hora eventually reached the Mac App Store on June 30. Looking back, this was the moment the project stopped being mainly about features and became a reliability exercise.

For the earlier context, start with why I built hora and the first 48-hour sprint.

The daily driver test changed the work

By this point, hora could handle the calendar I used every day:

• Multiple Google accounts and calendars.
• Day, week, and month views.
• Event creation, editing, dragging, and resizing.
• A menu bar agenda and Pomodoro timer.
• Keyboard commands and availability sharing.
• Native notifications and a local calendar cache.

The feature list made the app sound close to finished. My own usage made the opposite case.

Once the app became my daily driver, small failures stopped being interesting bugs. A duplicate event was no longer a curious edge case. It was two conflicting answers to where I needed to be. A silent sync failure meant the app could no longer be trusted.

That changed the definition of launch readiness.

The work nobody sees in a launch screenshot

The last days of March went into the parts of the app that should disappear when they work.

Retry without hiding failure

Google Calendar requests can fail because of a connection drop, a server error, or a rate limit. The app gained exponential backoff for retryable network errors and API responses such as 429, 500, and 503.

The goal was not to retry forever. It was to distinguish a temporary failure from a state that required the user or a full synchronization to intervene.

Paginate real calendars

My development account did not contain enough history to expose every pagination path.

The app needed to keep requesting pages for both full event fetches and incremental changes, then persist the final synchronization token. Google's incremental sync documentation is explicit that a new sync token may only arrive on the last page.

Ignoring that detail works until it does not. Large calendars are very effective at finding shortcuts in sync code.

Make local actions reversible

Undo and redo arrived for creating, editing, and deleting events.

This was more than wiring Cmd+Z to an in-memory change. The local optimistic update, the Google API request, and the eventual synchronized result all had to agree about what had happened.

Prepare the app for distribution

I added the privacy manifest, reviewed entitlements and permission descriptions, corrected StoreKit subscription states, and separated TestFlight behavior from the future paid release.

The app also started synchronizing calendars concurrently instead of waiting for each one in sequence. That made multi-calendar accounts faster, but it increased the need for clear isolation between accounts and local writes.

This was the kind of week where a smaller diff could represent more product progress than a new screen.

Google OAuth verification became the external gate

The largest launch dependency was no longer in the Xcode project. It was Google OAuth verification.

hora requests access to Google Calendar data on behalf of the signed-in person. Public apps that request sensitive scopes may need Google's review before launch. Google's current OAuth verification guide explains the scope categories and requirements.

While the production configuration was unverified, new users could encounter an "unverified app" warning and the project was subject to a user cap. Google documents both behaviors in its unverified apps guidance.

I could keep developing and testing. I did not want that warning to become somebody's first impression of the product.

That waiting period was frustrating because there was no code change that could make the queue move faster. It was also useful. External review forced the website, privacy policy, scopes, consent screen, and product description to tell the same story.

TestFlight made the app real in a different way

The first internal TestFlight builds were live.

Installing a build through Apple's distribution path feels different from running it in Xcode. Signing, entitlements, widgets, purchase environments, and account state all have a chance to behave differently.

Apple positions TestFlight as a way to distribute beta builds, manage testers, and collect feedback before App Review. At this stage I kept the TestFlight experience focused on testing the calendar rather than evaluating a paywall.

The build was usable, but external testing still required the surrounding product to be ready: test instructions, a support route, privacy language, and a way to understand what happened when something failed.

The question I was asking too broadly

In the original version of this update, I asked readers which features would make hora their default calendar app.

My list included an iPhone and iPad companion, natural-language event creation, smarter scheduling, ICS support, and deeper Google Workspace integrations.

It was an enthusiastic question, but not a very good research prompt. People answer broad roadmap questions with broad wishes.

The useful feedback arrived when I asked about a moment instead:

• What do you do just before a meeting?
• Where does Google Calendar on Mac slow you down?
• Which event changes do you not trust another app to make?
• What makes you return to the browser?

Those questions produced bug reports and workflows I could build around. They also made it easier to say no to features that sounded impressive but did not strengthen the core product.

The roadmap was a direction, not a contract

At the end of March, the planned order was:

1. Finish the Mac launch and reliability work.
2. Explore a native iPhone and iPad companion.
3. Add focused intelligence where it improved planning or meeting context.
4. Go deeper into useful Google Workspace workflows.

That sequence captured the ambition, but it was not a promise that every idea would ship unchanged.

The immediate product still had to earn the right to expand. A native Mac calendar that could not reliably synchronize recurrence, invitations, and large accounts did not need a more ambitious roadmap. It needed fewer surprises.

What happened next

Two days later, I published the week one breakdown with the commit count, the issue list, and the parts of the app that were still rough.

The first public beta followed in April. Real calendars exposed more work in recurrence, event identity, performance, and synchronization than any private checklist could. The first public beta retrospective tells that part of the story.

hora 1.0 eventually shipped on June 30. The launch took longer than the first burst of building, which is exactly what a calendar app needed.

The visible product began in a few intense days. Trust arrived one edge case at a time.

Try hora Calendar on the Mac App Store