What I Wanted hora's First Public Beta to Prove
A founder note prepared before hora's first public TestFlight beta: what version 0.6 shipped, what I asked testers to break, and what changed next.
Maciej Szamowski6 min read
On Friday, April 24, 2026, hora Calendar left my own Mac and entered public TestFlight.
I originally wrote this note two days before that happened. The app is now available on the Mac App Store, so the instructions to join the beta are no longer useful. The moment still is. Version 0.6 was the first honest test of whether the native Google Calendar client I had been building could survive calendars, accounts, and habits that were not mine.
This is the launch note rewritten as a record: what the first testers received, what I wanted them to challenge, and which assumptions did not last the week.
What version 0.6 actually was
The first public build was deliberately narrower than the roadmap around it.
It could create, edit, move, resize, and delete Google Calendar events. It understood recurring rules, supported multiple Google accounts, and provided Day, Week, and Month views. A menu bar window kept the next meeting close, and a desktop widget deep-linked into the app.
That sounds like a normal calendar feature list now. At the time, each part carried an unanswered question:
- Would optimistic event edits stay consistent after Google sent the next update?
- Would recurring exceptions behave across calendars created by different clients?
- Would the app remain responsive on an account with years of history?
- Would a menu bar countdown still be correct after a meeting moved elsewhere?
- Would a widget tap land on the event instead of merely opening the app?
The beta was not a preview of every idea I had. It was a test of those promises.
Why I built it as a native Mac app
hora was written in Swift and SwiftUI because the Mac-specific surfaces were not extras. They were the reason to build the product.
I wanted keyboard navigation that behaved like part of the app, not a browser tab. I wanted events in the menu bar, WidgetKit on the desktop, familiar window behavior, and a local cache that made the schedule immediately available.
I also wanted Google Calendar to remain the source of truth. hora connected directly to Google's calendar APIs rather than asking users to migrate their events into another planning service.
That decision created a clear boundary. The beta supported Google Calendar, not iCloud, Exchange, or general CalDAV accounts. If someone needed every provider in one window, hora was not the right beta for them. The later Google Calendar API vs CalDAV article explains why I kept that boundary.
What shipped in the first beta
The useful version of the 0.6 feature list looked like this:
| Workflow | What testers could do |
|---|---|
| Calendar views | Work in Day, Week, and Month views |
| Event editing | Create, edit, drag, resize, and delete Google events |
| Recurrence | Edit recurring series and handle end dates |
| Accounts | See personal and work Google accounts together |
| Meetings | Detect Google Meet, Zoom, and Microsoft Teams links |
| Menu bar | Check the next event and join a call |
| Desktop | View upcoming events in a WidgetKit widget |
| Sync | Receive Google Calendar changes without waiting for a long polling interval |
| Availability | Copy open slots from the current schedule |
The build also shipped in nine languages. English and Polish were the only versions I could judge myself. I was explicit that the remaining translations needed native review, because "technically translated" is not the same as comfortable product copy.
What was still only a plan
The original post had a large 0.6 versus 0.7 table. It mixed shipped behavior with a roadmap that included in-app calendar management, Google preference import, natural-language event creation, focus planning, and generated availability messages.
Some of those ideas shipped. Others changed shape after testing. That is why I no longer like presenting an early roadmap beside a release as if both columns have equal certainty.
A shipped feature is evidence. A planned feature is a hypothesis.
The current product includes Quick Add and Focus Time, but they were refined through later beta builds rather than appearing exactly as described in April. The history of what reached 1.0 is in the hora Calendar 1.0 launch note.
What I asked people to test
I did not need a group of people clicking every control once. I needed them to use hora as their calendar for a normal day.
My testing request had five priorities.
1. Trust the result after sync
Create an event, move it, edit a recurring occurrence, and respond to an invitation. Then check Google Calendar elsewhere. The local animation did not matter if the server state disagreed five seconds later.
2. Notice every moment of hesitation
A calendar is opened repeatedly and often in a hurry. Scrolling, opening an editor, switching a week, or joining a call should not feel like the app is thinking.
3. Use more than one account
My own setup was predictable. Work and personal accounts with different permissions, shared calendars, and old OAuth grants were where the real integration would be tested.
4. Keep the menu bar running all day
The next-meeting countdown was one of the smallest interfaces and one of the most visible. A stale label there could damage trust faster than a bug hidden deep in settings.
5. Tell me when Chrome was still necessary
The most valuable report was not "this button is broken." It was "I had to return to Google Calendar in the browser to do this." That exposed missing workflows rather than isolated controls.
The rough edges I knew about
Before launch, drag-to-resize still felt jumpy at some zoom levels. Accounts with very large event histories took longer to paint than I wanted. Several translations were functional but awkward.
I listed those problems because pretending a beta is polished does not make feedback better. It only makes testers wonder whether the behavior they saw is worth reporting.
What I did not anticipate was more useful. Large stores exposed main-thread SwiftData work. Real OAuth histories produced missing-scope errors. Google API quotas behaved differently with several active accounts. The week-one retrospective covers those failures and the first patch cycle.
What public beta changed for me
Before April 24, I could test whether a feature worked. Public beta tested whether the app recovered.
What happens after a token expires? After a recurring event is deleted twice? After the network returns? After a calendar contains 3,000 events instead of 30? After the app launches from a widget into a view that does not exist yet?
Those questions moved the product from feature development toward reliability work. The beta made the roadmap less tidy and the app much better.
hora eventually reached the Mac App Store on June 30, 2026. The public beta is history, but the testing principle survived: use the app in a real calendar, then follow every place where it makes you reach for the browser.
If you use Google Calendar on a Mac and want to try the release that grew from those builds, download hora Calendar from the Mac App Store.
