Week One Building hora: 107 Commits Later
A candid snapshot of hora's first ten days: 107 commits, three Swift packages, 21 resolved issues, useful workflows, and plenty still rough.
Maciej Szamowski7 min read
I called this "week one" when I first published it, but the numbers covered the first ten elapsed days of work, from March 23 through April 2, 2026.
That detail is a useful correction. Early-stage projects compress time. A week becomes a sprint, sleep becomes an implementation detail, and a commit graph can make all of it look more deliberate than it felt.
This is the snapshot I recorded then, with the hindsight I have now.
If you are joining the story here, start with why I built hora, then read what happened during the first 48-hour sprint.
The first ten days in numbers
My April 2 snapshot contained:
- 107 commits across the app and website repositories.
- 87 Swift files and roughly 15,800 lines of Swift.
- 3 local Swift packages: HoraCore, HoraGoogleAPI, and HoraSync.
- 9 interface languages.
- 2 CI configurations across Xcode Cloud and GitHub Actions.
- More than 21 tracked issues resolved.
- 3 blog posts, a landing page, and the privacy and terms pages needed for OAuth review.
- A version jump from 0.0.1 to 0.5.1.
March 31 and April 1 were the busiest commit days. That was when distribution work, modularization, and a dense run of issue fixes collided.
The numbers are historically useful. They are not a quality score.
Fifteen thousand lines can mean a product is taking shape. It can also mean the architecture is still moving quickly enough to create tomorrow's cleanup. One of the largest changes that week added three packages while deleting and relocating much of the old monolithic target. A line count cannot distinguish growth from a boundary finally becoming clear.
What the app could actually do
A build log should separate shipped behavior from impressive-sounding infrastructure.
By April 2, these workflows were useful enough that I relied on them:
Create and edit Google Calendar events
I could click an empty slot, create an event, and see the local calendar update immediately while the request went to Google. Dragging, resizing, deleting, and undoing changes all existed.
The optimistic interface made the app feel fast. It also created a harder engineering obligation: if Google rejected a request or returned a different result, the local state had to reconcile without silently inventing a calendar history.
Share availability
The availability sheet queried Google's FreeBusy endpoint, turned busy intervals into open slots, and copied a readable list to the clipboard.
This remained one of my favorite early features because it closed a complete loop. It started with real calendar data and ended in the email or chat where somebody had asked for time.
Google's FreeBusy endpoint returns busy ranges for selected calendars. hora handled the chosen working hours, free-slot calculation, and output locally.
Check the day without opening the full window
The menu bar view showed upcoming events and a countdown. A WidgetKit extension put today's and tomorrow's agenda on the desktop. Both made the project feel like a Mac app rather than a calendar grid inside a window.
Work with more than one Google account
Multiple accounts were supported, but they also produced some of the week's most instructive bugs. Calendar and event identifiers that looked unique inside one account could collide when shared calendars appeared across accounts.
The fix was not another conditional in the interface. Identity needed to include enough account context throughout storage and synchronization.
The issue loop mattered more than the feature count
The most useful loop of the week was not build, announce, repeat. It was:
- Use hora for a real day.
- Write down the moment it behaved strangely.
- Reduce that moment to a reproducible issue.
- Fix the underlying state, not only the visible symptom.
- Use it again.
That process found problems in recurring-event deduplication, menu bar rendering, window restoration, invitations, multi-calendar event identity, drag behavior, and large sync histories.
At the start of the week, I would often describe a feature as "working" once the happy path completed. By April 2, that word required more questions:
- Does it work for a shared calendar?
- Does it work for a recurring event?
- Does it work after the Mac wakes from sleep?
- Does the menu bar show the same answer as the main window?
- Can the user undo it?
- What happens when Google returns a retryable error?
That is where a calendar app starts becoming trustworthy.
Splitting the app into three Swift packages
On April 1, the project moved from one growing target into three local packages:
- HoraCore for shared models, API response types, and utilities.
- HoraGoogleAPI for authentication-aware Google Calendar, People, and FreeBusy services.
- HoraSync for the repository, synchronization manager, and event operations.
The main app and widget could depend on the pieces they needed without turning every type into global project state.
This was not architecture for a slide deck. The package boundaries followed pressure already visible in the code. Models needed to be shared with widgets. Network services needed token injection. Synchronization had grown large enough that UI concerns were making it harder to reason about failures.
The split did not solve every problem. It made the next problem easier to locate.
Nine languages, with an uncomfortable caveat
The app included English, Polish, German, Spanish, French, Italian, Japanese, Portuguese, and Simplified Chinese.
Most of the first-pass translations were generated with AI.
I was transparent about that because "supports nine languages" sounds much more complete than the actual state. The strings existed and the layouts could be tested, but calendar vocabulary, tone, pluralization, and natural phrasing still needed native review.
Localization was useful this early because it exposed hard-coded text and layout assumptions. It was not finished simply because a string catalog had nine columns.
That distinction still matters to me. Shipping a machine translation can start a feedback loop. Presenting it as polished localization ends the conversation too early.
The CI story was less tidy than I first wrote
Xcode Cloud handled builds and TestFlight distribution. A GitHub Actions workflow existed for pull-request testing too.
The original post made that sound like two healthy pipelines working together. In reality, the GitHub workflow was disabled on April 1 because the required macOS runner was not available for that configuration.
So the honest state was:
- Xcode Cloud was the active distribution path.
- GitHub Actions expressed the intended test path, but could not yet be treated as a reliable green check.
- Local testing and real TestFlight builds still carried more weight than I wanted.
This is a small correction, but it captures why build-in-public notes should age honestly. A workflow file in the repository is not the same as a functioning safety net.
What was still rough
The app was usable. It was not calm yet.
Drag and resize interactions still had visual and snapping issues. Large histories needed more performance work. Google OAuth verification was still in progress. Recurring events and shared-calendar identity kept producing cases that did not exist in my simplest test account.
The menu bar and widgets were useful, but every additional surface created another place where stale state could appear.
This is why I no longer describe the week as "a solid foundation" without qualification. The foundation existed. Parts of it were still wet concrete.
What the numbers did not show
The most important result was not 107 commits or version 0.5.1.
It was that hora had become good enough to reveal its own weaknesses through daily use. I no longer needed to imagine what a Google Calendar user might do. I could reach for the app, notice friction, and follow it into the code.
That loop carried the project into TestFlight and then the public beta. The road-to-launch update captures the external gates at the time. The first public beta retrospective shows what happened when far more varied calendars arrived.
hora eventually reached the Mac App Store on June 30, 2026. The release was built on this fast first stretch, but it was shaped by the slower work that followed.
