Engineering Korivo Without Accounts or a Cloud

01 / Constraint

Privacy as an architectural constraint

Privacy informs the core design of Korivo. If we don’t operate a central cloud service, we can’t depend on one for identity, synchronization, conflict resolution, migrations, or recovery. The app has to solve those problems on devices controlled by the user. That means Korivo had to establish several principles:

• Core functionality shouldn’t require a Korivo account.
• A remote Korivo database shouldn’t store personal health data.
• Records remain portable and inspectable rather than trapped in an opaque service.
• Losing access to Korivo’s infrastructure shouldn’t make a person lose access to their history.
• Our business shouldn’t force users into a perpetual subscription.

02 / Coordination

In most applications, the backend does a lot of the heavy lifting

A conventional application backend does much more than store rows. It provides a global ordering of events. It decides which edit wins. It records deletions. It serializes concurrent writes. It runs migrations. It creates backups. It tells every client which version is current.

Remove that backend and every device can possess a different, locally reasonable view of reality.

A phone might record a workout while a desktop edits the program that produced it. One device might delete a meal while another modifies an older copy. A sync process can be interrupted after writing the record but before advertising the change.

Putting JSON files in a shared folder is pretty easy. Making sure they behave like a database is much harder.

03 / Representation

Using portable records and your cloud storage

Korivo represents user information as typed, portable records organized into a well-defined folder structure.

The format covers more than just workouts. It includes programs, routines, diets, meals, sessions, cardio, exercises, biometrics, observations, supplements, historical diet targets, templates, and application state.

A portable representation gives us things a server-owned database doesn’t:

• Users retain a comprehensible copy of their information.
• Desktop and mobile applications don’t need to route anything through Korivo infrastructure.
• Backups don’t depend on an account remaining active.

04 / Convergence

Conflict resolution without a central referee

In a local-first system, conflicts can’t be avoided.

Korivo uses metadata to resolve those conflicts. A modified timestamp establishes the primary order, and device identity provides a stable tie-break when versions have the same timestamp. Two clients have to independently make the same decision about which copy to keep.

Deletion makes this harder. If one device removes a file, another device can’t distinguish “intentionally deleted” from “temporarily missing.” Korivo records deletions as tombstones so other devices retain evidence of the deletion instead of resurrecting an older copy. The system also has to heal duplicated copies, preserve local work, and recover from interruptions without pretending partial success means everything is in sync.

You won’t notice any of this when using Korivo, of course. We’ve put in the engineering work so it feels seamless and no different from a typical app.

05 / Interoperability

Two implementations are a disagreement waiting to happen

Korivo currently has an iOS app written in Swift and a desktop app written in TypeScript/Tauri.

One non-negotiable was that the desktop app work not just on Mac, but also on Windows and Linux. Both apps read the same JSON records, but they are parallel implementations. That creates plenty of room for disagreement.

One app might tolerate a missing field while the other rejects it. One date parser might accept a value that another rejects.

Usually the solution to bad behavior is tests. But unit tests written independently for each platform can’t prove both apps are doing the same thing. They only prove that a particular app is doing what it was written to do.

Korivo uses shared fixtures to address this. These define the shape of data on disk, our edge cases, how partitions should behave, and how to decide conflicts. Every client, whether written in Swift, TypeScript, or Rust, is tested against the same specification.

06 / Shared core

One core, multiple native applications

Maintaining all the synchronization and domain logic across multiple implementations and languages stops scaling pretty quickly, especially with a small team.

We want to bring Korivo to Android. That wasn’t on the agenda originally, but leaving Android users out indefinitely isn’t where we want to end up. We can’t make promises, but we’ve decided to invest in the foundational work that makes it possible.

We’re consolidating Korivo’s codecs and synchronization logic into a core Rust library. UniFFI lets us generate bindings for Swift and Kotlin, while the desktop application can call the same library through its Tauri boundary. This gives us one strongly typed implementation and makes it much easier to add new platforms.

Each app can then focus on what can’t be shared: presentation, accessibility, lifecycle, and integration with devices.

The existing apps remain authoritative while the Rust core runs alongside them and compares outputs. Differences are recorded, but the new implementation can’t change user data until it proves that it behaves identically.

Joel Spolsky famously called full rewrites one of the things you should never do. We agree. We’re building the Rust core because maintaining these rules separately in every client eventually becomes the riskier option.

07 / Tradeoffs

But why not use a normal cloud sync service?

Using a managed cloud service would make much of this simpler. Accounts, server-side recovery, telemetry, and scalability all have familiar managed solutions with a lower initial implementation cost.

Those solutions come with consequences, though:

• The company becomes the custodian of your potentially sensitive data.
• Product economics push the company toward recurring billing.
• Export and portability become secondary features instead of being intrinsic.
• Shutting down the service means users lose access to their data.

Korivo still has to store your data somewhere if you want it available across multiple devices, but cross-device synchronization is optional. If you enable it, you choose the storage provider. Local-first doesn’t mean infrastructure-free or free from security concerns. It means Korivo doesn’t need to insert itself into the middle of the relationship or know anything about your data.

Building Korivo this way aligns our architecture with our business model. Years ago, you bought software and owned it forever. We miss those days. We don’t think you should lose your data just because you don’t want to pay us forever.

08 / Reliability

The difficult parts are mostly invisible

As a user, you don’t need to understand manifests, tombstones, canonical encoders, or partition ledgers. You just log a workout on your phone, edit a plan on your computer, and trust that your history and data remain coherent and accessible.

That means we need to test situations most users will never intentionally create:

• Two devices edit the same record.
• A deletion races with an older update.
• A write fails halfway through a synchronization cycle.
• One file is corrupt while hundreds of neighboring records remain valid.
• A client receives a wire shape produced by a different language and version.
• The application is terminated while local work is still pending.

Privacy and architecture can’t be an excuse for important stuff breaking. Removing the centralized safety net makes consistent behavior and recovery even more important.