DEV Community

Cover image for Why I Built my Own Suite of Android Tools for macOS in Rust
hiyoyo
hiyoyo

Posted on

Why I Built my Own Suite of Android Tools for macOS in Rust

#android #mac #tauri #rust

All tests run on an 8-year-old MacBook Air (Intel). Every tool in my suite has to earn its place on this machine—if it can't run lean here, it doesn't ship.

Developing for Android on macOS should be seamless, but the reality is different. "Android File Transfer" crashes mid-copy. ADB wrappers eat 400MB of RAM just to sit idle. Xcode updates break USB device detection. After years of fighting with these tools on my aging MacBook Air, I stopped waiting for someone else to fix them and started building my own.

The result is the Hiyoko Suite—10 specialized macOS utilities for Android development, all built with Rust and Tauri v2.

TL;DR

  • Built 10+ Android dev tools for macOS using Rust (Tauri v2) + React to replace bloated alternatives.
  • Custom Rust-based MTP engine replaces macOS's broken "Android File Transfer" with 6-lane parallel transfers.
  • Entire suite runs on an 8-year-old Intel MacBook Air with under 80MB total RAM footprint.
  • Local-first architecture: sensitive data never leaves the device unless the user explicitly opts in.

The Problem with Existing Tools

The standard Android-on-Mac workflow is held together with duct tape. Here's what I was dealing with:

  • Android File Transfer: Apple's default MTP handler. Crashes on files over 4GB. No progress indicators. No batch operations. Hasn't been updated in years.
  • Electron-based ADB GUIs: 300-500MB of RAM for a UI wrapper around a CLI tool. On my 8GB machine, that's unacceptable.
  • IDE-bundled tools: Android Studio's built-in logcat and device manager work, but they require the entire IDE to be running.

I needed standalone, lightweight tools that did one thing well.

Why Rust + Tauri v2

The decision to use Rust wasn't about hype. When you're dealing with MTP (Media Transfer Protocol) or real-time ADB log streaming, memory safety and concurrency aren't optional—they're the difference between a smooth UI and a kernel panic.

Tauri v2 was the natural pairing. Instead of bundling Chromium (Electron), Tauri uses the system WebView. The difference on my machine is dramatic:

// Typical memory footprint comparison on my 8-year-old MacBook Air
// Electron-based ADB tool:  ~350MB RSS
// Tauri v2 equivalent:       ~25MB RSS
// Savings per app:           ~325MB

// With 10 apps in the suite, that's the difference between
// "my laptop is on fire" and "I forgot they were running"
Enter fullscreen mode Exit fullscreen mode

The Tauri v2 project structure keeps things clean across the suite:

# Cargo.toml — each app is a lean, focused binary
[package]
name = "hiyoko-mtp"
version = "2.4.0"
edition = "2021"

[dependencies]
tauri = { version = "2", features = ["macos-private-api"] }
serde = { version = "1", features = ["derive"] }
tokio = { version = "1", features = ["rt-multi-thread", "fs"] }

# Custom MTP engine — no libmtp dependency
hiyoko-mtp-core = { path = "../hiyoko-mtp-core" }

# Shared suite utilities (licensing, auto-start, paths)
hiyoko-helper = { path = "../hiyoko-helper" }
Enter fullscreen mode Exit fullscreen mode

Building the Ecosystem

Each app in the suite solves one specific pain point:

  • HiyokoMTP — File transfers that actually work, with a custom Rust-based MTP stack built on nusb.
  • HiyokoShot — One-click Android screenshot capture over USB or Wi-Fi.
  • HiyokoLogcat — Real-time log viewer with Gemini AI diagnostics (free, open-source).
  • HiyokoPDFVault — PDF tools with AES-256 encryption and local OCR.
  • HiyokoBar — System HUD in the menu bar with Gemini-powered error analysis.

The key architectural decision was keeping each app independent but sharing a core hiyoko-helper crate for licensing, path management, and auto-start behavior. This means I can ship a hotfix for HiyokoMTP without touching the PDF code.

// hiyoko-helper/src/lib.rs — shared across all 10 apps
pub mod licensing;
pub mod autostart;
pub mod paths;
pub mod updater;

/// Every app calls this on startup
pub fn init_suite_app(app_id: &str) -> Result<AppContext> {
    let paths = paths::resolve_app_dirs(app_id)?;
    let license = licensing::validate_or_trial(&paths)?;
    autostart::register_if_enabled(app_id, &paths)?;

    Ok(AppContext { paths, license })
}
Enter fullscreen mode Exit fullscreen mode

The actual implementation handles additional edge cases not shown here.

What I Learned

Three years and 10 apps later, here's what stuck:

  1. Solve your own pain first. Every Hiyoko app started as a script I wrote for myself. If it saved me 10 minutes a day, it became an app.
  2. Rust's compiler is your QA team. As a solo developer, I don't have dedicated testers. The borrow checker catches entire categories of bugs before they reach users.
  3. Lightweight beats feature-rich. Users on older hardware (and there are more of us than you'd think) will choose the 25MB tool over the 350MB one every time.

Building your own tools is the deepest way to understand your workflow. The Hiyoko Suite started as a personal quest for efficiency and turned into a production-grade ecosystem that runs on hardware most people would have recycled.

Have you ever built an internal tool that outgrew its original purpose? What made you decide to ship it?

If this was helpful, check out HiyokoKit — all-in-one Android dev toolkit (MTP file manager, Logcat+AI, ADB Tools, Monitor).

Built with Rust + Tauri v2. Tested on an 8-year-old MacBook Air.

Top comments (0)