DEV Community: hiyoyo

Conflict Resolution in a Bidirectional Sync App — How I Handle the Hard Cases

hiyoyo — Fri, 19 Jun 2026 01:07:18 +0000

All tests run on an 8-year-old MacBook Air. All results from shipping 7 Mac apps as a solo developer. No sponsored opinion.

HiyokoAutoSync does bidirectional sync between Android and Mac. Bidirectional sync has a hard problem: what happens when the same file is modified on both sides? Here's how I handle it.

The conflict cases

File modified on both sides since last sync — which version wins?
File deleted on one side, modified on the other — delete or keep?
File moved on one side — move on the other side or treat as delete + create?

Most sync apps punt on cases 1 and 3. Here's my approach.

Detecting conflicts

Track last-synced state in SQLite:

CREATE TABLE sync_state (
    file_path TEXT PRIMARY KEY,
    mac_hash TEXT,
    android_hash TEXT,
    mac_modified INTEGER,
    android_modified INTEGER,
    last_synced INTEGER
);

On sync check:

fn classify_file(record: &SyncRecord, mac_stat: &FileStat, android_stat: &FileStat) -> SyncAction {
    let mac_changed = mac_stat.hash != record.mac_hash;
    let android_changed = android_stat.hash != record.android_hash;

    match (mac_changed, android_changed) {
        (true, false)  => SyncAction::CopyToAndroid,
        (false, true)  => SyncAction::CopyToMac,
        (false, false) => SyncAction::NoOp,
        (true, true)   => SyncAction::Conflict,
    }
}

Conflict resolution strategies

I offer three strategies, user-configurable:

Newer wins: compare modification timestamps, keep the more recent file.

SyncAction::Conflict => {
    if mac_stat.modified > android_stat.modified {
        SyncAction::CopyToAndroid
    } else {
        SyncAction::CopyToMac
    }
}

Mac always wins: for users who treat Mac as source of truth.

Keep both: rename one file with a conflict suffix, keep both versions.

// Rename Android version to "file.conflict-2026-05-01.ext"
let conflict_name = add_conflict_suffix(&file_path);
copy_to_mac_as(&android_file, &conflict_name)?;
copy_to_android(&mac_file)?;

Delete vs modify conflict

File deleted on Mac, modified on Android:

(Deleted, Modified) => {
    // Default: keep the modified file, restore it on Mac
    // Alternative: delete from both sides
    // User configurable
    SyncAction::RestoreToMac
}

The safe default is to keep data. Deleting across both sides on a conflict can cause data loss users didn't intend.

The verdict

Bidirectional sync without conflict resolution is a bug waiting to happen. The "newer wins" strategy covers 90% of real-world cases. Keep both covers the rest. Make it configurable for power users.

TL;DR: Track sync state (hash + modified time) in SQLite per file. Classify each file into CopyToAndroid, CopyToMac, NoOp, or Conflict using a match on what changed. Offer three strategies: newer wins, Mac wins, or keep both. For delete vs modify conflicts, default to keeping data — accidental deletion is worse than a duplicate.

If this was useful, a ❤️ helps more than you'd think — thanks!

HiyokoAutoSync | X → @hiyoyok

USB Hotplug Detection in Rust on macOS — Reacting to Device Connect/Disconnect

hiyoyo — Thu, 18 Jun 2026 01:54:29 +0000

All tests run on an 8-year-old MacBook Air. All results from shipping 7 Mac apps as a solo developer. No sponsored opinion.

HiyokoAutoSync and HiyokoMTP both react instantly when an Android device is connected. No polling. No "refresh" button. Just plug in and it works. Here's how USB hotplug detection works in Rust on macOS.

The approach: nusb hotplug API

nusb provides a hotplug watch API that wraps macOS's IOKit USB notifications:

use nusb::hotplug::{HotplugEvent, HotplugWatch};

fn watch_usb_devices(app_handle: AppHandle) {
    std::thread::spawn(move || {
        let watch = nusb::watch_devices().expect("Failed to start USB watch");

        for event in watch {
            match event {
                HotplugEvent::Connected(device_info) => {
                    if is_android_device(&device_info) {
                        app_handle.emit("device-connected", DeviceInfo {
                            name: device_info.product_string().unwrap_or_default(),
                            vendor_id: device_info.vendor_id(),
                            product_id: device_info.product_id(),
                        }).ok();
                    }
                }
                HotplugEvent::Disconnected(device_info) => {
                    if is_android_device(&device_info) {
                        app_handle.emit("device-disconnected", ()).ok();
                    }
                }
            }
        }
    });
}

The watch runs in a dedicated thread — it's a blocking iterator. Emit Tauri events to notify the frontend.

Identifying Android devices

Android devices have well-known vendor IDs. A non-exhaustive list:

const ANDROID_VENDOR_IDS: &[u16] = &[
    0x18D1, // Google
    0x04E8, // Samsung
    0x22D9, // OPPO/OnePlus
    0x2717, // Xiaomi
    0x12D1, // Huawei
    0x0BB4, // HTC
    0x1004, // LG
    0x0FCE, // Sony
];

fn is_android_device(info: &nusb::DeviceInfo) -> bool {
    ANDROID_VENDOR_IDS.contains(&info.vendor_id())
}

This catches most Android devices. ADB provides a more reliable check, but vendor ID filtering is fast and works before ADB connects.

ADB confirmation

After detecting a USB device with a known Android vendor ID, confirm with ADB:

async fn confirm_adb_device() -> bool {
    let output = Command::new("adb")
        .args(["devices", "-l"])
        .output()
        .await;

    match output {
        Ok(out) => {
            let stdout = String::from_utf8_lossy(&out.stdout);
            stdout.lines()
                .skip(1) // skip "List of devices attached"
                .any(|line| line.contains("device"))
        }
        Err(_) => false,
    }
}

Vendor ID for fast detection, ADB for confirmation. Two-step keeps the UX instant while ensuring accuracy.

The frontend experience

The user plugs in their Android device. Within 1-2 seconds:

USB hotplug fires
ADB confirms the device
Frontend receives device-connected event
UI updates to show the device and enable sync

No button. No refresh. It just works.

TL;DR: Use nusb::watch_devices() in a dedicated thread to get IOKit USB hotplug events on macOS. Filter by vendor ID for instant detection, then confirm with adb devices for accuracy. Emit Tauri events to the frontend — plug in and it works within 1-2 seconds, no refresh button needed.

If this was useful, a ❤️ helps more than you'd think — thanks!

HiyokoAutoSync | X → @hiyoyok

Smart Resume for File Transfers in Rust — Never Start Over

hiyoyo — Tue, 16 Jun 2026 23:43:04 +0000

All tests run on an 8-year-old MacBook Air. All results from shipping 7 Mac apps as a solo developer. No sponsored opinion.

A 2GB video transfer that fails at 90% and restarts from zero is a terrible experience. HiyokoMTP and HiyokoAutoSync both implement smart resume. Here's how.

The problem

File transfers fail. USB connections drop. Devices sleep. The user unplugs at the wrong moment.

Without resume: start over. With resume: pick up where you left off.

The approach

Track transfer state in SQLite. On failure, record the partial state. On retry, check the record and resume from the last confirmed position.

CREATE TABLE transfer_state (
    id INTEGER PRIMARY KEY,
    file_path TEXT NOT NULL,
    total_bytes INTEGER NOT NULL,
    transferred_bytes INTEGER DEFAULT 0,
    file_hash TEXT,
    status TEXT DEFAULT 'in_progress',
    started_at INTEGER,
    updated_at INTEGER
);

Writing with resume support

pub async fn transfer_with_resume(
    source: &Path,
    dest: &Path,
    db: &Connection,
) -> Result<(), AppError> {
    let file_hash = compute_hash(source)?;

    // Check for existing partial transfer
    let existing = db.query_row(
        "SELECT transferred_bytes FROM transfer_state
         WHERE file_path = ? AND file_hash = ? AND status = 'in_progress'",
        params![source.to_str().unwrap(), &file_hash],
        |r| r.get::<_, i64>(0),
    ).ok();

    let start_offset = existing.unwrap_or(0) as u64;

    // Open source file, seek to offset
    let mut reader = File::open(source)?;
    reader.seek(SeekFrom::Start(start_offset))?;

    // Open dest file for append if resuming
    let mut writer = if start_offset > 0 {
        OpenOptions::new().append(true).open(dest)?
    } else {
        File::create(dest)?
    };

    // Transfer in chunks, updating DB periodically
    let mut transferred = start_offset;
    let mut buf = vec![0u8; 65536];

    loop {
        let n = reader.read(&mut buf)?;
        if n == 0 { break; }

        writer.write_all(&buf[..n])?;
        transferred += n as u64;

        // Update progress every 1MB
        if transferred % (1024 * 1024) == 0 {
            db.execute(
                "UPDATE transfer_state SET transferred_bytes = ?, updated_at = ? WHERE file_path = ?",
                params![transferred as i64, unix_now(), source.to_str().unwrap()],
            )?;
        }
    }

    // Mark complete
    db.execute(
        "UPDATE transfer_state SET status = 'complete' WHERE file_path = ?",
        params![source.to_str().unwrap()],
    )?;

    Ok(())
}

Validating resumed files

After a resume, verify the file hash of the completed transfer:

if compute_hash(dest)? != expected_hash {
    // Hash mismatch — delete and retry from scratch
    std::fs::remove_file(dest)?;
    return Err(AppError::Transfer("Hash mismatch after resume".into()));
}

A corrupted partial transfer is worse than starting over. Always validate.

The verdict

Smart resume is the difference between a frustrating tool and a reliable one. SQLite tracking + offset-based writes cover the implementation. The complexity is worth it for any app that transfers large files.

TL;DR: Track transfer state in SQLite with transferred_bytes and file_hash. On retry, seek to the last confirmed offset and append. Update progress every 1MB to keep DB writes cheap. Always verify the final hash — a corrupted resume is worse than starting over.

If this was useful, a ❤️ helps more than you'd think — thanks!

HiyokoAutoSync | X → @hiyoyok

AES-256-GCM Encryption in Rust — Securing Local App Data

hiyoyo — Tue, 16 Jun 2026 11:15:12 +0000

All tests run on an 8-year-old MacBook Air. All results from shipping 7 Mac apps as a solo developer. No sponsored opinion.

Hiyoko PDF Vault encrypts PDFs with AES-256-GCM. Here's the implementation — the parts that aren't obvious from the docs.

Why AES-256-GCM

AES-256-GCM is authenticated encryption. It provides both confidentiality (the data is encrypted) and integrity (you know if the data was tampered with). Without authentication, encrypted data can be modified without detection.

For document encryption, use authenticated encryption. AES-256-GCM is the standard choice.

The implementation with aes-gcm

[dependencies]
aes-gcm = "0.10"
rand = "0.8"

use aes_gcm::{
    aead::{Aead, AeadCore, KeyInit, OsRng},
    Aes256Gcm, Key, Nonce,
};

pub fn encrypt(data: &[u8], key: &[u8; 32]) -> Result<Vec<u8>, AppError> {
    let cipher = Aes256Gcm::new(Key::<Aes256Gcm>::from_slice(key));

    // Generate random nonce — never reuse a nonce with the same key
    let nonce = Aes256Gcm::generate_nonce(&mut OsRng);

    let ciphertext = cipher
        .encrypt(&nonce, data)
        .map_err(|_| AppError::Encryption("Encryption failed".into()))?;

    // Prepend nonce to ciphertext — you need it for decryption
    let mut result = nonce.to_vec();
    result.extend_from_slice(&ciphertext);

    Ok(result)
}

pub fn decrypt(data: &[u8], key: &[u8; 32]) -> Result<Vec<u8>, AppError> {
    if data.len() < 12 {
        return Err(AppError::Encryption("Data too short".into()));
    }

    let (nonce_bytes, ciphertext) = data.split_at(12);
    let nonce = Nonce::from_slice(nonce_bytes);
    let cipher = Aes256Gcm::new(Key::<Aes256Gcm>::from_slice(key));

    cipher
        .decrypt(nonce, ciphertext)
        .map_err(|_| AppError::Encryption("Decryption failed — wrong key or corrupted data".into()))
}

Key derivation from password

Never use a password directly as an AES key. Use Argon2id to derive a key:

argon2 = "0.5"

use argon2::{Argon2, PasswordHasher, password_hash::SaltString};

pub fn derive_key(password: &str, salt: &[u8; 32]) -> Result<[u8; 32], AppError> {
    let argon2 = Argon2::default();
    let mut key = [0u8; 32];

    argon2
        .hash_password_into(password.as_bytes(), salt, &mut key)
        .map_err(|_| AppError::Encryption("Key derivation failed".into()))?;

    Ok(key)
}

Store the salt with the encrypted data. The salt is not secret — it just prevents rainbow table attacks.

The nonce rule

Never reuse a nonce with the same key. With a 96-bit random nonce and OsRng, collision probability is negligible for any realistic number of encryptions. Always generate fresh nonces with a cryptographically secure RNG.

Storing encrypted PDFs

Format: [salt (32 bytes)][nonce (12 bytes)][ciphertext]

Everything needed for decryption is in the file. The password is the only secret.

TL;DR: Use aes-gcm crate for AES-256-GCM encryption — authenticated encryption that catches tampering. Derive keys from passwords with Argon2id (never use passwords directly as keys). Store format: [salt][nonce][ciphertext]. Generate a fresh nonce per encryption with OsRng.

If this was useful, a ❤️ helps more than you'd think — thanks!

Hiyoko PDF Vault | X → @hiyoyok

Hardware Video Compression in Rust on macOS — ffmpeg with VideoToolbox

hiyoyo — Tue, 16 Jun 2026 03:05:13 +0000

All tests run on an 8-year-old MacBook Air. All results from shipping 7 Mac apps as a solo developer. No sponsored opinion.

HiyokoAutoSync optionally compresses videos during sync. Software compression on an 8-year-old MacBook Air is slow. Hardware compression via VideoToolbox is fast. Here's how to use ffmpeg's hardware acceleration from Rust.

VideoToolbox basics

VideoToolbox is Apple's hardware video encoding framework. ffmpeg supports it via the h264_videotoolbox encoder. The difference on Intel MacBook Air:

Software (libx264): 2-3 minutes for a 1-minute 4K video
Hardware (h264_videotoolbox): 15-30 seconds for the same video

For a sync app where users want to not think about it, this matters.

The ffmpeg command

ffmpeg -i input.mp4 \
  -c:v h264_videotoolbox \
  -b:v 5M \
  -c:a aac \
  -b:a 128k \
  output.mp4

h264_videotoolbox uses the hardware encoder. -b:v 5M sets video bitrate — adjust based on your quality/size tradeoff.

From Rust

use std::process::Command;

pub async fn compress_video(
    input: &Path,
    output: &Path,
    bitrate_mbps: u32,
) -> Result<(), AppError> {
    let bitrate = format!("{}M", bitrate_mbps);

    let status = tokio::task::spawn_blocking({
        let input = input.to_owned();
        let output = output.to_owned();
        move || {
            Command::new("ffmpeg")
                .args([
                    "-i", input.to_str().unwrap(),
                    "-c:v", "h264_videotoolbox",
                    "-b:v", &bitrate,
                    "-c:a", "aac",
                    "-b:a", "128k",
                    "-y", // overwrite output
                    output.to_str().unwrap(),
                ])
                .status()
        }
    }).await??;

    if !status.success() {
        return Err(AppError::Compression("ffmpeg failed".into()));
    }

    Ok(())
}

Fallback to software

VideoToolbox isn't available on all systems. Fallback gracefully:

async fn compress_with_fallback(input: &Path, output: &Path) -> Result<(), AppError> {
    // Try hardware first
    match compress_video_hw(input, output).await {
        Ok(()) => Ok(()),
        Err(_) => {
            log::warn!("Hardware encoding failed, falling back to software");
            compress_video_sw(input, output).await
        }
    }
}

Software fallback with libx264 is slower but reliable on any system.

Bundling ffmpeg

ffmpeg needs to be bundled with your Tauri app or assumed to be installed. I bundle a universal binary ffmpeg in the app resources. In tauri.conf.json:

{
  "bundle": {
    "resources": ["bin/ffmpeg"]
  }
}

Then access it via the resource directory at runtime.

TL;DR: Use ffmpeg's h264_videotoolbox encoder for hardware-accelerated video compression on macOS — 5-10x faster than libx264 on Intel Macs. Call via spawn_blocking in Rust, add a software fallback for systems where VideoToolbox isn't available, and bundle ffmpeg as a Tauri resource.

If this was useful, a ❤️ helps more than you'd think — thanks!

HiyokoAutoSync | X → @hiyoyok

HEIC to JPEG on macOS in Rust — Using sips Without Reinventing the Wheel

hiyoyo — Mon, 15 Jun 2026 12:03:44 +0000

All tests run on an 8-year-old MacBook Air. All results from shipping 7 Mac apps as a solo developer. No sponsored opinion.

iPhones shoot HEIC. Most apps want JPEG. HiyokoAutoSync converts automatically during sync. The solution is already on every Mac: sips.

What sips is

sips (Scriptable Image Processing System) is a macOS built-in command-line tool for image conversion. It ships with every Mac, handles HEIC natively, and requires zero bundling.

sips -s format jpeg photo.heic --out photo.jpg

One command. No dependencies. Works on Intel and Apple Silicon.

Calling sips from Rust

use std::process::Command;

pub async fn heic_to_jpeg(
    input: &Path,
    output: &Path,
) -> Result<(), AppError> {
    let status = Command::new("sips")
        .args([
            "-s", "format", "jpeg",
            "-s", "formatOptions", "85", // quality 0-100
            input.to_str().unwrap(),
            "--out",
            output.to_str().unwrap(),
        ])
        .status()?;

    if !status.success() {
        return Err(AppError::Conversion(
            format!("sips failed for {:?}", input)
        ));
    }

    Ok(())
}

formatOptions sets JPEG quality. 85 is a good default — smaller than 100, visually indistinguishable for most photos.

Async conversion with Tauri

Command::new is blocking. Wrap in spawn_blocking for use in async Tauri commands:

let input = input_path.clone();
let output = output_path.clone();

tokio::task::spawn_blocking(move || {
    heic_to_jpeg_sync(&input, &output)
}).await??;

Batch conversion

For parallel HEIC conversion during sync, the same semaphore pattern applies:

let semaphore = Arc::new(Semaphore::new(4)); // 4 concurrent conversions

for heic_file in heic_files {
    let sem = Arc::clone(&semaphore);
    tokio::spawn(async move {
        let _permit = sem.acquire().await.unwrap();
        heic_to_jpeg(&heic_file, &jpeg_output(&heic_file)).await
    });
}

4 concurrent sips processes is comfortable on most Macs. More than 6 and you'll see diminishing returns.

The alternative: pure Rust

There are Rust crates for HEIC decoding. They require bundling native libraries, add significant binary size, and don't handle all HEIC variants as well as Apple's own implementation.

For a macOS-only app, sips is the correct choice. Use the platform.

TL;DR: For HEIC→JPEG on macOS, skip the Rust crates and use the built-in sips command. Call it via Command::new, wrap in spawn_blocking for async Tauri commands, and use a Semaphore with 4 concurrent processes for batch conversion. Zero dependencies, Apple-quality output.

If this was useful, a ❤️ helps more than you'd think — thanks!

HiyokoAutoSync | X → @hiyoyok

Parallel File Transfers in Rust — How I Made Android Sync Actually Fast

hiyoyo — Mon, 15 Jun 2026 02:55:02 +0000

All tests run on an 8-year-old MacBook Air. All results from shipping 7 Mac apps as a solo developer. No sponsored opinion.

Sequential file transfer is slow. HiyokoAutoSync uses parallel transfers with a concurrency limit. Here's how I built it.

The problem with sequential transfer

Copy 100 photos from Android to Mac one at a time: each transfer waits for the previous to complete. ADB overhead per file adds up. On a large library, this takes minutes.

Parallel transfers use the available bandwidth more efficiently. Same 100 files, 6 concurrent transfers: significantly faster.

tokio::sync::Semaphore for concurrency control

Unlimited parallelism isn't better — it overwhelms the ADB connection and the device. A semaphore limits concurrent transfers to a useful number:

use tokio::sync::Semaphore;
use std::sync::Arc;

const MAX_CONCURRENT: usize = 6;

async fn transfer_files(files: Vec<FileEntry>) -> Result<(), AppError> {
    let semaphore = Arc::new(Semaphore::new(MAX_CONCURRENT));
    let mut handles = vec![];

    for file in files {
        let sem = Arc::clone(&semaphore);
        let handle = tokio::spawn(async move {
            let _permit = sem.acquire().await.unwrap();
            transfer_single_file(&file).await
        });
        handles.push(handle);
    }

    // Collect results
    for handle in handles {
        handle.await??;
    }

    Ok(())
}

6 concurrent transfers was the sweet spot in my testing — fast without overwhelming the connection.

Progress tracking across parallel transfers

Each transfer needs to report progress independently. Use an atomic counter:

use std::sync::atomic::{AtomicUsize, Ordering};

let completed = Arc::new(AtomicUsize::new(0));
let total = files.len();

for file in files {
    let completed = Arc::clone(&completed);
    let handle_clone = app_handle.clone();

    tokio::spawn(async move {
        let _permit = sem.acquire().await.unwrap();
        transfer_single_file(&file).await?;

        let done = completed.fetch_add(1, Ordering::Relaxed) + 1;
        handle_clone.emit("transfer-progress", Progress {
            completed: done,
            total,
            current_file: file.name.clone(),
        }).ok();

        Ok::<(), AppError>(())
    });
}

Error handling in parallel

One failed transfer shouldn't kill all others. Collect errors and report at the end:

let results: Vec<Result<(), AppError>> = futures::future::join_all(handles)
    .await
    .into_iter()
    .map(|r| r.unwrap_or_else(|e| Err(AppError::Task(e.to_string()))))
    .collect();

let errors: Vec<_> = results.into_iter().filter_map(|r| r.err()).collect();
if !errors.is_empty() {
    // Report partial failure — some files transferred, some didn't
}

Partial success is better than all-or-nothing for file transfers.

The result

6-lane parallel transfer on HiyokoAutoSync is noticeably faster than sequential for large photo libraries. The semaphore pattern is reusable for any parallel work with a concurrency limit.

TL;DR: Use tokio::sync::Semaphore with MAX_CONCURRENT = 6 to parallelize ADB file transfers without overwhelming the connection. Track progress with AtomicUsize, and use join_all with per-error collection so one failed transfer doesn't abort the rest.

If this was useful, a ❤️ helps more than you'd think — thanks!

HiyokoAutoSync | X → @hiyoyok

APK Install and App Manager in Rust + Tauri — Building ADB Tools

hiyoyo — Sun, 14 Jun 2026 13:26:32 +0000

All tests run on an 8-year-old MacBook Air. All results from shipping 7 Mac apps as a solo developer. No sponsored opinion.

HiyokoKit includes APK installation and an Android app manager. Both use ADB under the hood. Here's the implementation.

APK installation

#[tauri::command]
async fn install_apk(apk_path: String) -> Result<String, AppError> {
    let output = tokio::process::Command::new("adb")
        .args(["install", "-r", &apk_path]) // -r = reinstall if exists
        .output()
        .await?;

    let stdout = String::from_utf8_lossy(&output.stdout);
    let stderr = String::from_utf8_lossy(&output.stderr);

    if stdout.contains("Success") {
        Ok("Installation successful".into())
    } else {
        let error = if stderr.contains("INSTALL_FAILED_VERSION_DOWNGRADE") {
            "Cannot install older version over newer. Use -d flag to downgrade."
        } else if stderr.contains("INSTALL_FAILED_ALREADY_EXISTS") {
            "App already installed. Use reinstall option."
        } else {
            "Installation failed"
        };
        Err(AppError::Adb(error.into()))
    }
}

Parse the specific error codes — generic "installation failed" isn't useful to users.

App list

#[derive(Serialize)]
pub struct AppInfo {
    package_name: String,
    is_system: bool,
}

#[tauri::command]
async fn list_apps(include_system: bool) -> Result<Vec<AppInfo>, AppError> {
    let flag = if include_system { "-l" } else { "-3" }; // -3 = third-party only

    let output = tokio::process::Command::new("adb")
        .args(["shell", "pm", "list", "packages", flag])
        .output()
        .await?;

    let apps = String::from_utf8_lossy(&output.stdout)
        .lines()
        .filter_map(|line| {
            line.strip_prefix("package:").map(|pkg| AppInfo {
                package_name: pkg.trim().to_string(),
                is_system: !include_system,
            })
        })
        .collect();

    Ok(apps)
}

App uninstall

#[tauri::command]
async fn uninstall_app(package_name: String) -> Result<(), AppError> {
    let output = tokio::process::Command::new("adb")
        .args(["uninstall", &package_name])
        .output()
        .await?;

    if String::from_utf8_lossy(&output.stdout).contains("Success") {
        Ok(())
    } else {
        Err(AppError::Adb(format!("Failed to uninstall {}", package_name)))
    }
}

Clipboard sync between Android and Mac

#[tauri::command]
async fn push_clipboard_to_android(text: String) -> Result<(), AppError> {
    tokio::process::Command::new("adb")
        .args(["shell", "am", "broadcast", "-a", "clipper.set", "-e", "text", &text])
        .status()
        .await?;
    Ok(())
}

#[tauri::command]
async fn get_android_clipboard() -> Result<String, AppError> {
    let output = tokio::process::Command::new("adb")
        .args(["shell", "am", "broadcast", "-a", "clipper.get"])
        .output()
        .await?;

    // Parse broadcast result for clipboard content
    let stdout = String::from_utf8_lossy(&output.stdout);
    extract_clipboard_from_broadcast(&stdout)
}

Note: clipboard sync via ADB requires Clipper or similar app on the Android device.

Error handling for ADB not found

fn check_adb_available() -> Result<(), AppError> {
    Command::new("adb")
        .arg("version")
        .output()
        .map_err(|_| AppError::Adb(
            "ADB not found. Please install Android Platform Tools.".into()
        ))?;
    Ok(())
}

Check on launch, not on first use. Users should know immediately if ADB is missing.

TL;DR: Building ADB tools in Rust + Tauri: parse specific error codes for APK install (not just "failed"), use pm list packages -3 for third-party apps, and check ADB availability on launch. Clipboard sync needs Clipper on the Android side.

If this was useful, a ❤️ helps more than you'd think — thanks!

HiyokoKit | X → @hiyoyok

Building a Floating AI Assistant That Lives in the Corner of Your Screen

hiyoyo — Sun, 14 Jun 2026 02:25:30 +0000

If this is useful, a ❤️ helps others find it.

All tests run on an 8-year-old MacBook Air.

HiyokoHelper is a 360×440px floating window. Always accessible, never in the way. Cmd+Shift+H brings it to the front from any app.

Window configuration

{
  "app": {
    "windows": [{
      "label": "main",
      "width": 360,
      "height": 440,
      "resizable": false,
      "decorations": false,
      "alwaysOnTop": true,
      "transparent": true,
      "visible": false
    }],
    "macOS": {
      "activationPolicy": "accessory"
    }
  }
}

decorations: false — custom title bar
alwaysOnTop: true — floats above everything
activationPolicy: accessory — no Dock, no Cmd+Tab
visible: false — hidden on launch

Global shortcut from anywhere

let shortcut: Shortcut = "CmdOrCtrl+Shift+H".parse()?;

app.global_shortcut().on_shortcut(shortcut, |app, _, _| {
    if let Some(window) = app.get_webview_window("main") {
        if window.is_visible().unwrap_or(false) {
            window.hide().unwrap();
        } else {
            window.show().unwrap();
            window.set_focus().unwrap();
        }
    }
})?;

Works from any app — VS Code, Terminal, Finder, anywhere.

Draggable without native title bar

.title-bar { -webkit-app-region: drag; }
.title-bar button { -webkit-app-region: no-drag; }

The title bar area drags. Buttons inside are clickable.

Close hides, not quits

#[tauri::command]
pub fn hide_window(window: tauri::Window) {
    window.hide().unwrap();
    // Process stays alive
    // Clipboard monitor keeps running
    // Shortcut still works
}

Launch at login

tauri::Builder::default()
    .plugin(tauri_plugin_autostart::init(
        MacosLauncher::LaunchAgent,
        Some(vec!["--minimized"]),
    ))

Starts hidden at login. Ready for Cmd+Shift+H without ever appearing on screen.

TL;DR: Floating assistant window in Tauri: decorations: false + alwaysOnTop: true + activationPolicy: accessory (no Dock/Cmd+Tab). Global shortcut toggles visibility from any app. -webkit-app-region: drag for dragging without a native title bar. Close hides the window, not the process.

HiyokoHelper (OSS) | X → @hiyoyok

SQLite in a Tauri v2 App — Simple, Reliable, Zero Regrets

hiyoyo — Sat, 13 Jun 2026 15:11:17 +0000

All tests run on an 8-year-old MacBook Air. All results from shipping 7 Mac apps as a solo developer. No sponsored opinion.

I added SQLite to three Tauri apps. Every time I reached for it later than I should have. Here's how I actually use it and why I stopped overthinking the database question.

Why SQLite and not something else

A Tauri app runs on the user's machine. There's no server. There's no network. The database lives in the app's data directory. SQLite is a file. It's fast, reliable, and has zero operational overhead.

For a solo dev shipping desktop apps, this is the correct choice. There's no meaningful alternative worth evaluating.

I use rusqlite directly. No ORM. The queries are simple enough that an ORM adds complexity without benefit.

What I actually use it for

Sync state tracking. HiyokoAutoSync tracks which files have been synced, when, and their hash. Without SQLite this is a mess of JSON files with race condition potential. With SQLite it's a straightforward table with indexed lookups.

CREATE TABLE sync_records (
    id INTEGER PRIMARY KEY,
    file_path TEXT NOT NULL,
    last_synced INTEGER NOT NULL,
    file_hash TEXT NOT NULL,
    direction TEXT NOT NULL
);

App settings that need querying. Simple key-value settings belong in a config file. Settings you need to query — filter, sort, paginate — belong in SQLite.

History and logs. Anything the user might want to browse, search, or filter later. SQLite makes this trivial. A flat file makes this painful.

The Tauri-specific setup

Database path via app_handle:

let db_path = app_handle
    .path()
    .app_data_dir()
    .unwrap()
    .join("app.db");

let conn = Connection::open(&db_path)?;

I initialize the schema on first launch with CREATE TABLE IF NOT EXISTS. Simple, idempotent, no migration framework needed at this scale.

For async Tauri commands, I wrap the connection in Mutex and manage it as app state:

app.manage(Mutex::new(conn));

Not glamorous. Works perfectly.

Where it gets annoying

Blocking calls in async context. rusqlite is synchronous. Tauri commands are async. You need to either use spawn_blocking or accept that you're blocking the thread. For most desktop app use cases, blocking is fine — queries complete in microseconds.

Schema changes. When I need to add a column, I write a manual migration check on startup. For 3-4 migrations across an app's lifetime, this is manageable. If you're doing frequent schema changes, reach for a migration library earlier than I did.

The verdict

SQLite via rusqlite is the correct default for Tauri app persistence. Add it earlier than you think you need it. The migration from "JSON files everywhere" to SQLite mid-project is annoying and avoidable.

The database question for Tauri desktop apps is solved. SQLite. Move on.

TL;DR: SQLite via rusqlite is the right call for Tauri desktop apps — no server, no deps, zero ops overhead. Use app_data_dir() for the DB path, Mutex<Connection> as app state, and CREATE TABLE IF NOT EXISTS for schema init. Add it earlier than you think you need it; migrating from JSON files mid-project is painful.

If this was useful, a ❤️ helps more than you'd think — thanks!

HiyokoAutoSync | X → @hiyoyok

Tauri v2 Cheatsheet — The Commands I Use on Every Project

hiyoyo — Sat, 13 Jun 2026 00:55:47 +0000

All tests run on an 8-year-old MacBook Air. All results from shipping 7 Mac apps as a solo developer. No sponsored opinion.

After 7 Tauri apps, I type the same commands constantly. Here's the reference I wish existed when I started.

Project setup

# New project
npm create tauri-app@latest

# Add to existing project
npm install --save-dev @tauri-apps/cli
npx tauri init

Development

# Dev mode (hot reload)
npm run tauri dev

# Dev with specific log level
RUST_LOG=debug npm run tauri dev

# Dev with backend logs visible
npm run tauri dev 2>&1 | grep -v "^$"

Building

# Standard build
npm run tauri build

# Universal binary (Intel + Apple Silicon)
npm run tauri build -- --target universal-apple-darwin

# Debug build (faster, no optimization)
npm run tauri build -- --debug

Plugins

npm run tauri add global-shortcut
npm run tauri add fs
npm run tauri add shell
npm run tauri add notification

This updates both Cargo.toml and the plugin registration. Faster than doing it manually.

Permissions (tauri.conf.json)

{
  "app": {
    "security": {
      "capabilities": [
        {
          "identifier": "main-capability",
          "description": "Main window capabilities",
          "windows": ["main"],
          "permissions": [
            "fs:read-all",
            "fs:write-all",
            "shell:execute",
            "global-shortcut:allow-register"
          ]
        }
      ]
    }
  }
}

Tauri v2 requires explicit permission declarations. If a command silently does nothing, check permissions first.

Common Rust patterns

// Get app data directory
let data_dir = app.path().app_data_dir().unwrap();

// Emit event to frontend
app_handle.emit("event-name", payload).ok();

// Get window
let window = app.get_webview_window("main").unwrap();

// App state
app.manage(MyState::new());
let state = app.state::<MyState>();

Notarization (macOS)

# Submit for notarization
xcrun notarytool submit app.dmg \
  --apple-id YOUR_APPLE_ID \
  --team-id YOUR_TEAM_ID \
  --password YOUR_APP_PASSWORD \
  --wait

# Staple after notarization
xcrun stapler staple app.dmg

Debugging

# Check what's in the bundle
unzip -l target/release/bundle/macos/App.app/Contents/MacOS/App

# Verify notarization
spctl -a -v App.app

# Check entitlements
codesign -d --entitlements - App.app

The most useful thing I learned

When a Tauri command silently fails: check the browser console first (Cmd+Option+I in dev mode), then check RUST_LOG output, then check permissions.

Silent failures in Tauri are almost always a permissions issue or a missing #[tauri::command] registration.

TL;DR: Quick Tauri v2 command reference: npm run tauri dev / tauri build -- --target universal-apple-darwin / tauri add <plugin>. Silent command failures? Check DevTools console → RUST_LOG → permissions in that order. Almost always a missing permission or unregistered command.

If this was useful, a ❤️ helps more than you'd think — thanks!

HiyokoAutoSync | X → @hiyoyok

The Dev Tools I Actually Use as a Solo Rust + Tauri Developer in 2026

hiyoyo — Fri, 12 Jun 2026 03:05:44 +0000

All tests run on an 8-year-old MacBook Air. All results from shipping 7 Mac apps as a solo developer. No sponsored opinion.

Not a listicle of everything possible. Just what I actually open every day.

Editor: VS Code with specific extensions

rust-analyzer: non-negotiable. Inline type hints, error detection, jump to definition. Rust without rust-analyzer is painful.

Continue: local LLM autocomplete via Ollama. Handles boilerplate and repetitive patterns without API calls.

Even Better TOML: Cargo.toml syntax and validation. Small but useful.

Tauri: official Tauri extension with command palette integration.

AI: three tools, different jobs

Ollama + qwen2.5-coder:1.5b: autocomplete. Runs locally. Never leaves the machine.

Gemini: quick questions, syntax lookups, anything where speed matters more than depth. Free tier covers daily use.

Claude: hard Rust bugs, architecture decisions, anything where being wrong is expensive. Free tier for targeted use.

Terminal: iTerm2

Default macOS Terminal works. iTerm2's split panes are useful when running npm run tauri dev alongside a shell for ADB commands.

Version control: Git + GitHub

Commit before handing off to AI tools. This saved me twice when AI tools made silent regressions — I could diff against the last commit and see exactly what changed.

The rule: never let AI touch code that isn't committed.

Debugging: browser DevTools + RUST_LOG

Tauri apps have a WebView. Cmd+Option+I opens DevTools in dev mode. Frontend bugs debugged exactly like a web app.

Backend: RUST_LOG=debug npm run tauri dev shows Rust log output in the terminal.

Design: minimal

I'm not a designer. For UI, I use Tailwind CSS utility classes and reference existing Mac app conventions. I don't use Figma.

For app icons — my weakest point — I iterate on simple concepts and accept "good enough." The icon isn't the product.

What I don't use

A project management tool (GitHub Issues is enough)
A staging environment (the app runs locally by definition)
A CI/CD pipeline (manual builds, notarize before each release)
A documentation platform (README + dev.to articles)

Solo dev means every tool has to justify its overhead. Most don't.

TL;DR: My daily stack as a solo Rust + Tauri dev: VS Code with rust-analyzer, three-tier AI (Ollama locally, Gemini for quick lookups, Claude for hard bugs), iTerm2, and Git with a strict "commit before AI" rule. No Figma, no CI/CD, no project management tool — if it can't justify its overhead, it's out.

If this was useful, a ❤️ helps more than you'd think — thanks!

HiyokoAutoSync | X → @hiyoyok