There's no sync feature — there's a folder, and that's the sync feature

It's worth saying plainly before anything else: this app has no account, no cloud sync and no server anywhere in it. That's a deliberate choice, not a missing feature waiting on a roadmap, and it's worth understanding before trying to keep a library current across two machines, because the honest answer to "how do I sync this" is "you don't, not through the app — you sync the folder it lives in, with whatever you already use for that."

That answer works because of how little the workspace actually depends on. Everything it needs — the database, the thumbnails, the proxies — lives inside the same folder as the image and video files themselves, with nothing held in a system location or tied to one specific machine. A folder that ordinary file-sync tools can already mirror between two Macs is a folder a workspace can ride along on.

Step 0: Decide whether syncing is actually the right answer

Before setting anything up, it's worth being honest about which of two different problems is actually being solved. "I want the same library visible on both machines, kept current" is what the rest of this page covers. "I occasionally need to check something on the other Mac" is a smaller problem, and it might not need continuous syncing at all — an external drive carried between the two, or a one-off copy before a trip, can be simpler and safer than running a permanent sync on a workspace that's mostly used from a single machine anyway. Continuous folder-sync earns its complexity when both machines are genuinely active at different times during the same week, not as a default for "might need it someday."

Choosing a sync tool: what actually matters here

Not every folder-sync tool behaves the same way under the specific stress this workflow puts on it, so it's worth checking a few things about whatever tool is already in use rather than assuming any of them are interchangeable. It needs to sync hidden files and files without a common document extension — some tools default to skipping anything that looks like an application-support file, which would silently leave the database behind while happily syncing the images next to it. It needs to preserve both sides of a genuine conflict rather than picking one automatically and discarding the other, which is what step four below depends on. And it needs to actually be running and caught up before a switch, which is a habit rather than a setting, but is worth confirming the tool exposes some visible "up to date" state for, rather than one that syncs silently with no way to check.

None of this requires any configuration inside the app itself, which is worth stating plainly: there's no sync toggle to find, no account to sign both machines into, no setting that needs to match between them. The whole setup lives in whichever sync tool already exists on both Macs, and the app simply treats the synced folder like any other folder it's been pointed at.

Step 1: Sync the folder, not the app

Whatever already keeps a folder consistent between your two Macs — iCloud Drive, Dropbox, a Syncthing pair, a shared NAS mount both machines connect to — is the thing doing the actual syncing here. The app itself has nothing to configure for this; it just needs to be pointed at the synced folder on each machine.

Step 2: Register the same folder as a workspace on both machines

Once the folder itself is syncing, register it as a workspace on the second Mac the same way it was registered on the first. The first pass on the second machine reads what's already there — it doesn't need to rebuild anything from scratch, since the database, thumbnails and proxies already exist in the synced folder by the time the second Mac opens it.

Step 3: Treat the workspace as single-writer, not simultaneous

This is the part worth taking seriously rather than skimming past. The database inside the folder is a single file, and most sync tools work by watching for a file to stop changing before uploading it — which means two Macs writing to that same file at the same time, through a sync tool that wasn't built to arbitrate that, is a real risk to the file rather than a theoretical one. The safe pattern is simple: finish working on one Mac, let the sync tool visibly catch up, and only then open the workspace on the other. Don't leave it open on both at once.

Step 4: Know what to do if a conflicted copy shows up

Most folder-sync tools handle a genuine write conflict by keeping both versions and naming one a "conflicted copy" rather than silently picking a winner. If that happens to the database file specifically, keep the copy from whichever Mac had the more recent, intentional session of work, delete the other, and let the app re-index against it. Nothing about the image files themselves is at risk in this scenario — a conflicted database copy affects tags, ratings and notes, not the files those things describe, which are untouched regardless of which copy of the database wins.

Step 5: Lean on canvases for the parts that actually merge well

A .coii-canvas file is plain, pretty-printed JSON — the same kind of file a version-control tool or a sync tool already knows how to diff sensibly. Two people, or one person on two machines, editing different parts of the same canvas is a far more forgiving situation than two machines writing to the database at once, because a text-based diff can often reconcile two sets of changes to a JSON file in a way a binary database file never can.

Step 6: Verify nothing was lost after switching machines

After moving from one Mac to the other, a quick sanity check is worth the thirty seconds it costs. Compare a rough total against what the last known count was, or re-run a saved view that tracks something specific — an inbox, a shortlist — and confirm it looks the way it should before trusting a whole session of work to the sync having gone cleanly.

Step 7: Have a fallback for when sync genuinely can't keep up

On a slow connection, or with a very large workspace, waiting for a full sync before every switch between machines can become its own friction. In that situation, it's worth accepting a coarser rhythm rather than fighting the sync tool — treating one Mac as primary for a stretch of days and the other as read-mostly, rather than switching back and forth within the same afternoon, keeps the single-writer discipline easy to actually follow instead of a rule that gets skipped under time pressure.

A worked example: a freelancer with a desktop and a laptop

A common shape for this problem: a desktop Mac at a home studio and a laptop for client visits, both needing the same reference library. Putting the workspace folder inside whichever cloud-sync service already covers both machines, registering it once on each, and adopting the habit of quitting the app before closing the laptop lid and reopening it — rather than leaving it running in the background while travelling — avoids nearly every version of the conflict problem above, because the workspace is almost never genuinely open on both machines at the same instant.

A note on canvases specifically travelling well

Worth repeating on its own: a canvas moving between two synced Macs is the single smoothest part of this whole setup, precisely because it's plain text rather than a database record. Dragging a plate onto a board on the desktop and opening the same board an hour later on the laptop, once the sync tool has caught up, works the way opening any other synced document would — no re-indexing required, no special handling, just a file that happened to update.

Why this is a real limitation, not a workaround dressed up as one

It would be dishonest to describe folder-syncing as equivalent to a proper built-in sync feature — it isn't. A dedicated sync layer would understand the database's structure and could merge two sets of changes safely instead of treating the whole file as one atomic blob to fight over. What's on offer here instead is the more limited but more inspectable version of the same outcome: nothing about the workspace is tied to a server, an account or this specific app continuing to exist, which is also exactly why an ordinary file-sync tool can reach it at all. The trade is real, and single-writer discipline is the price of it.

That trade is also the same one that shows up throughout the rest of this app's design, not a special case invented for syncing. Nothing being tied to a server is the identical property that makes a canvas openable in ten years and a folder restorable from any backup tool without a special export step — syncing between two Macs is just the situation where that property's cost, rather than only its benefit, becomes visible. A tool built around an account and a server could paper over the single-writer problem by arbitrating changes centrally; it would also mean the library stops being readable the day that server or account goes away. Which trade is worth making depends on what's actually being optimised for, and this page is built for the version of that answer where the folder staying inspectable and portable matters more than seamless simultaneous editing.

Common mistakes worth avoiding

Leaving the app open on both Macs at once "just in case" — this is the one mistake most likely to actually damage something, since it's the direct cause of the database being written from two places simultaneously. Assuming a sync tool has finished before it actually has, and switching machines based on how much time feels like it should have passed rather than checking the sync tool's own status. And treating a conflicted-copy warning as something to dismiss without reading — it's the sync tool doing exactly its job, catching a real conflict instead of silently overwriting one side.

A less obvious mistake is registering two different folders — one on each Mac — that happen to hold copies of the same images, rather than one folder that's genuinely kept in sync. That produces two independent workspaces with two independent databases that will never reconcile on their own, however similar their contents look at a glance, and it's a much harder problem to untangle later than simply setting sync up correctly from the start.

What to do when the library gets large

A larger workspace means a larger database file, and a larger file takes a sync tool longer to fully upload and download between two machines — which makes the "wait for it to catch up" discipline in step three more important at scale, not less, since the window where a switch could happen too early gets longer as the file grows. Thumbnails and proxies add real size to what gets synced too, though unlike the database they're regenerable from the source files if a copy is ever lost or skipped.

Backing up the same folder properly covers the closely related question of protecting this same folder against loss rather than keeping two live copies current, and the two habits work well together. Building a library from folders you already have and organizing what's indexed are worth reading if the workspace doesn't exist on either machine yet. What a proxy file actually is explains the regenerable piece named above, and why there's no account to sign into in the first place covers the same design choice from the angle of privacy rather than sync. The one-time purchase shape of the app itself covers licensing across the two Macs this page assumes. Or try it on both of your own machines — thirty days, every feature, no card and no account, three devices per licence, which is exactly the shape this workflow needs.