hiyoyo

Posted on Apr 2

I Built a Rust-Powered Diff Sync Engine to Fix Android↔Mac Sync [Mac Only]

#mac #android #rust #programming

## Why I Built This

You get back from a trip and try to back up your photos from Android to Mac.

When did I last back up? How far did I get?

You don't know, so you send everything. Duplicates pile up. Storage gets wasted. You do it all again next time...

Sound familiar?

"I have no idea what's already backed up, so I just send everything every time"
"I used a sync tool and accidentally deleted an entire folder of important files"
"I transferred hundreds of photos and half of them were already on my Mac"

"Never transfer the same file twice. Build a tool that does exactly that." — that's where this project started.

What I Built

Hiyoko Sync — a Mac-only Android differential sync app.

https://hiyokoko.gumroad.com/l/HiyokoSync

30-day money-back guarantee, no questions asked.

Key Features

The core is a differential sync engine that compares file size and modification date, and transfers only what's new or changed.

Sync

Differential sync engine: Compares file size and modification date — already transferred files are automatically skipped
Multiple sync jobs: Create named rules like "Photos → Mac" or "Music → Android" and run them all in one click
DCIM mode: One-click backup of your entire Android camera folder to Mac — perfect after a trip
Auto-sync on connect: Plug in the cable and sync starts automatically. No button pressing required
Conflict resolution dashboard: Files with the same name but different content are listed before anything is moved. Choose Ask / Overwrite / Skip / Auto-Rename
Exclusion rules: Automatically skip system noise like .DS_Store. Add your own patterns too
System path protection: Writing to critical macOS directories (~/Library, ~/.ssh, etc.) is blocked at the app level

Review & Logs

Pre-flight review: Before any files move, a summary shows exactly how many will be added, skipped, or overwritten. You decide when to proceed
Sync history log: Full transfer history, exportable as CSV
Real-time progress: Live speed graph and ETA

System Requirements

macOS 13 Ventura or later
Intel Mac / Apple Silicon (Universal Binary)
Android 10–16

Verified Devices

Physically tested — confirmed working

Xiaomi: Redmi K70, Mi 11 Lite 5G, Xiaomi Pad 5, Redmi 12 5G
POCO: X7 Pro, F6
Rakuten: Rakuten Mini

Expected to work — not yet physically tested

Samsung / Google Pixel / Xperia / Huawei / Motorola and other major Android brands

Roadmap

v1 focuses on one-way sync (Android → Mac) and core reliability.

Feature	v1	v2
One-way sync	✅	✅
Bidirectional sync	—	✅
Scheduled / automatic sync	—	✅
Advanced exclusion rule patterns	—	✅

Try It Out

🐤 Hiyoko Sync

https://hiyokoko.gumroad.com/l/HiyokoSync

🎉 Early bird $10 (reg. $12) — 2 weeks only
One-time purchase
30-day money-back guarantee, no questions asked
Bug reports & feature requests:
- 🇯🇵 Japanese form: https://forms.gle/cEDCJScbarfEcnHU8
- 🇺🇸 English form: https://docs.google.com/forms/d/e/1FAIpQLSe68YFnPtm1JVXN4GpUDRHvkuhaw9l-QGSlXT4GD_qeeuOe5w/viewform
Official X: https://x.com/hiyoyok

Hope it reaches someone with the same frustration! 🐤

The rest is technical detail for engineers. Feel free to skip if you just want to use the app!

Tech Stack

Technology	Role
Rust	Diff engine & MTP stack
Tauri	Desktop app framework
React	UI
nusb	Rust-native USB library, direct IOKit access
Tokio	Async runtime

Why Rust + Tauri?

Both diff detection reliability and MTP transfer stability come down to memory safety and concurrency. With Rust, there's no risk of crashing mid-comparison on a large file tree, and diffing thousands of files is fast.

Tauri was chosen over Electron for its lighter footprint and closer-to-native macOS feel.

Technical Deep Dive

How the Diff Engine Works

Before moving a single byte, Hiyoko Sync builds a virtual file tree of both your Mac and Android folders. It compares file size and modification date to identify exactly what needs to be transferred.

1. Build Mac file tree
2. Build Android file tree (via MTP)
3. Diff by size + modification date
4. Queue only changed files for transfer
5. Show pre-flight review
6. Transfer after user confirmation

This eliminates "send everything every time" at the root level.

The MTP Timestamp Problem

Due to MTP protocol constraints, file timestamps can be reset to the transfer time after syncing.

This creates a nasty loop with diff detection: "this file was already transferred, but the timestamp changed, so let's transfer it again."

To prevent this, file size is treated as the primary key and modification date as secondary — if the size matches, the file is considered identical.

Why I Switched from libmtp to nusb

libmtp was the starting point, but device recognition on macOS was broken.

libmtp was designed for Linux, where USB device handling works differently at a fundamental level.

libmtp (Linux-designed)
    ↓
libusb
    ↓
macOS IOKit ← conflict happens here

The fix was switching to nusb.

Custom MTP stack (Rust)
    ↓
nusb (Rust-native, calls IOKit directly)
    ↓
macOS IOKit ← no conflict!

nusb is a Rust-native USB library that calls IOKit directly on macOS. This same stack was proven in Hiyoko MTP and carried over to Sync as-is.

The Philosophy Behind Conflict Resolution

The scariest thing is an app that quietly decides to overwrite files on its own. If it overwrites a photo you can't get back, there's no undo.

In Hiyoko Sync, conflicting files are always listed before anything is touched. You decide how to handle each one. "APPLY TO ALL" is available for bulk decisions, but the default is always "Ask."

System Path Protection

Regardless of how a sync job is configured, writing to critical macOS paths like ~/Library or ~/.ssh is blocked at the app level. This prevents accidental system damage from misconfigured jobs.

What I Learned Shipping This

MTP's limitations are the app's problem to solve

MTP timestamp behavior varies wildly between devices. I could have documented it as "expected behavior" and moved on — but that breaks the user experience. Protocol limitations have to be absorbed in app logic. That was the key lesson here.

"Safe" means different things to different people

Early on I thought "please back up your data before using" was enough. But real safety is a design that doesn't break even if you make a mistake. The pre-flight review and system path protection both came from that realization.

The relationship between Hiyoko Sync and Hiyoko MTP

Hiyoko Sync reuses the MTP stack from Hiyoko MTP — the nusb-based protocol implementation, auto-reconnect logic, and transfer queue are essentially unchanged.

"Transfer-focused MTP" and "sync-focused Sync" — pick whichever fits your workflow. 🐤