Phone Bridge

PocketSync

Both phones got used since they last matched. This works out what belongs where.

Free right now — no account, no card

Get PocketSync free Windows & Mac · one file, nothing to install

Preview

1 interface design, then a screenshot of it running. Drag, scroll or use the arrows.

Interface design PocketSync, 1 of 1
Screenshot PocketSync running on Windows today

Free while we’re in preview

Get PocketSync

Both phones got used since they last matched. This works out what belongs where.

The Mac button is for Apple Silicon. On an older Intel Mac, get this one instead.

One file, both ways. Double-click it for the window. Run the same file from a command prompt with arguments and it behaves as the command-line tool, because the engine is inside it. Nothing else to download and nothing to keep beside it.

Early preview. The window has been built and run, but not yet on a real Windows PC or Mac, so expect rough edges. The engine underneath it is fully tested.

  • One file — no installer
  • Runs on your machine, offline
  • Source code published below

Free while in preview. It isn’t signed yet, so Windows or macOS will ask you to confirm the first time you open it. At launch, PocketSync is included in every plan along with the rest of the range.

The family case

Photos were taken on the old phone and on the new one. A few were edited. One got renamed. Somebody deleted something and nobody remembers what.

PocketSync compares three things: side A, side B, and a baseline recording the state those two last agreed on. That third input separates “new on A” from “deleted on B”, which no two-way comparison can do. Identity is the SHA-256 of the contents, so a copy that landed with a different timestamp is still the same file, and a photo that turned up under a new name is reported as a rename instead of a deletion plus an addition.

Nothing of yours gets removed

A deletion on one side is never propagated to the other. Not with a flag, not with a policy, not with a prompt. There is one os.Remove call in the source, it refuses any path not ending in .pocketsync.part, and a test reads the source and fails the build if a second one appears.

Conflicts have no default. A path changed on both sides to different content is reported and skipped unless you choose keep-both, prefer-a or prefer-b, and even then the losing version is written somewhere safe before anything is replaced.

Both libraries must already be mounted as folders. MovePhone handles the one-way job.

Reading on the job itself

Advanced & technical details Command-line builds, source code, checksums and a recorded session — for developers and IT teams

A working command-line build of the reconciliation engine: a three-way compare of both libraries against a baseline that classifies every file into one of ten states, detects a photo that was renamed rather than deleted-and-re-added, and never propagates a deletion in either direction. Conflicts need a policy you state, and keep-both preserves every version on both sides. It plans by default and only writes with --apply.

Recorded session

Recorded terminal session showing PocketSync running
A real recorded session — PocketSync’s actual output, captured by running the shipped binary.

Naming status

Working name only — brand verdict **AVOID** (Very High). Collision: PocketSync. Rename completely.

What it draws on

Existing paid software whose best ideas shaped this program: iMazing, Wondershare MobileTrans, TouchCopy, Droid Transfer.

Command line

There is nothing extra to install. The program you download is the command-line tool as well: give it arguments instead of double-clicking it and it runs as one, with its output on your terminal. The standalone builds below are the same engine on its own, for machines where you would rather not ship a window at all.

pocketsync - three-way reconciliation for two phone libraries (Techlosoft Phone Bridge)

USAGE
  pocketsync status   --a <dir> --b <dir> [--baseline <file.json>] [--json]
  pocketsync plan     --a <dir> --b <dir> [--baseline <file.json>]
              [--conflict keep-both|prefer-a|prefer-b] [--json]
  pocketsync sync     --a <dir> --b <dir> [--baseline <file.json>]
              [--conflict keep-both|prefer-a|prefer-b] --apply [--json]
  pocketsync baseline --a <dir> --b <dir> --baseline <file.json> [--json]
  pocketsync help | -h | --help

COMMANDS
  status     One short paragraph: how many files are new on each side, how many
             need a decision, how many were renamed. Reads only.
  plan       The full three-way classification and the exact copy operations
             that WOULD run. Changes nothing on disk. This is the default view.
  sync       The same computation, then --apply actually performs the copies.
             Without --apply, sync is identical to plan and touches nothing.
  baseline   Record the agreed-identical state of the two sides: every path
             that exists on BOTH sides with byte-identical content. Paths that
             differ or exist on one side only are deliberately left out.

FLAGS
  --a <dir>          Side A: a mounted phone library, or any directory tree.
  --b <dir>          Side B: the other library.
  --baseline <file>  JSON manifest of the last agreed-identical state. Optional
                     for status/plan/sync: without it every path looks new and
                     no deletion can be detected (which is safe, since nothing
                     is ever deleted anyway).
  --conflict <pol>   How to resolve a file changed on BOTH sides to different
                     content. There is NO default: with no policy, conflicts are
                     reported and skipped, so nothing is ever silently lost.
                       keep-both  write BOTH versions to BOTH sides as
                                  <name>.pocketsync-a<ext> / <name>.pocketsync-b<ext>
                       prefer-a   side A's version wins at the original path;
                                  side B's version is preserved as
                                  <name>.pocketsync-b<ext> on both sides first
                       prefer-b   the mirror image of prefer-a
  --apply            Required by sync to write anything. Copies are written to
                     a .part file, hash-verified, then renamed into place.
...

Recorded from the shipped binary, not written by hand.

Source

Every file the program is built from:

apply.go · console.go · console_test.go · engine.go · guided.go · main.go · main_test.go · report.go · scan.go

SHA-256 checksums · build instructions & scope notes · full build plan