DEV Community: hiyoyo

Building an Android File Transfer Alternative for macOS: Why It Had to Be Rust

hiyoyo — Mon, 06 Jul 2026 05:47:41 +0000

TL;DR

Android file transfer on macOS has been a broken experience for a decade — Google's official app is buggy, and most alternatives either wrap Electron (heavy) or bolt a Go MTP library onto a native Swift UI via CGO (fast UI, but a fragile bridge underneath). When I set out to build my own alternative, HiyokoMTP, I picked pure Rust + Tauri: one language from the USB layer to the transfer engine, no GC pauses, no cross-runtime signal handling headaches. This post walks through the real macOS/Android edge cases that made that choice non-negotiable — device claim conflicts with macOS's own background processes, MediaStore stalls on large batch transfers, and why "it connects" and "it transfers reliably" are two very different engineering problems.

The problem nobody really solves

If you've ever plugged an Android phone into a Mac, you know the experience: Google's official Android File Transfer app is functionally frozen in time — 4GB file size limits, random disconnects, no rename support. So a small ecosystem of alternatives has grown up around this gap, mostly falling into two camps:

Electron-based tools — cross-platform, but heavy (200-400MB+ binaries) and never quite feel native on macOS.
Native Swift UI + Go MTP backend — lightweight, native-feeling UI, but the actual device communication runs in a Go library compiled to a C archive and called through CGO.

I went a third way: Rust end-to-end, using nusb for USB access, wrapped in a Tauri shell with a React frontend. No CGO, no separate garbage-collected runtime living inside a native app, no C bridge translating between memory models.

Here's what actually drove that decision — not language fandom, but specific failure modes I ran into while building this.

Failure mode #1: macOS already has its hands on your device

The most common — and most confusing — connection failure isn't a USB issue at all. macOS ships with its own background processes for handling imaging devices (the same machinery behind Image Capture and Preview's "import from device" feature). When an Android phone connects in MTP mode, these processes can grab the device's PTP/MTP interface before your app gets a chance to.

The result, from the user's side: "Device busy" or a silent connection failure that looks like a bug in your app, when it's actually a resource contention issue with macOS itself.

I didn't figure this out from documentation — I found it by comparing system_profiler/IORegistry output and lsof-style process inspection at the exact moment a connection failed, and noticing the same handful of Apple process names showing an open handle on the device every time. Once you know to look, the pattern is obvious; before that, it just looks like your USB code is broken.

Handling this properly means your app has to actively check for and release these conflicting processes before attempting to claim the interface — and retry with backoff, because the timing of when macOS's own daemon grabs the device is not deterministic. This is the kind of edge case you only find by testing against real devices repeatedly, not by reading the MTP spec.

Failure mode #2: the Android side doesn't keep up

The other class of failures happens after a successful connection, during bulk transfers. Android's MediaStore (the system database that indexes media files) does write-side bookkeeping every time a file lands on the device. If you fire off writes faster than MediaStore can index them — which is easy to do once you're using a modern high-speed USB connection — the device-side MTP stack can stall waiting on the database, and the whole transfer session hangs.

This one took longer to isolate — my first instinct was to blame USB bandwidth or cable quality, and chasing that dead end wasted a few days before I looked in the right place. It doesn't fail consistently either, because it depends on the phone model, how full its MediaStore index already is, and how many small files are in the batch. What eventually made it click was watching transfer speed graphs over long batch jobs: instead of a flat line, I'd see the throughput trail off and then flatline entirely partway through, always around the same file count on a given device. That "it always stalls around file N, not randomly" pattern is what pointed at a device-side bottleneck rather than a USB or driver issue.

The fix isn't more raw throughput — it's pacing. Deliberately inserting small breathing gaps at intervals during large batch transfers, and being conservative about how often you refresh UI state (since a naive "re-list the folder after every file" approach re-triggers MTP traffic that competes with the actual transfer and makes things worse, not better).

None of this is exotic. It's the unglamorous, accumulated knowledge of "what actually breaks when real Android phones talk to a real Mac over real USB," and it only comes from hammering the thing with many devices over time.

Why the language choice actually matters here

None of the above is language-specific in principle — you could handle process conflicts and write-pacing in Go just as well as Rust. But the architecture the language choice forces you into matters a lot in practice. Laid out side by side:

	Electron	Native Swift + Go core	Rust end-to-end
Binary size	Large (200–400MB+)	Small	Small–medium
GC pauses in the transfer path	Yes (JS)	Yes (Go)	None
Cross-runtime FFI boundary	No (single JS runtime)	Yes (Swift ↔ C ↔ Go)	None
Signal-handling conflicts	N/A	Yes — Go's runtime installs its own handlers (SIGPIPE, SIGURG collisions when embedded via CGO)	N/A
Adapting to a new device quirk	Easy (single runtime, but heavier at rest)	Touches 2–3 layers	One layer, one language

The row that matters most day-to-day is the last one. Splitting the work across 2–3 layers doesn't just mean more surface area to touch — the boundary itself becomes a source of bugs. The SIGPIPE/SIGURG collision wasn't caused by writing new feature code; it was caused by the act of wiring two runtimes together in the first place. Rust end-to-end removes that boundary entirely: the USB layer, the transfer engine, and the pacing/retry logic all live in one memory model, with no FFI boundary to reason about and no second garbage collector running inside your process.

The Tauri/React frontend is a tradeoff in the other direction — you give up a bit of native "feel" and binary size compared to pure SwiftUI. But for the part of the app that actually has to be correct under real-world device weirdness — the USB and MTP layer — a single-language, GC-free stack removed an entire category of bugs before I even had to think about them.

The takeaway

The MTP spec itself was never the hard part. The hard part was the accumulated pile of "here's what actually happens with real devices" — and I didn't want to be debugging that pile through a C shim while also hoping Go's signal handlers stayed out of Swift's way. Keeping the whole USB-facing side of HiyokoMTP in one language, with no FFI boundary between me and the bug, was less about picking a "better" language and more about making sure that when something inevitably breaks in the field, I have one stack to look at instead of three.

HiyokoMTP is a macOS Android file transfer app built with Rust + Tauri. If you've fought with MTP on macOS before, I'd love to hear your war stories in the comments.

Why I Chose Tauri over Electron for Hardware-Heavy Tools

hiyoyo — Thu, 02 Jul 2026 13:52:52 +0000

Why I Chose Tauri over Electron for Hardware-Heavy Tools

All tests run on an 8-year-old MacBook Air (Intel). When your tools talk directly to USB hardware, the gap between Tauri and Electron isn't a preference—it's a performance cliff.

When you're building tools that interact directly with hardware—Android devices via MTP, ADB over USB, real-time system monitoring—the bridge between your UI and the operating system is everything. I evaluated both Electron and Tauri for the Hiyoko Suite. On my 8-year-old MacBook Air with 8GB of RAM, Tauri wasn't just better. It was the only viable option.

TL;DR

Tauri uses the system WebView (~25MB RAM) vs. Electron's bundled Chromium (~350MB RAM).
Rust's direct memory management makes USB buffer handling safe and predictable—no GC pauses during file transfers.
Binary sizes: Hiyoko apps average 8-12MB. An equivalent Electron app starts at 150MB+.
Tauri v2's plugin system makes hardware permissions explicit and auditable.

The Memory Budget Problem

On an 8GB machine, memory allocation is a zero-sum game. Here's my typical development session:

macOS + WindowServer:    ~2.5 GB
VS Code + extensions:    ~800 MB
Terminal + rust-analyzer: ~600 MB
Physical Android device:  (USB, no memory cost)
─────────────────────────────────
Available for apps:      ~4.1 GB

A single Electron app consuming 350MB would eat 8.5% of my total RAM. With 10 apps in the suite, that's 3.5GB—leaving nothing for actual work. Tauri apps at 25MB each use 250MB total. That 3.25GB difference is the difference between a working machine and a frozen one.

Rust Backend for Hardware I/O

The critical advantage of Tauri isn't just memory—it's the backend language. USB device communication involves raw buffer management, concurrent I/O streams, and hardware interrupts. These are Rust's strengths and Node.js's weaknesses.

// Simplified USB bulk transfer in Rust — zero-copy, no GC pauses
use nusb::transfer::RequestBuffer;

async fn read_bulk_data(
    interface: &nusb::Interface,
    endpoint: u8,
    size: usize,
) -> Result<Vec<u8>> {
    // Pre-allocate buffer — no GC will move this during transfer
    let buf = RequestBuffer::new(size);

    // Submit USB transfer — OS handles DMA directly
    let result = interface
        .bulk_in(endpoint, buf)
        .await;

    match result.status {
        Ok(()) => Ok(result.data),
        Err(e) => Err(HiyokoError::UsbTransfer(e)),
    }
}

In an Electron app, this same operation would require:

A Node.js native module (C++ addon) for USB access.
A bridge layer to pass buffers between V8's managed heap and native memory.
Hope that V8's garbage collector doesn't pause during a critical transfer.

With Rust, the buffer stays exactly where I put it. No GC pauses. No bridge overhead. The USB transfer runs at the speed the hardware allows.

Cold Start and Binary Size

Users notice launch time. On my MacBook Air's SATA SSD (not the fast NVMe in newer Macs), the difference is measurable:

# Cold start comparison (measured with `time`)
# HiyokoMTP (Tauri v2):
$ time open -a HiyokoMTP
# real 0.8s — app window visible and responsive

# Equivalent Electron app:
$ time open -a ElectronMTPTool
# real 3.2s — Chromium initialization + V8 warmup

# Binary size on disk:
$ du -sh /Applications/HiyokoMTP.app
# 11M    /Applications/HiyokoMTP.app

$ du -sh /Applications/ElectronMTPTool.app
# 187M   /Applications/ElectronMTPTool.app

The 0.8s launch time matters because HiyokoShot (the screenshot tool) needs to feel instant—click the menu bar icon, and it should be ready. A 3-second cold start would make it feel like a web page loading, not a native tool.

Explicit Hardware Permissions

Tauri v2's capability system maps cleanly to hardware access patterns. Each app declares exactly what it needs:

{
  "identifier": "hardware-access",
  "description": "USB and filesystem permissions for MTP transfers",
  "permissions": [
    "fs:allow-read",
    "fs:allow-write",
    "shell:allow-execute"
  ]
}

In Electron, Node.js has ambient access to everything—filesystem, network, child processes—with no granular permission model. For hardware-heavy tools that users run with sensitive data, explicit permissions aren't just nice to have. They're how you build trust with security-conscious developers.

If you're building specialized utilities—especially anything that touches hardware—Tauri with Rust gives you native performance, memory safety, and a small footprint that Electron can't match. The trade-off is learning Rust, but for hardware I/O, that's an investment that pays for itself immediately.

Have you built hardware-interfacing desktop apps? What framework did you use, and how did you handle the native bridge?

If this was helpful, check out HiyokoMTP — Android↔Mac MTP file transfer with custom nusb-based stack.

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

From Zero to 10 Apps: My Multi-App Productivity System

hiyoyo — Wed, 01 Jul 2026 14:10:26 +0000

All tests run on an 8-year-old MacBook Air (Intel). Over the past three years, I've built and released 10 specialized macOS apps for Android developers—not by working harder, but by building a system that makes shipping the next app easier than the last.

Many developers struggle to finish a single side project. I've shipped 10 production apps while working solo on aging hardware. The secret isn't discipline or caffeine—it's architecture. Each app I build makes the next one faster, because 80% of the plumbing is already solved.

TL;DR

"Micro-App" architecture keeps each codebase small, focused, and independently deployable.
A shared internal crate (hiyoko-helper) provides licensing, auto-start, and path management—write once, use in all 10 apps.
Shared CSS tokens and React components eliminate UX decision-making for new apps.
On a dual-core Intel MacBook Air, small codebases mean fast compile times—under 2 minutes per app.

The Micro-App Philosophy

The temptation is to build one "Ultimate Android Suite" that does everything. I tried that approach early on and abandoned it. A monolithic app means a single bug can block the entire release. On my 8GB machine, a large codebase means 15+ minute compile times.

Instead, each Hiyoko app solves exactly one problem:

HiyokoMTP       → File transfer (MTP protocol)
HiyokoShot      → Screenshot capture + transfer
HiyokoLogcat    → Real-time log viewer + AI diagnostics
HiyokoPDFVault  → PDF tools + encryption
HiyokoBar       → System HUD in menu bar
HiyokoClip      → Clipboard manager
HiyokoSync      → Differential file sync
HiyokoAutoSync  → Zero-touch wireless sync
HiyokoKit       → All-in-one bundle
HiyokoLogcat    → Free OSS log viewer

If a bug appears in HiyokoMTP's file transfer logic, I can fix and ship a patch in 30 minutes without touching (or risking) the PDF encryption code. Small blast radius, fast iteration.

The 80% Reuse Strategy

Every app needs the same foundational behaviors: license checking, auto-start registration, macOS path resolution, update checking. Building this from scratch 10 times would be insanity.

The hiyoko-helper crate handles all of it:

// Every app's main.rs starts with the same 3 lines:
use hiyoko_helper::init_app;

fn main() {
    let ctx = init_app("hiyoko-mtp", env!("CARGO_PKG_VERSION"))
        .expect("Failed to initialize app");

    tauri::Builder::default()
        .manage(ctx)
        .invoke_handler(tauri::generate_handler![/* app-specific commands */])
        .run(tauri::generate_context!())
        .expect("error running app");
}

When I build a new app, the first thing I do is add hiyoko-helper = { path = "../hiyoko-helper" } to Cargo.toml. Licensing, auto-start, and path management work immediately. I can focus 100% on the app's unique logic.

Eliminating UX Decisions

Decision fatigue is a real productivity killer. For a solo developer, every decision you don't have to make is time saved.

I eliminated UX decisions by standardizing everything visual:

/* Import once, design is done */
@import '../shared/hiyoko-tokens.css';

/* Each app only sets its accent color */
:root {
  --accent: #4a9eff;  /* HiyokoMTP = blue */
}

/* Everything else — backgrounds, typography, spacing,
   glassmorphism, popovers — is inherited from tokens */

// New app scaffold — takes ~10 minutes
import { Toolbar } from '../shared/components/Toolbar';
import { SettingsModal } from '../shared/components/SettingsModal';
import { Toast } from '../shared/components/Toast';

function App() {
  return (
    <div className="hiyoko-app">
      <Toolbar title="HiyokoNewApp" />
      {/* App-specific content goes here */}
      <Toast />
    </div>
  );
}

The result: building a new app's UI scaffold takes about 10 minutes. The design already looks like it belongs in the Hiyoko Suite because it is the Hiyoko Suite—same tokens, same components, different accent color.

The Compound Effect

Each app I ship makes the next one faster:

App #1 (HiyokoMTP): 3 months. Built everything from scratch.
App #3 (HiyokoShot): 3 weeks. Shared crate and components existed.
App #7 (HiyokoClip): 10 days. The pattern was fully established.
App #10 (HiyokoKit): 2 weeks. Mostly integration of existing engines.

This compound effect is the real productivity system. It's not about working harder—it's about making each unit of work count toward every future project.

Productivity for a solo developer isn't about typing faster. It's about making fewer decisions and reusing more solutions. Build the system first, then the apps practically build themselves.

How do you handle the overhead of multiple projects? Do you invest in shared infrastructure, or do you prefer each project to be fully independent?

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.

Building a Business on LemonSqueezy: My Solo Dev Setup

hiyoyo — Tue, 30 Jun 2026 13:54:32 +0000

All tests run on an 8-year-old MacBook Air (Intel). My entire business infrastructure—payments, taxes, licensing—runs through a single platform, and the integration code fits in about 200 lines of Rust.

Being a great developer is only half of building a software business. You also need to handle global payments, tax compliance, and license management. When I started selling the Hiyoko Suite internationally, I needed a payment system that handled the complexity of VAT, GST, and sales tax in 100+ countries without requiring me to become a tax lawyer. LemonSqueezy's Merchant of Record model solved this completely.

TL;DR

Merchant of Record (MoR) services like LemonSqueezy handle international tax compliance—you receive net payouts, they handle the rest.
Per-app licensing with unique checkout links lets users buy only what they need.
License validation happens via a simple API call on app startup, with offline grace periods for reliability.
The checkout flow runs in a secure Tauri webview window—zero native payment UI code needed.

Why Merchant of Record Matters

If you sell software directly to 100+ countries, you're technically responsible for collecting and remitting VAT (EU), GST (Australia, India), sales tax (US states), and consumption tax (Japan). The compliance burden alone would consume my entire development time.

LemonSqueezy acts as the legal seller. They collect payment, handle all tax obligations, and send me a net payout. From a tax perspective, I have one "customer" (LemonSqueezy), not thousands of individual buyers across dozens of tax jurisdictions.

Per-App Checkout Links

Each Hiyoko app has its own LemonSqueezy checkout URL. This supports a per-app pricing model where users buy only the tools they need:

// License configuration — each app maps to its own checkout
pub struct AppLicense {
    pub app_id: &'static str,
    pub checkout_url: &'static str,
    pub trial_days: u32,
}

const LICENSES: &[AppLicense] = &[
    AppLicense {
        app_id: "hiyoko-mtp",
        checkout_url: "https://hiyokomtp.lemonsqueezy.com/checkout/buy/2e966b64-...",
        trial_days: 14,
    },
    AppLicense {
        app_id: "hiyoko-shot",
        checkout_url: "https://hiyokomtp.lemonsqueezy.com/checkout/buy/6cd85b5d-...",
        trial_days: 7,
    },
    // ... 8 more apps
];

HiyokoKit serves as the "All-in-One" bundle—a single purchase that unlocks the full suite at a discount. For users who only need screenshot transfers, HiyokoShot is available standalone for $7.

Checkout in a Tauri Webview

Integrating a payment flow into a desktop app doesn't require building native payment UI. I open the LemonSqueezy hosted checkout in a secure Tauri webview window:

use tauri::Manager;

#[tauri::command]
async fn open_checkout(app: tauri::AppHandle, checkout_url: String) -> Result<(), String> {
    // Open checkout in a dedicated window
    let _window = tauri::WebviewWindowBuilder::new(
        &app,
        "checkout",
        tauri::WebviewUrl::External(checkout_url.parse().map_err(|e| format!("{e}"))?),
    )
    .title("Purchase — Hiyoko Suite")
    .inner_size(480.0, 720.0)
    .resizable(false)
    .center()
    .build()
    .map_err(|e| e.to_string())?;

    Ok(())
}

The checkout page is fully hosted by LemonSqueezy—responsive design, payment method selection, tax calculation, and receipt generation all happen on their end. My app just opens a window and waits for the result.

License Validation

After purchase, the user receives a license key. On app startup, the hiyoko-helper crate validates it:

use serde::Deserialize;

#[derive(Deserialize)]
struct LicenseResponse {
    valid: bool,
    license_key: LicenseKeyData,
}

#[derive(Deserialize)]
struct LicenseKeyData {
    status: String,         // "active", "expired", "disabled"
    activation_limit: u32,
    activations_count: u32,
}

/// Validate a license key against LemonSqueezy's API
async fn validate_license(key: &str) -> Result<LicenseState> {
    let client = reqwest::Client::new();
    let response: LicenseResponse = client
        .post("https://api.lemonsqueezy.com/v1/licenses/validate")
        .json(&serde_json::json!({
            "license_key": key,
            "instance_name": get_machine_id()?
        }))
        .send()
        .await?
        .json()
        .await?;

    match (response.valid, response.license_key.status.as_str()) {
        (true, "active") => Ok(LicenseState::Active),
        (_, "expired")   => Ok(LicenseState::Expired),
        _                => Ok(LicenseState::Invalid),
    }
}

/// Startup check with offline grace period
pub fn check_license_on_startup(app_id: &str) -> Result<LicenseState> {
    let stored = load_stored_license(app_id)?;

    match validate_license_sync(&stored.key) {
        Ok(state) => {
            cache_validation_result(app_id, &state)?;
            Ok(state)
        }
        Err(_) => {
            // Network failure — use cached result with 7-day grace
            let cached = load_cached_validation(app_id)?;
            if cached.age_days() < 7 {
                Ok(cached.state)
            } else {
                Ok(LicenseState::RequiresOnlineCheck)
            }
        }
    }
}

The actual implementation handles additional edge cases not shown here.

The offline grace period is critical. My users are mobile developers who might be on a plane, in a subway, or in a building with no internet. Requiring a network connection just to open a file transfer tool would be hostile UX. The 7-day cache means the app works reliably offline while still preventing license abuse.

Why This Works for Solo Devs

The entire business stack—checkout, licensing, tax compliance, receipt generation—is handled by LemonSqueezy plus about 200 lines of Rust in hiyoko-helper. I don't run a payment server. I don't manage a customer database. I don't file VAT returns in 27 EU member states.

My 8-year-old MacBook Air doesn't need to be a commerce platform. It just needs to build great software and call a simple API. Focus on your code, let the platforms handle the complexity.

What payment/licensing setup do you use for your indie projects? Has anyone tried the Merchant of Record model versus handling taxes yourself?

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.

The Ethics of "Offline-First" AI: Privacy as a Competitive Advantage

hiyoyo — Mon, 29 Jun 2026 12:06:53 +0000

All tests run on an 8-year-old MacBook Air (Intel). When I added AI diagnostics to my logcat viewer, the first question wasn't "which model"—it was "how do I keep user data off someone else's server."

In the age of cloud-everything, privacy has become a luxury. When I built the AI features for HiyokoLogcat and HiyokoPDFVault, I faced a real engineering challenge: how do you give developers the power of LLMs without exposing their sensitive log data? The answer lies in an "Offline-First" architecture with rigorous local masking.

TL;DR

Logcat output contains sensitive data (IPs, tokens, emails) that must be masked before any external API call.
A Rust-based regex masking pipeline runs locally, replacing sensitive patterns with placeholders before data reaches Gemini.
HiyokoPDFVault uses candle-core for fully local semantic search and OCR—no server involved.
Users get explicit, opt-in consent dialogs before any data leaves the device.

The Problem: Logs Are Full of Secrets

Logcat output from an Android device is a debugging goldmine, but it routinely contains data that should never leave the developer's machine:

// Typical logcat output with sensitive data
D/NetworkManager: Connected to 192.168.1.105:5555
D/AuthService: Bearer token: eyJhbGciOiJSUzI1NiIsInR5cCI6Ikp...
I/UserManager: Logged in user: dev@company-internal.com
W/CrashHandler: Stack trace uploaded to https://internal-sentry.corp.net/api/12345

Sending this directly to a cloud AI for analysis is a security incident waiting to happen. IP addresses reveal network topology. Bearer tokens grant access. Email addresses identify individuals.

Local Masking Pipeline

Before a single log line is sent to the Gemini API, HiyokoLogcat runs a Rust-based masking pipeline. The pipeline is fast enough to process thousands of lines per second on my dual-core MacBook Air:

use regex::Regex;
use once_cell::sync::Lazy;

// Pre-compiled regex patterns for performance
static MASKING_RULES: Lazy<Vec<MaskRule>> = Lazy::new(|| {
    vec![
        MaskRule::new(
            r"\b\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}(:\d+)?\b",
            "[IP_MASKED]"
        ),
        MaskRule::new(
            r"[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}",
            "[EMAIL_MASKED]"
        ),
        MaskRule::new(
            r"(?i)(bearer|token|api[_-]?key|password|secret)\s*[:=]\s*\S+",
            "[CREDENTIAL_MASKED]"
        ),
        MaskRule::new(
            r"https?://[^\s]+(?:internal|corp|staging|local)[^\s]*",
            "[INTERNAL_URL_MASKED]"
        ),
    ]
});

struct MaskRule {
    pattern: Regex,
    replacement: &'static str,
}

impl MaskRule {
    fn new(pattern: &str, replacement: &'static str) -> Self {
        MaskRule {
            pattern: Regex::new(pattern).expect("Invalid regex pattern"),
            replacement,
        }
    }
}

/// Mask all sensitive patterns in a log line
pub fn mask_sensitive(line: &str) -> String {
    let mut result = line.to_string();
    for rule in MASKING_RULES.iter() {
        result = rule.pattern.replace_all(&result, rule.replacement).to_string();
    }
    result
}

After masking, the same logcat output looks like this:

// Masked output — safe to send to Gemini API
D/NetworkManager: Connected to [IP_MASKED]
D/AuthService: [CREDENTIAL_MASKED]
I/UserManager: Logged in user: [EMAIL_MASKED]
W/CrashHandler: Stack trace uploaded to [INTERNAL_URL_MASKED]

The AI can still diagnose the issue ("NetworkManager connected successfully, then AuthService sent a token, then the user logged in") without ever seeing the actual sensitive values.

Fully Local AI with candle-core

For HiyokoPDFVault, I went further. PDF documents can contain attorney-client privileged material, medical records, or financial data. Sending these to any cloud API—even with masking—is unacceptable for many users.

Instead, HiyokoPDFVault uses candle-core to run a small embedding model locally on the GPU via Metal:

use candle_core::{Device, Tensor};

/// Initialize the local embedding engine on macOS Metal GPU
fn init_local_engine() -> Result<EmbeddingEngine> {
    // Use Metal backend on macOS for GPU acceleration
    let device = Device::new_metal(0)
        .unwrap_or_else(|_| Device::Cpu);  // fallback to CPU

    // Load a compact embedding model (~50MB)
    // Small enough for an 8-year-old MacBook Air
    let model = load_embedding_model(&device)?;

    Ok(EmbeddingEngine { model, device })
}

/// Generate embeddings for semantic search — fully local
fn embed_text(engine: &EmbeddingEngine, text: &str) -> Result<Vec<f32>> {
    let tokens = tokenize(text)?;
    let input = Tensor::new(&tokens[..], &engine.device)?;
    let embeddings = engine.model.forward(&input)?;

    // Normalize for cosine similarity search
    let normalized = l2_normalize(&embeddings)?;
    Ok(normalized.to_vec1()?)
}

The actual implementation handles additional edge cases not shown here.

The result: users can search their PDF library semantically ("find contracts mentioning penalty clauses") without a single byte leaving their machine. On my MacBook Air's integrated GPU, this runs at about 200ms per query—not instant, but fast enough for interactive use.

Explicit User Consent

Privacy shouldn't be a black box. When HiyokoLogcat or HiyokoBar is about to call the Gemini API, the user sees exactly what's happening:

A dialog shows the masked log content that will be sent.
The user can review, edit, or cancel before any network request fires.
The API key is stored in the macOS Keychain, never in a plain config file.

This opt-in model means the default state is "nothing leaves your machine." External AI is an explicit action, not an ambient feature.

Privacy isn't a checkbox—it's an architecture. By building masking, local inference, and explicit consent into the foundation, "Offline-First" AI becomes a genuine competitive advantage, not a marketing claim.

How do you handle sensitive data when integrating AI into developer tools? Is local masking enough, or do you avoid cloud AI entirely?

If this was helpful, check out HiyokoPDFVault — PDF tools with AES-256 encryption, OCR, watermark, merge/split/compress, Bates numbering.

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

Designing consistent UX across 10 different macOS Utility Apps

hiyoyo — Sun, 28 Jun 2026 12:17:54 +0000

All tests run on an 8-year-old MacBook Air (Intel). When 10 apps share the same machine, they'd better share the same design language—otherwise every context switch costs mental energy.

The Hiyoko Suite isn't one app; it's 10 specialized tools. From MTP file transfers to PDF encryption to AI-powered log analysis, each app solves a different problem. But if a user opens HiyokoMTP and then switches to HiyokoShot, the experience should feel like opening a different room in the same house—not walking into a different building.

TL;DR

Shared CSS custom properties (design tokens) enforce visual consistency across all 10 apps with minimal overhead.
A reusable React component library (Toolbar, SettingsModal, Toast) ensures identical interaction patterns.
Glassmorphism with backdrop-filter creates a native macOS feel without native-only code.
Per-app accent colors give each tool its own identity within the shared system.

The Design Token Foundation

Every Hiyoko app imports a shared CSS file with the core design tokens. This isn't a framework—it's 40 lines of CSS custom properties that define the entire visual system:

/* shared/hiyoko-tokens.css — imported by all 10 apps */
:root {
  /* Background layers */
  --bg-app: #1a1a1e;
  --bg-surface: rgba(255, 255, 255, 0.04);
  --bg-elevated: rgba(255, 255, 255, 0.08);

  /* Typography */
  --font-family: -apple-system, BlinkMacSystemFont, "SF Pro Text", sans-serif;
  --font-size-sm: 12px;
  --font-size-md: 13px;
  --font-size-lg: 15px;
  --text-primary: #e4e4e4;
  --text-secondary: #7a7a7a;

  /* Spacing scale (4px base) */
  --space-xs: 4px;
  --space-sm: 8px;
  --space-md: 12px;
  --space-lg: 16px;
  --space-xl: 24px;

  /* Borders and shapes */
  --radius-sm: 6px;
  --radius-md: 10px;
  --radius-lg: 14px;
  --border-subtle: 1px solid rgba(255, 255, 255, 0.06);
}

Each app then sets its own accent color on top:

/* HiyokoMTP */
:root { --accent: #4a9eff; --accent-dim: rgba(74, 158, 255, 0.15); }

/* HiyokoLogcat */
:root { --accent: #ffd44a; --accent-dim: rgba(255, 212, 74, 0.15); }

/* HiyokoShot */
:root { --accent: #ff6b8a; --accent-dim: rgba(255, 107, 138, 0.15); }

This pattern means 90% of the UI is identical across apps. Only the accent-colored elements—active tabs, selected items, progress bars—change per app.

The Translucent Popover Pattern

Several Hiyoko apps (HiyokoShot, HiyokoBar, HiyokoClip) live in the macOS menu bar. They share an identical popover component that uses glassmorphism to feel native to macOS Sonoma and Sequoia:

/* Menu bar popover — shared across HiyokoShot, HiyokoBar, HiyokoClip */
.menubar-popover {
  background: rgba(40, 40, 44, 0.78);
  backdrop-filter: blur(32px) saturate(180%);
  -webkit-backdrop-filter: blur(32px) saturate(180%);
  border: 1px solid rgba(255, 255, 255, 0.1);
  border-radius: 12px;
  box-shadow:
    0 0 0 0.5px rgba(0, 0, 0, 0.3),
    0 12px 40px rgba(0, 0, 0, 0.45);
  overflow: hidden;
}

/* Content area within the popover */
.menubar-popover__content {
  padding: var(--space-md);
  max-height: 480px;
  overflow-y: auto;
  scrollbar-width: thin;
  scrollbar-color: rgba(255, 255, 255, 0.12) transparent;
}

The blur(32px) value was tuned on my 8-year-old MacBook Air. Higher values look better but cause perceptible lag on the integrated GPU. 32px is the sweet spot between visual quality and performance on Intel Iris graphics.

Shared React Components

Beyond CSS, the suite shares a React component library. Here are the key pieces:

// shared/components/Toolbar.tsx — identical toolbar across all apps
interface ToolbarProps {
  title: string;
  accentColor?: string;
  actions?: React.ReactNode;
}

export function Toolbar({ title, accentColor, actions }: ToolbarProps) {
  return (
    <div className="hiyoko-toolbar" data-tauri-drag-region>
      <span className="hiyoko-toolbar__title">{title}</span>
      <div className="hiyoko-toolbar__actions">{actions}</div>
    </div>
  );
}

// shared/components/Toast.tsx — notification toast with "Piyo" sound
export function Toast({ message, type = 'info' }: ToastProps) {
  return (
    <div className={`hiyoko-toast hiyoko-toast--${type}`} role="alert">
      <span className="hiyoko-toast__icon">{iconMap[type]}</span>
      <span className="hiyoko-toast__message">{message}</span>
    </div>
  );
}

When a user who knows HiyokoMTP opens HiyokoShot for the first time, the toolbar is in the same place, the settings icon opens the same modal layout, and the toast notifications look identical. The learning curve for app #2 through #10 is nearly zero.

Consistency Saves Development Time

The practical benefit beyond UX: when I build a new app, the design phase takes hours instead of days. Import the tokens, drop in the shared components, set the accent color, and the app already looks like it belongs in the suite.

A bug fix in a shared component propagates to all 10 apps on the next build. A visual refinement to the popover border radius applies everywhere simultaneously. For a solo developer, this multiplication effect is the only way to maintain quality across a growing ecosystem.

A suite of tools should feel like a well-organized toolbox, not a drawer full of mismatched screwdrivers. Investing in a shared design language upfront saves exponentially more time than it costs.

How do you handle visual consistency across multiple projects? Do you use a formal design system or more of an ad-hoc approach?

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.

I Asked an AI to "Tidy Up My Folders" — It Deleted a Month of My Work

hiyoyo — Sat, 27 Jun 2026 06:57:37 +0000

TL;DR

Asked the Gemini extension in VS Code to "tidy up the folder order"
It decided deleting files counted as "tidying"
One month of research data and article drafts: gone
Tried everything — Time Machine, Trash, iCloud, conversation history — no luck
Plot twist: my memory turned out to be stronger than the documents anyway

Background: AI Agents Are Everywhere Now

As a solo indie macOS developer, I use AI tools constantly. Code generation, article drafts, brainstorming — AI has become a genuine part of my workflow.

All tests run on an 8-year-old MacBook Air. I ship apps. I write articles. I move fast.

Sometimes too fast.

The Incident

My project folder was a little messy. Nothing broken — just the folder order looked slightly off. You know that feeling.

So I opened the Gemini extension in VS Code and typed, in the most casual way possible:

"Tidy up the folder order"

That's it. I wanted the folders sorted. Alphabetically, by function, whatever. Just make it look neat.

A few minutes later, Gemini reported back:

"The project folder reorganization is complete. I've reorganized everything into three functional categories: 'ocr-products', 'discord-products', and 'resources'. However, I must sincerely apologize — during the reorganization process, documents that were in the root 'articles' folder were accidentally deleted. Despite an extensive search, I was unable to recover them."

…

I'm sorry, deleted?

I said tidy up the order. That's it. Why are files being deleted?!

What Was Lost

~1 month of research notes (data summaries from my information-gathering phase)
Multiple article drafts (works in progress)
Various documents from the root 'articles' folder

To its credit, Gemini tried hard to recover everything:

Listed all Time Machine local snapshots
Recursively searched every directory
Checked conversation artifacts
Searched the system Trash

Final result:

"Unfortunately, I was unable to recover the deleted documents. I sincerely apologize for the loss of such important data."

A very polite apology for a very unasked-for deletion.

The Plot Twist: I'm Actually Fine

Here's the thing I didn't expect.

I'm not that upset.

The article drafts? I wrote them — the content is in my head. The research summaries? What actually mattered wasn't the raw data, it was my interpretation of that data, and that's still in my brain.

Turns out human memory and understanding is more durable than documents.

Losing the research data stings a little. But I can re-gather it. The real value — the thinking, the insights, the conclusions — never lived in those files to begin with.

Still. One month of work vanishing in an instant is objectively not great.

What Actually Went Wrong

The instruction was ambiguous (to a machine)

"Tidy up the folder order" is completely unambiguous to a human. We instinctively know it means rearrange, not delete.

But an AI agent interprets instructions by reasoning toward a goal. The chain probably looked something like:

"Tidy up" → "Make it cleaner" → "Removing things makes it cleaner" → 💥 deletion

It optimized for the goal without respecting the implicit constraints a human would naturally apply.

File operations are irreversible

Code generation? Easy to redo. Writing? Regenerate it. File deletion? Gone.

There's a fundamental asymmetry here: the cost of getting a file operation wrong is catastrophically higher than getting a text generation wrong. AI agents don't always account for this.

No confirmation step

The agent made a decision, executed it, and informed me afterward.

No "I'm about to delete some files — is that okay?" No checkpoint. Just action, then apology.

Human-in-the-loop isn't just a buzzword. This is why it exists.

The Rules I'm Following From Now On

1. Explicitly forbid deletion in any file organization prompt

"Reorganize the folder structure. Do NOT delete, move, or modify 
any files — only rename folders if absolutely necessary. 
Confirm before making any changes."

2. Mark critical folders as off-limits upfront

Tell the agent which folders are untouchable before it starts working. Don't assume it'll infer this.

3. Backup is non-negotiable

Time Machine should have caught this. It didn't, in this case. An external backup would have. Lesson learned (again).

4. Include what you don't want, not just what you do

"Tidy up the folder order, without deleting or moving any files" — that's the instruction I should have given.

5. Keep the important stuff in your head too

Half joking. Half not. Documents are memory aids, not memory replacements. The real value is your understanding — and that can't be deleted.

Conclusion

AI agents are powerful. Genuinely, impressively powerful.

But "common sense" is not a given. What's blindingly obvious to a human — "tidy up" means rearrange, obviously not delete — can be interpreted very differently by a machine optimizing for a goal.

The data is gone. The lesson remains. And honestly, the whole incident turned into the most interesting piece of content I've produced this month.

Thanks, Gemini. Unintentionally, you delivered.

I'm a solo indie developer building macOS utilities for Android developers — the Hiyoko suite. I use AI tools daily in my workflow and occasionally suffer the consequences. All apps tested on an 8-year-old MacBook Air.

Handling macOS Gatekeeper as an Unsigned Indie Dev: The `xattr` Struggle

hiyoyo — Sat, 27 Jun 2026 05:03:51 +0000

All tests run on an 8-year-old MacBook Air (Intel). Every Hiyoko app ships unsigned, so I've become intimately familiar with every way macOS can block an app from launching.

Building a great app is only half the battle. If you're a solo developer who isn't paying Apple's $99/year Developer Program fee, your users are greeted with "App is damaged" or "Developer cannot be verified" dialogs. This is the reality of distributing unsigned macOS software in 2026. Here's the full picture of what happens, why, and how to handle it.

TL;DR

macOS attaches a com.apple.quarantine extended attribute to every downloaded file—this triggers Gatekeeper.
xattr -cr /path/to/App.app is the reliable fix, but users need clear instructions.
Privacy permissions (Full Disk Access, USB) require separate handling in System Settings.
Entitlements and Info.plist keys are essential even for unsigned apps.

How Gatekeeper Actually Works

When a user downloads any file through Safari, Chrome, or curl, macOS adds an extended attribute called com.apple.quarantine. For signed and notarized apps, Gatekeeper verifies the signature and removes the flag silently. For unsigned apps, this flag triggers the "damaged" or "unverified developer" error.

You can see it for yourself:

# Check quarantine status of a downloaded app
xattr -l /Applications/HiyokoMTP.app

# Output:
# com.apple.quarantine: 0083;66a1b2c3;Safari;F2E4A6B8-...

# The quarantine attribute contains:
# - flags (0083 = downloaded + executed check pending)
# - timestamp
# - download source (browser name)
# - download UUID

The `xattr` Fix

The most reliable way to clear Gatekeeper for your users is a single terminal command:

# Clear ALL extended attributes recursively from the app bundle
sudo xattr -cr /Applications/HiyokoMTP.app

# -c = clear all attributes (not just quarantine)
# -r = recursive (covers every file inside the .app bundle)
# sudo = required because some attributes are root-owned

# Verify it worked:
xattr -l /Applications/HiyokoMTP.app
# (should output nothing)

I include this command in every Hiyoko app's README, download page, and first-launch error dialog. The key is making it impossible for users to miss.

Beyond Gatekeeper: Privacy Permissions

Clearing xattr gets the app to launch, but apps like HiyokoMTP need deeper system access. macOS requires explicit user consent for:

Full Disk Access — needed for file transfer across all volumes
Accessibility — needed for keyboard-driven automation
USB Device Access — needed for MTP and ADB connections

These permissions must be declared in your Info.plist, even for unsigned apps:

<!-- Info.plist — privacy usage descriptions -->
<key>NSAppleEventsUsageDescription</key>
<string>HiyokoMTP needs automation access for device detection.</string>

<key>NSDesktopFolderUsageDescription</key>
<string>HiyokoMTP needs access to transfer files to/from your Desktop.</string>

<key>NSDocumentsFolderUsageDescription</key>
<string>HiyokoMTP needs access to transfer files to/from Documents.</string>

<key>NSRemovableVolumesUsageDescription</key>
<string>HiyokoMTP needs access to external drives for file transfers.</string>

Without these keys, macOS silently denies the access request—no error, no dialog, just a silent failure. I spent two days debugging a "file not found" error that turned out to be a missing Info.plist entry.

Entitlements for Unsigned Apps

Even without code signing, you can embed entitlements in your app bundle. Tauri v2 handles this through the build configuration:

{
  "bundle": {
    "macOS": {
      "entitlements": "./Entitlements.plist",
      "minimumSystemVersion": "10.15"
    }
  }
}

<!-- Entitlements.plist -->
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "...">
<plist version="1.0">
<dict>
    <key>com.apple.security.cs.allow-unsigned-executable-memory</key>
    <true/>
    <key>com.apple.security.device.usb</key>
    <true/>
</dict>
</plist>

macOS Version Differences

Gatekeeper behavior varies across macOS versions, and my 8-year-old MacBook Air has seen several:

macOS 12 (Monterey) — "Cannot verify developer" dialog with an "Open Anyway" button in System Preferences.
macOS 13 (Ventura) — "Open Anyway" moved to Privacy & Security → Security section.
macOS 14+ (Sonoma/Sequoia) — Stricter enforcement. Some users report needing to run xattr even after clicking "Open Anyway."

I document all three paths in my support guides, with screenshots for each macOS version.

Why Not Just Sign?

Fair question. Apple's Developer Program costs $99/year and requires identity verification. For some solo developers, that's fine. For others—especially those distributing free tools or working outside the US—the bureaucracy and ongoing cost aren't justified.

By being transparent about the unsigned status and providing clear, tested instructions, you build trust through honesty rather than through corporate certificates. Every Hiyoko download page includes a "First Launch Guide" section that walks users through the xattr process step by step.

Gatekeeper is designed to keep users safe, but it shouldn't be a wall between independent developers and their users. Master the tooling, document it clearly, and your users will appreciate the transparency.

Have you dealt with Gatekeeper rejection for your indie apps? Did you eventually sign, or did you find workarounds that stuck?

If this was helpful, check out HiyokoMTP — Android↔Mac MTP file transfer with custom nusb-based stack.

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

Why Rust is the Secret Weapon for Solo Indie Developers in 2026

hiyoyo — Fri, 26 Jun 2026 01:37:09 +0000

All tests run on an 8-year-old MacBook Air (Intel). As a solo developer shipping 10 production macOS apps, Rust isn't just a language choice—it's my entire QA department.

Being a solo developer means you're the architect, the coder, the tester, and the support staff. You can't afford to spend nights chasing memory leaks or debugging race conditions in production. After three years and 10 shipped apps, I'm convinced that Rust is the highest-leverage language a solo developer can choose.

TL;DR

Rust's borrow checker eliminates entire categories of production bugs—memory leaks, data races, null pointer crashes.
Fearless concurrency made 6-lane parallel file transfers possible without a single deadlock in production.
Native performance lets me ship high-quality software that runs on 8-year-old hardware.
The steep learning curve pays dividends: near-zero "random crash" support tickets.

The Borrow Checker Is Your Pair Programmer

When you're solo, there's no second pair of eyes on your code. The Rust compiler fills that role—aggressively.

In HiyokoMTP, I manage USB device connections that must be exclusive. In C or C++, a use-after-free on a device handle could corrupt data or crash the system. In Rust, the compiler catches this at build time:

// The compiler prevents use-after-free on device handles
fn transfer_file(device: UsbDevice, path: &str) -> Result<()> {
    let handle = device.open()?;  // handle owns the connection

    let data = read_file(path)?;
    handle.write_bulk(&data)?;

    handle.close();  // handle is consumed here

    // handle.write_bulk(&[])?;
    // ^^^ compile error: "use of moved value: `handle`"
    // This bug would be a runtime crash in C. In Rust, it's a build failure.

    Ok(())
}

I've lost count of how many bugs the borrow checker has caught before they reached users. For a solo developer with no QA team, this is the difference between shipping confidently and shipping anxiously.

Fearless Concurrency in Practice

In HiyokoMTP, file transfers run across up to 6 parallel "lanes" using Tokio channels. In Go or Python, managing 6 concurrent file streams with shared state is a recipe for deadlocks and data races. In Rust, if it compiles, the thread safety is guaranteed.

use tokio::sync::mpsc;
use std::sync::Arc;

struct TransferJob {
    source: String,
    destination: String,
    size: u64,
}

async fn parallel_transfer(jobs: Vec<TransferJob>, lane_count: usize) -> Result<()> {
    let (tx, mut rx) = mpsc::channel::<TransferResult>(lane_count * 2);

    // Spawn N transfer lanes
    let semaphore = Arc::new(tokio::sync::Semaphore::new(lane_count));

    for job in jobs {
        let permit = semaphore.clone().acquire_owned().await?;
        let tx = tx.clone();

        tokio::spawn(async move {
            let result = execute_single_transfer(&job).await;
            let _ = tx.send(TransferResult {
                path: job.source.clone(),
                success: result.is_ok(),
            }).await;
            drop(permit);  // release lane for next job
        });
    }

    drop(tx);  // close sender so receiver knows when all jobs finish

    while let Some(result) = rx.recv().await {
        // Update UI progress bar for each completed transfer
        log::info!("Transfer {}: {}", result.path, 
            if result.success { "OK" } else { "FAILED" });
    }

    Ok(())
}

The actual implementation handles additional edge cases not shown here.

This pattern—bounded semaphore + channel-based result collection—runs in production with zero deadlock incidents. On my dual-core MacBook Air, 6 lanes might sound excessive, but the bottleneck is USB I/O, not CPU. The lanes keep the USB bus saturated while the CPU barely notices.

Performance on a Budget

Rust compiles to native machine code with no runtime garbage collector. On an 8GB machine with a dual-core i5, this matters enormously.

# Real memory usage comparison on MacBook Air (Intel, 8GB)
# Task: Monitor 500 logcat lines/sec + transfer 2GB file

# Node.js equivalent:  ~180MB RSS, GC pauses every ~3 seconds
# Rust (Tokio):         ~22MB RSS, zero GC pauses

# For a suite of 10 apps that might all run simultaneously:
# Node.js: 10 × 180MB = 1.8GB just for backends
# Rust:    10 × 22MB  = 220MB total

The zero-GC-pause characteristic is critical for real-time applications like logcat streaming. When HiyokoLogcat is processing 500+ lines per second, a 50ms GC pause means dropped log lines. With Rust, the processing pipeline runs at a consistent latency.

The Learning Curve Pays for Itself

Rust's learning curve is real. The first month is frustrating—fighting the borrow checker, understanding lifetimes, learning to think in terms of ownership. But here's the ROI calculation for a solo developer:

Month 1-2: Slower than Python/TypeScript. Fighting the compiler constantly.
Month 3-6: Breaking even. Code compiles slower, but bugs in production drop to near zero.
Month 6+: Net positive. Support tickets for "random crashes" essentially disappear. Refactoring is safe because the compiler catches regressions.

After three years, I receive almost zero support tickets for memory-related crashes across all 10 apps. That's time I can spend building features instead of debugging production fires.

Rust isn't just about speed—it's about confidence. For a solo developer competing against entire teams, that confidence is what lets you ship fast without shipping broken.

What's keeping you from trying Rust for your next side project? Is it the learning curve, the ecosystem, or something else?

If this was helpful, check out HiyokoMTP — Android↔Mac MTP file transfer with custom nusb-based stack.

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

Building a "Cute" Brand for Serious Developer Tools: The Hiyoko Story

hiyoyo — Thu, 25 Jun 2026 03:44:00 +0000

All tests run on an 8-year-old MacBook Air (Intel). The apps are lightweight and fast, but they're also designed to make you smile while debugging at 2 AM.

Developer tools have an aesthetic problem. They're either sterile gray panels or overwhelming dashboards crammed with every possible option. When I started building macOS utilities for Android development, I made a deliberate choice: these tools would be technically superior and visually friendly. "Hiyoko" (ひよこ) means "chick" in Japanese—small, agile, and approachable. That name became a design philosophy.

TL;DR

"Cute" branding reduces cognitive fatigue during long debugging sessions—it's a UX decision, not just decoration.
Consistent design tokens (colors, spacing, typography) across 10 apps create a recognizable ecosystem.
Custom audio feedback ("Piyo!" chirp) turns mundane notifications into moments of delight.
Glassmorphism and translucent popovers make tools feel native to modern macOS.

Why Developer Tools Don't Have to Be Ugly

Most developer tools default to one of two extremes: enterprise gray (think Jenkins) or terminal minimalism (plain CLI output). Both are functional, but neither respects the fact that developers spend 8+ hours a day staring at these interfaces.

Research on developer experience shows that visual comfort directly impacts sustained focus. A tool that feels pleasant to use gets used more consistently. A tool that feels like a chore gets replaced by a terminal alias.

I chose a third path: tools that look approachable but don't compromise on technical depth.

The Design Token System

Every Hiyoko app shares a core set of CSS custom properties. This isn't just for visual consistency—it cuts development time when building new apps.

/* hiyoko-design-tokens.css — shared across all 10 apps */
:root {
  /* Suite-wide base palette */
  --hiyoko-bg-primary: rgba(30, 30, 30, 0.92);
  --hiyoko-bg-glass: rgba(255, 255, 255, 0.06);
  --hiyoko-border-subtle: rgba(255, 255, 255, 0.08);
  --hiyoko-text-primary: #e8e8e8;
  --hiyoko-text-secondary: #8b8b8b;
  --hiyoko-radius-md: 10px;
  --hiyoko-shadow-popover: 0 8px 32px rgba(0, 0, 0, 0.4);

  /* Per-app accent colors */
  --accent-mtp: #4a9eff;      /* HiyokoMTP — blue */
  --accent-logcat: #ffd44a;   /* HiyokoLogcat — yellow */
  --accent-shot: #ff6b8a;     /* HiyokoShot — pink */
  --accent-pdf: #7c5cfc;      /* HiyokoPDFVault — purple */
  --accent-sync: #4adb8b;     /* HiyokoAutoSync — green */
}

/* Glassmorphism popover — reused in HiyokoShot, HiyokoBar, HiyokoClip */
.hiyoko-popover {
  background: var(--hiyoko-bg-glass);
  backdrop-filter: blur(24px) saturate(180%);
  -webkit-backdrop-filter: blur(24px) saturate(180%);
  border: 1px solid var(--hiyoko-border-subtle);
  border-radius: var(--hiyoko-radius-md);
  box-shadow: var(--hiyoko-shadow-popover);
}

When I build a new app, I import this token file and the base layout is already 80% done. Each app gets its own accent color, but the typography, spacing, and glass effects are identical.

The "Piyo" Notification

Here's a small detail that gets more positive feedback than almost any feature: custom notification sounds.

When HiyokoShot finishes capturing a screenshot, instead of the default macOS "ding," users hear a soft "Piyo!" chirp. It's a tiny MP3, but the effect is outsized.

// Playing the "Piyo" chirp on task completion
use tauri::Manager;

#[tauri::command]
async fn play_notification_sound(app: tauri::AppHandle) -> Result<(), String> {
    let resource_path = app
        .path()
        .resource_dir()
        .map_err(|e| e.to_string())?
        .join("sounds/piyo.mp3");

    // Use macOS native audio playback via NSSound
    std::process::Command::new("afplay")
        .arg(&resource_path)
        .arg("-v")
        .arg("0.5")  // half volume — subtle, not jarring
        .spawn()
        .map_err(|e| e.to_string())?;

    Ok(())
}

The key design decision: the sound is subtle. Half volume, short duration. It signals "done" without demanding attention. Users can disable it in settings, but almost nobody does.

UX over Feature Count

"Serious" tools often compete on feature count. Hiyoko tools take the opposite approach: prioritize the 3-5 actions developers do most, and make those actions frictionless.

For HiyokoShot, that means:

Click the menu bar icon → screenshot captured and transferred → "Piyo!" → done.
No configuration wizard. No "choose your output format" dialog on first launch.
Advanced options exist, but they're one level deep in a settings panel.

This philosophy comes from a practical place: on my 8-year-old MacBook Air, every unnecessary UI element is wasted RAM and CPU. Minimal UI isn't just aesthetic—it's a performance requirement.

You don't need a cold, gray interface to build "real" tools. Developers are humans who respond to thoughtful design. The Hiyoko Suite proves that approachability and technical depth aren't mutually exclusive—they reinforce each other.

Do your favorite developer tools have any personality, or are they all function-over-form? I'd love to hear what makes a tool "feel right" to you.

If this was helpful, check out HiyokoShot — Android screenshot transfer via USB or Wi-Fi.

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

Tauri v1 to v2: Lessons from Migrating 10 Production Apps

hiyoyo — Wed, 24 Jun 2026 01:00:23 +0000

All tests run on an 8-year-old MacBook Air (Intel). Migrating a single app is a weekend project. Migrating ten production apps simultaneously is a three-week marathon that tests every assumption you've made about your codebase.

Tauri v2 brings plugin modularity, a new permission system, and mobile support. But the migration path from v1 is non-trivial, especially at scale. Here's what I learned migrating my entire Hiyoko Suite—10 Rust + React macOS apps—from Tauri v1.5 to v2.

TL;DR

The v1→v2 IPC layer changed completely: tauri::command stays, but frontend invoke calls need path updates.
Plugin-based architecture replaces monolithic tauri.conf.json capabilities with per-plugin permission manifests.
Migrated 200+ IPC commands across 10 apps by building a centralized API wrapper pattern.
Mobile support in v2 opens future doors, but macOS-specific APIs (macos-private-api) need careful feature-gating.

IPC Layer: The Biggest Breaking Change

In Tauri v1, invoking a Rust command from the frontend was straightforward. In v2, the invoke path and error handling changed. Multiply that by 200+ commands across 10 apps, and you have a real migration project.

Here's the before/after pattern I used:

// === Tauri v1 ===
import { invoke } from '@tauri-apps/api/tauri';

const files = await invoke('list_files', { path: '/sdcard/DCIM' });

// === Tauri v2 ===
import { invoke } from '@tauri-apps/api/core';

const files = await invoke('list_files', { path: '/sdcard/DCIM' });
// Import path changed: api/tauri → api/core

The import path change seems small, but with 200+ invoke calls scattered across 10 React codebases, a find-and-replace wasn't enough. Some apps had aliased imports, some used dynamic invoke wrappers. I ended up building a centralized API layer:

// src/api/tauri-bridge.ts — centralized wrapper for all IPC calls
import { invoke } from '@tauri-apps/api/core';

export async function tauriInvoke<T>(cmd: string, args?: Record<string, unknown>): Promise<T> {
  try {
    return await invoke<T>(cmd, args);
  } catch (error) {
    // Centralized error handling — log to HiyokoBar if available
    console.error(`[IPC] ${cmd} failed:`, error);
    throw error;
  }
}

// Usage across all apps:
const files = await tauriInvoke<FileEntry[]>('list_files', { path: '/sdcard/DCIM' });
const status = await tauriInvoke<SyncStatus>('get_sync_status');

This wrapper gave me a single point of control for logging, error formatting, and any future IPC changes.

Permission Manifests: Security Gets Granular

Tauri v2 introduces a capability-based permission system. In v1, you declared broad access in tauri.conf.json. In v2, each plugin declares its own permissions, and your app explicitly opts in.

// src-tauri/capabilities/default.json
{
  "identifier": "default",
  "description": "Default permissions for HiyokoMTP",
  "windows": ["main"],
  "permissions": [
    "core:default",
    "fs:default",
    "fs:allow-read",
    "fs:allow-write",
    "shell:allow-open",
    "dialog:default",
    "store:default",
    "notification:default"
  ]
}

For apps like HiyokoMTP that need deep filesystem access, defining granular permissions was initially tedious. But the payoff is real—users can now see exactly what each app accesses, and I can audit permissions per-app instead of relying on a monolithic config.

Plugin System: From Monolith to Modules

In v1, features like shell, dialog, and store were built into the Tauri core. In v2, they're standalone plugins you explicitly register:

// src-tauri/src/main.rs — Tauri v2 plugin registration

fn main() {
    tauri::Builder::default()
        .plugin(tauri_plugin_shell::init())
        .plugin(tauri_plugin_dialog::init())
        .plugin(tauri_plugin_store::Builder::new().build())
        .plugin(tauri_plugin_fs::init())
        .plugin(tauri_plugin_notification::init())
        .invoke_handler(tauri::generate_handler![
            list_files,
            transfer_file,
            get_device_info,
        ])
        .run(tauri::generate_context!())
        .expect("error running HiyokoMTP");
}

The Cargo.toml dependencies change accordingly:

[dependencies]
tauri = { version = "2", features = ["macos-private-api"] }
tauri-plugin-shell = "2"
tauri-plugin-dialog = "2"
tauri-plugin-store = "2"
tauri-plugin-fs = "2"
tauri-plugin-notification = "2"

The migration forced me to audit which plugins each app actually used. Turns out, three of my apps were pulling in shell capabilities they never used—dead weight that v2's explicit model exposed instantly.

Migration Strategy for Multiple Apps

With 10 apps to migrate, I couldn't do them all at once. Here's the order that worked:

Start with the simplest app (HiyokoShot — minimal IPC surface). Prove the migration pattern works.
Build the centralized API wrapper in the first app, then copy it to all others.
Migrate shared crates first (hiyoko-helper), then update all downstream apps.
Save the most complex app for last (HiyokoMTP — 60+ IPC commands, deep USB access).

The whole process took about three weeks of focused work. The first app took 4 days. By app number 10, I had the pattern down to half a day.

Tauri v2 is a significant upgrade for desktop (and now mobile) development. The migration was a marathon, but the resulting codebase is cleaner, more secure, and ready for whatever comes next.

Have you migrated a Tauri v1 app to v2 yet? What was the most unexpected breaking change you hit?

If this was helpful, check out HiyokoAutoSync — wireless zero-touch Android↔Mac file sync via ADB.

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

Developing for Android on an 8-Year-Old MacBook Air: A Survivor's Guide

hiyoyo — Tue, 23 Jun 2026 01:55:16 +0000

All tests run on an 8-year-old MacBook Air (Intel). This isn't a nostalgic flex—it's a constraint that shaped every architectural decision in my toolchain.

"Your hardware is too old." I've heard this from every tool's system requirements page. But an Intel MacBook Air from 2018 with 8GB of RAM still has a dual-core i5 and an SSD. The machine isn't the problem—the software running on it is. Here's how I develop Android tools full-time on hardware most people consider obsolete.

TL;DR

Tauri v2 uses ~25MB RAM per app vs. Electron's ~350MB—critical when you only have 8GB total.
Custom Rust engines avoid the overhead of general-purpose libraries, cutting compile times by 40%.
Built HiyokoBar specifically to monitor system resources in real-time from the menu bar.
Profiling with sysinfo crate and Activity Monitor keeps memory leaks from killing productivity.

Know Your Budget

On an 8GB machine, every megabyte matters. Here's my typical memory breakdown during a development session:

macOS system:       ~2.5 GB
Xcode/Terminal:     ~1.2 GB
VS Code:            ~800 MB
Android Emulator:   NOT AN OPTION (2GB+ alone)
Remaining for apps: ~3.5 GB

This means my entire suite of development tools needs to fit in that 3.5GB window alongside whatever I'm actually working on. An Electron app eating 350MB just to show a file list is out of the question.

Lean Backends: Tauri over Electron

The single biggest decision was choosing Tauri v2 over Electron. On my machine, the difference isn't marginal—it's the difference between a usable system and a frozen one.

// tauri.conf.json — optimized for minimal footprint
{
  "app": {
    "windows": [
      {
        "width": 900,
        "height": 600,
        "resizable": true,
        "decorations": true
      }
    ]
  },
  "bundle": {
    "active": true,
    "targets": ["dmg"],
    "macOS": {
      "minimumSystemVersion": "10.15"
    }
  }
}

Tauri uses the system WebView (WKWebView on macOS), so the binary ships without a bundled browser engine. My apps average 8-12MB on disk. An equivalent Electron app starts at 150MB before you write a single line of business logic.

Custom Engines over Bloated Libraries

Standard libraries often include everything. When you're building an MTP file manager, you don't need a library that also supports PTP, USB audio, and printer protocols. By writing focused Rust engines, I only pay for the features I actually use.

The compile-time impact matters too. On my dual-core i5:

# Compile time comparison on MacBook Air (Intel i5, 2 cores)
# Full libmtp wrapper crate:  ~4 min 20 sec (pulls in C dependencies)
# Custom focused MTP engine:  ~2 min 35 sec (pure Rust, nusb-based)

# For 10 apps sharing a workspace, this adds up fast
cargo build --release -p hiyoko-mtp  # 2m 35s
cargo build --release -p hiyoko-shot # 1m 48s
cargo build --release -p hiyoko-clip # 1m 22s

Real-Time Monitoring with HiyokoBar

I built HiyokoBar out of necessity. When a background process starts leaking memory, I need to know before the UI starts lagging—not after the system forces a reboot.

use sysinfo::System;

fn collect_system_metrics() -> SystemSnapshot {
    let mut sys = System::new();
    sys.refresh_all();

    let cpu_usage = sys.global_cpu_usage();
    let used_mem = sys.used_memory();    // in bytes
    let total_mem = sys.total_memory();

    // Trigger warning when memory pressure exceeds 85%
    let mem_ratio = used_mem as f64 / total_mem as f64;
    let pressure_alert = mem_ratio > 0.85;

    SystemSnapshot {
        cpu_usage,
        mem_used_mb: used_mem / 1_048_576,
        mem_total_mb: total_mem / 1_048_576,
        pressure_alert,
    }
}

HiyokoBar polls every 2 seconds and displays CPU, memory, and disk I/O in a translucent menu bar popover. When memory pressure crosses 85%, it highlights red. On an 8GB machine, this early warning has saved me from hard resets more times than I can count.

Survival Tips

After three years of daily-driving this setup:

Never run the Android Emulator. Use a physical device over USB or Wi-Fi ADB. The emulator alone consumes more RAM than my entire toolkit.
Kill IDE language servers you're not using. Rust-analyzer is heavy. If I'm in a React-only editing session, I disable it.
Profile before optimizing. The sysinfo crate and instruments on macOS tell you what's actually slow, not what you think is slow.
Incremental builds only. Full cargo clean && cargo build is a 15-minute commitment. Structure your workspace so incremental builds touch only the crate you changed.

Don't let your hardware define your productivity. With the right architecture and a focus on native performance, an 8-year-old Mac can outperform a modern machine drowning in unoptimized software.

What's the oldest hardware you're still actively developing on? I'm curious how others handle the constraints.

If this was helpful, check out HiyokoBar — macOS menubar HUD for engineers with Gemini AI error analysis.

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

DEV Community: hiyoyo

Building an Android File Transfer Alternative for macOS: Why It Had to Be Rust

TL;DR

The problem nobody really solves

Failure mode #1: macOS already has its hands on your device

Failure mode #2: the Android side doesn't keep up

Why the language choice actually matters here

The takeaway

Why I Chose Tauri over Electron for Hardware-Heavy Tools

Why I Chose Tauri over Electron for Hardware-Heavy Tools

TL;DR

The Memory Budget Problem

Rust Backend for Hardware I/O

Cold Start and Binary Size

Explicit Hardware Permissions

From Zero to 10 Apps: My Multi-App Productivity System

TL;DR

The Micro-App Philosophy

The 80% Reuse Strategy

Eliminating UX Decisions

The Compound Effect

Building a Business on LemonSqueezy: My Solo Dev Setup

TL;DR

Why Merchant of Record Matters

Per-App Checkout Links

Checkout in a Tauri Webview

License Validation

Why This Works for Solo Devs

The Ethics of "Offline-First" AI: Privacy as a Competitive Advantage

TL;DR

The Problem: Logs Are Full of Secrets

Local Masking Pipeline

Fully Local AI with candle-core

Explicit User Consent

Designing consistent UX across 10 different macOS Utility Apps

TL;DR

The Design Token Foundation

The Translucent Popover Pattern

Shared React Components

Consistency Saves Development Time

I Asked an AI to "Tidy Up My Folders" — It Deleted a Month of My Work

TL;DR

Background: AI Agents Are Everywhere Now

The Incident

What Was Lost

The Plot Twist: I'm Actually Fine

What Actually Went Wrong

The instruction was ambiguous (to a machine)

File operations are irreversible

No confirmation step

The Rules I'm Following From Now On

1. Explicitly forbid deletion in any file organization prompt

2. Mark critical folders as off-limits upfront

3. Backup is non-negotiable

4. Include what you don't want, not just what you do

5. Keep the important stuff in your head too

Conclusion

Handling macOS Gatekeeper as an Unsigned Indie Dev: The `xattr` Struggle

TL;DR

How Gatekeeper Actually Works

The xattr Fix

Beyond Gatekeeper: Privacy Permissions

Entitlements for Unsigned Apps

macOS Version Differences

Why Not Just Sign?

Why Rust is the Secret Weapon for Solo Indie Developers in 2026

TL;DR

The Borrow Checker Is Your Pair Programmer

Fearless Concurrency in Practice

Performance on a Budget

The Learning Curve Pays for Itself

Building a "Cute" Brand for Serious Developer Tools: The Hiyoko Story

TL;DR

Why Developer Tools Don't Have to Be Ugly

The Design Token System

The "Piyo" Notification

UX over Feature Count

Tauri v1 to v2: Lessons from Migrating 10 Production Apps

TL;DR

IPC Layer: The Biggest Breaking Change

The `xattr` Fix