The share feature is: send the file

There's no Share button in the usual sense, no invite dialog, no permissions list to set before someone else can open a board. That's not a gap in the app; it follows directly from what a canvas already is — a .coii-canvas file sitting in one of your own folders — and once that's the starting point, "how do I share this" stops being a question about a feature and becomes a question about which of the ways you already move files is the right one for this particular recipient.

That reframing matters because the honest answer depends on one thing: does the person receiving the board already have the images it points to? A canvas doesn't embed pixels. It stores paths, positions and notes as plain JSON, and a plate on the board is only ever as good as whatever file sits at the end of that path when it's opened. Getting a board in front of someone who can actually see it means accounting for that dependency, not just attaching one file to an email.

It's worth naming why this feels unfamiliar. Most moodboard tools people have used before this one default to a hosted board with a shareable link, because the images live on a server the tool controls and a link is the natural way to point at something living there. None of that server-side storage exists here — the images stay exactly where you put them, and the canvas is a small file describing how to find them, not a copy of them. That's a trade worth being explicit about going in: there is nothing to lose access to later, no account that could be deactivated, no service that could raise its price or shut down and take the board with it, but there's also no link that works from a machine that has neither the app nor the images. The steps below are about making that trade work in practice rather than wishing it away.

None of this is a limitation to work around quietly. It's a fair trade to be upfront about, and it changes who this workflow suits: someone sending a board once to a client who'll never open the app again wants a fast, disposable option, while someone handing a board to a long-term collaborator wants the standing folder from step two. Knowing which of those two people you're actually sending to, before picking a channel, saves rebuilding the wrong kind of setup halfway through.

Step 1: Work out what the canvas actually depends on

Before picking a channel, check whether the board you're sending references images the recipient already has — a shared client drive, a synced project folder, a set of deliverables you sent last week — or whether every plate on it points at something that only exists on your own machine.

If it's the former, the canvas file alone is enough: open it on the other end, and every plate resolves because the same relative path leads to the same file. If it's the latter, the canvas needs company.

Step 2: Sending to someone who already has the same folder

This is the easy case, and it's more common than it sounds — anyone you regularly hand references to on a shared drive, a team's synced project folder, or a workspace you both already keep in sync across two Macs is set up for it without extra work.

Save the canvas somewhere inside that shared structure — a Boards folder alongside the images it references is a reasonable default — and the file itself is the whole of what you send. The recipient's copy of the app reads the same relative paths yours does and every plate shows up exactly as you left it.

Step 3: Sending to someone who doesn't

When the recipient has never seen the folder a board draws from, the canvas needs to travel with the files it points at, kept in the same relative shape. In practice that means gathering the board and the images it actually uses into one folder before zipping it, rather than sending the whole library.

A query scoped to the project folder and a recent date range is usually enough to pull together the handful of files a given board actually needs, without shipping months of unrelated material along with it. Zip the canvas and that folder together, keeping the same structure, and the recipient unzips it, points their own copy of the app at the folder, and opens the canvas from inside it.

Worth noting: the images a board references don't need to be sent at full resolution to be useful on the receiving end. If the recipient's copy of the app has already indexed the same files, the proxies it writes at canvas resolution are what actually render on the board day to day — the full files matter for anything beyond viewing the layout, but a review pass rarely needs more than what the board already shows.

Step 4: Pick the channel the same way you already do for files

Nothing inside the app uploads anything on your behalf, so the choice of channel is entirely yours and depends on size and frequency. AirDrop handles a single board and its images between two Macs in the same room without a second thought. A zipped attachment works for anything small enough for whatever inbox is on the other end. For anyone you'll be sending boards to repeatedly — a recurring client, a collaborator on the same project — a standing synced folder is worth setting up once rather than zipping something new every time, which folds back into step 2 for every board after the first.

An alternative: viewing without a full install

There isn't one, and it's worth saying plainly rather than implying a lighter-weight path exists. There's no viewer app, no web-based preview and no way to flatten a canvas into a single image inside the app itself. A recipient either has the app and the referenced files, or they don't see the board at all — which is a real constraint on who this method of sharing actually works for. Someone who needs to glance at a layout once, on a machine that will never have the app installed, is better served by an actual exported image made by hand — taking a screenshot of the canvas open on your own screen and sending that — than by trying to get the file itself to open somewhere it structurally can't.

That distinction matters because it draws a clean line around what this workflow is for: getting the working file to someone who's going to keep using it, not producing a disposable preview for someone who just needs to glance at it once. Conflating the two leads to over-engineering the simple case — zipping a full project folder for someone who only wanted to see what the board looked like — or under-serving the real one, sending a screenshot to a collaborator who actually needed the editable file to keep working on the board themselves.

Step 5: What the recipient needs on their end

Opening a .coii-canvas requires the app itself — there's no viewer that works without it, and no browser preview. If the person you're sending it to doesn't already own a copy, the 30-day trial is enough to open a single board and review it without either side paying first. Everything a board needs to render is either already there or arrived in the same package; nothing about opening it depends on a network connection or a login.

When it's a standing thing, not a one-off

A single board sent once is a zip file and an afternoon. A relationship where boards go back and forth every week — an ongoing client, a recurring review cycle — is better served by a shared folder both sides keep synced through whatever tool already does that job, so a new board is a save rather than a send. The canvas format doesn't change between the two cases; what changes is whether the channel is built once and reused, or improvised per file. Setting up the standing version the first time a second board gets sent saves rebuilding the packaging step from scratch each time.

What breaks a share silently

The most common failure isn't a missing file — it's a path that resolves to something different than expected because the folder structure on the receiving end doesn't quite match the one the canvas was built against. A canvas built against ~/Projects/Studio-B/Approved/shot-04.heic needs that same relative shape wherever it's opened; renaming the top folder, flattening subfolders during a zip, or dropping the contents into a differently named directory all break the link between the plate and its file, even though nothing about the canvas itself changed. This is the same category of problem registering several external drives runs into when a drive gets renamed after its workspace is set up — a path is only stable if nothing upstream of it moves.

The fix is mechanical rather than clever: when packaging a board for someone who doesn't already share your folder structure, preserve the folder layout exactly, from the canvas's own directory downward, rather than collecting the referenced images into a flat pile next to it. Testing the zip by unpacking it into a fresh, empty folder and opening the canvas from there — rather than trusting that the structure looks right — catches a mismatched path before the recipient does.

A worked example: three rounds with the same client

A board that goes back and forth for client notes usually isn't a single send — it's several, each with a slightly different set of images pulled in as the concept narrows. Round one might be a broad exploration, a dozen images from three different location scouts, sent as a zip because the client has never seen the project folder. Round two, after notes narrow the direction to one location, is a smaller board with new images added alongside a handful kept from round one — sent the same way, since nothing about the client's setup changed between rounds. By round three, if the relationship is ongoing enough to justify it, switching to a shared synced folder set up once means the fourth and fifth rounds stop being separate zip files entirely and become saves into a folder the client already has open.

That progression — ad hoc for the first exchange, standing once the relationship proves itself — is the realistic shape most sharing relationships actually take, and it's worth planning for rather than assuming every relationship needs the heavier setup from the first message.

What this isn't

Worth being direct about: there's no live collaborative editing here, no comment thread attached to a plate, and no hosted preview a recipient can open in a browser without the app installed. Two people can't edit the same board at the same time and expect the changes to merge — the workflow above is send, receive, review, not co-edit in real time. Anyone whose actual need is a client clicking a web link with no install required is asking for a different kind of tool than this one, and this page won't pretend the gap isn't there. What it does get right is the part after that: a file that opens the same way on any Mac, forever, without a service on the other end that could go away.

That plain-file property is also what makes the file worth sending in the first place rather than a screenshot of it — a screenshot flattens the layout permanently, while the canvas itself stays editable on the other end if that's ever useful. Building a board from folders you already have covers the step before this one, and keeping a canvas under version control is worth reading next if the boards you're sending change often enough that tracking those changes matters as much as sending the current one. What a moodboard actually is and an offline moodboard app with no account fill in the parts of this that this page assumes. Or try sending one from your own library — thirty days, every feature, no card and no account, is enough to zip a real board and hand it to someone else to see whether the plain-file version of sharing actually fits how you work.