PocketSync
Both phones got used since they last matched. This works out what belongs where.
Free right now — no account, no card
Preview
1 interface design, then a screenshot of it running. Drag, scroll or use the arrows.
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
- How to send a file from your phone to your computer Run a small web server on the computer and open its address on the phone. The file goes straight across you...
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
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