Syncing picks between devices: what actually carries over

You made a first pass on the sofa. Now the shoot is open on your desktop and none of it is there. This is the part of a two-device workflow nobody writes about, so here it is in detail: the three routes a selection decision can travel, exactly what each one drops on the way, and the requirements a phone-then-desktop setup has to meet before it saves you anything.

The handover, not the picking, is the hard part

Picking photos on a phone is not difficult. Modern phone screens are sharp, your thumb is fast, and most of the calls in a first pass are obvious at any size. We made that argument in detail in culling on your phone versus your computer, which splits the job by decision type: the phone takes the volume, the desk takes the difficulty.

That article ends on one sentence that this whole page exists to unpack. A two-device workflow only pays if the handover is clean. If you open the shoot on the computer and your phone picks are not already sitting on the original files, you have not saved an hour, you have spent one twice.

So the useful question is not which device is better. It is a plumbing question: what is a selection decision made of, and which pipes will actually carry it. Three routes exist today. Each one carries some of your decisions and quietly drops the rest.

What you are actually trying to move

When you pick a frame, your software records a very small thing. Usually one of four:

• A flag. Pick, reject, or unflagged. Binary and fast, which is why most first passes use it. See flags versus star ratings for when each one belongs.
• A star rating. Zero to five. An old standard, understood by almost every program ever written.
• A color label. A word with a color attached, which is why label names have to match between machines or they arrive blank. More on that in using color labels for culling.
• Membership of something. A collection, an album, a stack, a virtual copy, a pick order inside a burst.

The first three are metadata fields. They are standardized, they have names other programs recognize, and they can be written somewhere that is not your catalog. The fourth is not. Collections, stacks, virtual copies and sort order are structures that live inside one program's database, and there is no agreed format for shipping them anywhere else.

That single split explains almost every sync disappointment you have had. Ratings and labels usually survive. The shape you organized things into usually does not.

Route one: XMP sidecars

XMP is a metadata standard. For a proprietary raw file, Adobe explains that XMP is not written into the original at all: it goes into a separate sidecar file with the same base name and an .xmp extension, so the raw file itself is never touched. For JPEG, TIFF, PSD and DNG, the same metadata gets written inside the file.

This is the closest thing photography has to a universal handover format, and it recently got better. Adobe's own documentation for flagging now states: "With LrC 13.2, flag states are now saved to XMP. Thus, they are now visible or available outside of the Lightroom Classic catalog." If you last checked this years ago and concluded flags were catalog-only, that is no longer true.

The three settings that decide whether it works

• Automatically write changes into XMP, in Catalog Settings under Metadata. Off by default. With it off, your decisions sit in the catalog and the sidecars stay empty.
• Photo, then Save Metadata to File. The manual version, for when you want to push a folder's decisions out on demand.
• Metadata, then Read Metadata from File. The receiving end. Without this step the second machine never looks at the sidecar you worked so hard to write.

One recent wrinkle worth knowing: from the October 2025 release, Lightroom Classic 15.0 writes a second sidecar with an .acr extension for heavy edits, masks and AI settings, keeping the .xmp file light. If you are copying sidecars by hand between machines, you now have two files per frame to keep together, not one.

What XMP loses: collections, stacks, virtual copies, your burst pick order, and history. It carries the verdict, not the arrangement.

Route two: Lightroom's own cloud sync

If you run Lightroom Classic on the desk and Lightroom on an iPhone or iPad, Adobe already syncs selection decisions between them. It is worth reading Adobe's own list rather than assuming, because the gaps are specific. This table is straight from Adobe's Lightroom Classic sync FAQ.

Flags and ratings crossing is the good news, and it is genuinely useful. Three constraints decide whether you can build a workflow on it.

Only collections sync, not folders. A photo has to be in a synced collection, or in All Synced Photographs, before it exists on the phone at all. Dumping a card into a folder does nothing.

Going up, you only send proxies. Adobe states plainly that "if you sync images from Lightroom Classic, only smart previews are synced." Coming back the other way, originals get downloaded. That asymmetry is fine for a first pass and wrong for a focus check, for the reasons in smart previews for culling.

One catalog, forever. "Lightroom Classic syncs only one catalog at a time." If you keep a catalog per year or per wedding, this route is a poor fit, and two Classic machines cannot sync to each other through it at all.

Worth noting alongside this: Adobe now ships Assisted Culling in both Classic and cloud Lightroom, labeled early access, scoring subject focus, eye focus and eyes open, and marking frames as Selects or Rejects. It marks, it does not throw anything away. The old line that Lightroom has no automated selection is out of date.

Route three: hand over a whole catalog

The third route ignores metadata standards and moves the database itself. In Lightroom Classic that is File, then Export as Catalog, with Build or Include Smart Previews ticked so the laptop can work without the drive attached. On the other side, File, then Import from Another Catalog, merges the decisions back in.

This is the only route that carries everything: flags, ratings, labels, collections, stacks, virtual copies, develop settings, the lot. It is what you want when a second shooter hands you their pass, or when you cull on a laptop in a hotel and merge at home.

Its cost is that it is a parcel, not a pipe. It goes one way, at one moment, between two copies of the same program. There is no live reconciliation: if both machines touched the same frame, the merge asks you to choose, and you will not remember which choice was the considered one. It also cannot include a phone, because no phone runs Lightroom Classic.

A fourth, cruder route deserves a mention because plenty of working photographers use it: export a list. A text file of picked filenames, or a folder of small JPEGs named after the raws, is ugly but universal, and it survives any pair of programs. We go through the tidier versions of this in exporting selections to Lightroom.

The five things that actually break

In practice, sync failures are rarely mysterious. They are almost always one of these.

1. Renaming after the first pass. This is the big one. XMP sidecars are matched by filename. If you pick on the phone against IMG_4471.CR3, then ingest with a rename template on the desktop, every sidecar is now pointing at a name that no longer exists. Rename once, at ingest, before anything makes a decision. A consistent file naming system is a sync feature, not just tidiness.

2. Two bodies, one filename. Two cameras both counting up from IMG_0001 will collide the moment their folders merge, and a sidecar cannot tell which frame it belonged to. Put a body identifier in the rename template on day one.

3. Sidecars left behind. Move or copy raws in Finder and select only the raw files, and the .xmp files stay where they were. Same for the new .acr files. The frames arrive with every decision stripped and no warning that anything was lost.

4. The catalog and the file disagree. Both hold a copy of the metadata, and they drift. Lightroom Classic shows a small conflict badge on the thumbnail, and it is easy to click past, overwriting the sidecar your phone pass wrote. If two devices are both writing, decide in advance which one wins.

5. A live catalog inside a sync folder. Dropbox, iCloud Drive and Google Drive are file-level sync services. A Lightroom catalog is a database being written to constantly, and putting one in a synced folder produces conflicted copies and corruption. Sync the raws and the sidecars if you like. Never the open catalog.

What a phone-then-desktop workflow has to get right

If you are evaluating any two-device setup, whether it is Adobe's, a pair of third-party apps or something you rigged yourself, these are the tests. Written as requirements, because that is what they are.

• Stable identity that is not the filename. A frame needs an identifier that survives renaming, copying and merging two cards. Filename matching is the weakest link in every route above.
• Decisions land on originals, not on proxies. You reviewed a small preview. The verdict has to attach to the raw file on your drive, otherwise you have annotated a copy nobody will open again.
• Nothing is ever thrown away. A first pass made fast on a small screen has to be fully reversible. Frames that were not picked stay exactly where they are, visible, one tap from being picked after all.
• Works with no signal. Venues have thick walls and the drive home has dead zones. Decisions must be recorded locally and reconciled later, not lost because a request failed.
• A conflict rule you know before you need it. When both devices touched a frame, something has to win, and you should be able to say which without reading a support article at midnight.
• Hard calls are deferred, not faked. Fine focus, near-identical frames and color cannot be settled on a phone. A good handover marks those frames for the desk instead of quietly resolving them.
• It speaks a format your editor already reads. Ratings, labels and flags in XMP, or a catalog. If the decisions only exist inside one app's own library, you have added a library rather than removed a step. That trade-off is the subject of fitting a selection tool into your editing stack.
• It goes both ways. Changes made at the desk should be visible on the phone next time, or the second shoot starts from a stale picture.

Held against that list, today's options each fail somewhere. XMP is universal but filename-fragile and structure-blind. Adobe's sync is genuinely two-way for flags and ratings, but wants your whole life in one catalog and sends proxies upward. Catalog export is complete and one-shot. Nothing yet treats the phone as a first-class first pass with a clean return path.

That gap is the reason Kepla is being built the way it is: a first pass on iPhone or iPad, the same shoot continuing on the Mac with nothing redone, and every frame it did not pick still sitting there untouched, because it never deletes, moves or renames a file. Those apps are still in development and we will keep saying so until they ship. The booking page is live and free today.

FAQ