DEV Community: hiyoyo

Adding AI Error Analysis to a macOS Menu Bar App with Gemini API

hiyoyo — Mon, 20 Apr 2026 12:38:41 +0000

When a monitored script fails, most tools just show you a red icon.
HiyokoBar does something better: it automatically sends the error output to Gemini AI and displays a diagnosis — no copy-pasting logs, no context switching.
Here's how I built it.

The Problem
Engineers spend a surprising amount of time doing this:

Script fails
Copy error output
Open browser
Paste into ChatGPT/Claude/Gemini
Read diagnosis
Switch back to terminal

This is 2026. The AI should come to you.

Architecture
Each monitor card in HiyokoBar has an analyze_errors toggle. When enabled:

Script runs via std::process::Command
Non-zero exit code detected
stdout + stderr sent to Gemini API
Response displayed as "AI Insight" panel in golden color

The entire flow is automatic. Zero user interaction required.

Implementation
The Gemini API Call
rustuse reqwest::Client;
use serde_json::json;

pub async fn analyze_error(
error_output: &str,
api_key: &str,
) -> Result> {
let prompt = format!(
"You are a senior engineer analyzing a script error. \
Provide a concise diagnosis (2-3 sentences max) and the most likely fix.\n\n\
Error output:\n{}",
error_output
);

let client = Client::new();
let response = client
    .post("https://generativelanguage.googleapis.com/v1beta/models/gemini-2.5-flash:generateContent")
    .header("X-goog-api-key", api_key)
    .json(&json!({
        "contents": [{
            "parts": [{"text": prompt}]
        }],
        "generationConfig": {
            "maxOutputTokens": 256,
            "temperature": 0.3
        }
    }))
    .send()
    .await?;

let data: serde_json::Value = response.json().await?;
let text = data["candidates"][0]["content"]["parts"][0]["text"]
    .as_str()
    .unwrap_or("Analysis unavailable")
    .to_string();

Ok(text)

}
Key decisions:

gemini-2.5-flash for speed and cost efficiency
maxOutputTokens: 256 — engineers want diagnosis, not essays
temperature: 0.3 — factual, not creative

Triggering the Analysis
rustasync fn run_monitor(monitor: &Monitor, api_key: Option<&str>) -> MonitorResult {
let output = Command::new(&monitor.command)
.args(&monitor.args)
.output()
.await;

match output {
    Ok(out) if out.status.success() => MonitorResult::Success(
        String::from_utf8_lossy(&out.stdout).to_string()
    ),
    Ok(out) => {
        let error_text = format!(
            "stdout: {}\nstderr: {}",
            String::from_utf8_lossy(&out.stdout),
            String::from_utf8_lossy(&out.stderr)
        );

        // Only analyze if AI is enabled and key is available
        let insight = if monitor.analyze_errors {
            if let Some(key) = api_key {
                analyze_error(&error_text, key).await.ok()
            } else {
                None
            }
        } else {
            None
        };

        MonitorResult::Error { error_text, insight }
    }
    Err(e) => MonitorResult::Error {
        error_text: e.to_string(),
        insight: None,
    }
}

}
The AI Insight UI
On the React side, the insight panel appears with a golden glow when an AI diagnosis is available:
tsx{result.insight && (
<motion.div
initial={{ opacity: 0, y: -8 }}
animate={{ opacity: 1, y: 0 }}
className="mt-2 p-3 rounded-lg border border-yellow-500/30 bg-yellow-500/10"

<div className="flex items-center gap-2 mb-1">
  <Sparkles className="w-3 h-3 text-yellow-400" />
  <span className="text-xs font-bold text-yellow-400">AI INSIGHT</span>
</div>
<p className="text-xs text-yellow-200/80">{result.insight}</p>

)}

Storing the API Key Securely
Never put API keys in config files. I use macOS Keychain via the keyring crate:
rustuse keyring::Entry;

pub fn save_gemini_key(key: &str) -> keyring::Result<()> {
Entry::new("hiyoko-bar", "gemini-api-key")?.set_password(key)
}

pub fn load_gemini_key() -> keyring::Result {
Entry::new("hiyoko-bar", "gemini-api-key")?.get_password()
}
The key lives in Keychain, never touches disk as plaintext.

Result
The AI Insight feature turns HiyokoBar from a "pretty dashboard" into an actual engineering tool. When your Docker container crashes at 2am, you want a diagnosis in your menu bar — not another tab to open.

HiyokoBar: https://hiyokoko.gumroad.com/l/hiyokobar

🇯🇵 日本語版: https://hiyokoko.gumroad.com/l/hiyokobar_jp

🐤 Launched on Product Hunt today — would love your support!
https://www.producthunt.com/products/hiyokobar

X: @hiyoyoko

I Just Launched HiyokoBar on Product Hunt

hiyoyo — Mon, 20 Apr 2026 07:33:58 +0000

I was alt-tabbing 10 times a morning just to check Docker status and GitHub PRs.

This is 2026. That information should come to you.

So I built HiyokoBar — an always-on dashboard that lives in your macOS menu bar. Set up any shell script to run on a schedule. Results surface as glass cards, right where you're already looking. Error detected? Gemini AI diagnoses it instantly. Full GUI, zero JSON required.

Built with Rust + Tauri 2.0. Shipped in one day by reusing architecture from my Hiyoko app family.

🛒 Get it on Gumroad:
🌏
English: https://hiyokoko.gumroad.com/l/hiyokobar
🇯🇵Japanese:https://hiyokoko.gumroad.com/l/hiyokobar_jp

🚀 Launched on Product Hunt today:
https://www.producthunt.com/products/hiyokobar

Would love your feedback! 🐤💐

I Built and Shipped a $39 macOS App in One Day (Here's How)

hiyoyo — Mon, 20 Apr 2026 07:16:09 +0000

Yesterday I had an idea. Today it's on Gumroad making money.
Here's exactly how I shipped HiyokoBar — a menu bar HUD for engineers — in a single day.

The Idea
I was constantly alt-tabbing to check Docker status, GitHub PRs, server health.
I wanted something that pushes information to me, not something I have to pull from.
Raycast is great but it's Pull-type. You invoke it when you need it.
I wanted a HUD that's always there — like a cockpit instrument panel for my Mac.

The Unfair Advantage: Code Reuse
I didn't start from zero. I have a portfolio of macOS utility apps built with Rust + Tauri 2.0, and I ruthlessly reused everything I could:
ComponentSourceMenu bar skeletonHiyokoHelper (internal app)Keychain storageHiyokoKitGumroad license authHiyokoShotParallel executionHiyokoAutoSyncGemini AI integrationHiyokoLogcat
The menu bar app architecture — tray icon, click to show/hide, window positioning — was already battle-tested. I just dropped in new features.
This is why building a product suite matters more than one-off apps.

Timeline
Morning

Copied HiyokoHelper as the base
Replaced window positioning with tauri-plugin-positioner
Got the HUD dropping down from the menu bar icon

Midday

Built the shell script execution engine in Rust
Card UI in React with Framer Motion animations
Polling with random jitter to avoid CPU spikes

Afternoon

Gemini AI error analysis (ported from HiyokoLogcat)
GUI settings editor — no JSON required
Drag & drop card reordering
Real-time countdown timers

Evening

Gumroad license auth (ported from HiyokoShot)
macOS Keychain for API key storage
OWASP security audit (caught a critical A02 bug — API keys were stored in plain JSON instead of Keychain)
i18n (Japanese / English)
Gumroad listing, README, pricing

Total: ~8 hours

The Security Audit Saved Me
Before shipping, I ran through OWASP Top 10 for native apps.
Found a critical bug: despite the design doc saying "store in Keychain," the actual implementation was saving API keys in plain JSON.
A quick audit before shipping caught what code review missed.
Always check OWASP before you ship. Even for "simple" apps.

Pricing: $39 One-Time
I originally planned $29. Looked at what I built and charged $39.
The target is senior engineers. They don't blink at $39 for a tool they'll use every day. Underpricing signals low quality to this audience.

What's Next

Product Hunt launch this week
v3.0 ideas: community recipe store, macOS notifications, multi-AI support

Try It

HiyokoBar: https://hiyokoko.gumroad.com/l/hiyokobar

🇯🇵 日本語版: https://hiyokoko.gumroad.com/l/hiyokobar_jp

🐤 Launched on Product Hunt today — would love your support!
https://www.producthunt.com/products/hiyokobar

X: @hiyoyoko

How I Built a macOS Menu Bar HUD with Rust + Tauri 2.0

hiyoyo — Mon, 20 Apr 2026 05:45:12 +0000

I recently built HiyokoBar — a push-type HUD for engineers that lives in the macOS menu bar and runs shell scripts on a schedule, displaying results as beautiful cards.
Here's a technical breakdown of the interesting parts.

Tech Stack

Backend: Rust / Tauri 2.0 / Tokio / Reqwest
Frontend: React + TypeScript + Tailwind CSS + Framer Motion
AI: Google Gemini API
Auth: Gumroad License API + SHA256 + macOS Keychain

Menu Bar App with Tauri 2.0
Tauri 2.0 makes menu bar apps surprisingly straightforward. The key is configuring the window to behave like a native HUD.
rust// tauri.conf.json
{
"app": {
"windows": [{
"visible": false,
"decorations": false,
"alwaysOnTop": true,
"skipTaskbar": true
}]
}
}
For positioning the window directly below the tray icon, I used tauri-plugin-positioner:
rustuse tauri_plugin_positioner::{Position, WindowExt};

fn show_window(app: &AppHandle) {
let window = app.get_webview_window("main").unwrap();
let _ = window.move_window(Position::TrayBottomCenter);
window.show().unwrap();
window.set_focus().unwrap();
}

Shell Script Execution with Jitter
Running multiple scripts simultaneously causes CPU spikes. I solved this by adding random jitter to each script's execution offset:
rustuse tokio::time::{sleep, Duration};
use rand::Rng;

async fn start_monitor(monitor: Monitor, tx: Sender) {
let offset = rand::thread_rng().gen_range(0..10);
sleep(Duration::from_secs(offset)).await;

loop {
    let result = execute_command(&monitor).await;
    tx.send(result).unwrap();
    sleep(Duration::from_secs(monitor.interval_secs)).await;
}

}

Command Execution — Why It's Safe
I use std::process::Command with explicit argument separation, which calls execve directly without a shell:
rustasync fn execute_command(monitor: &Monitor) -> MonitorResult {
let output = Command::new(&monitor.command)
.args(&monitor.args)
.output()
.await?;

// ...

}
This means even if a user types ; rm -rf / in the args field, it's treated as a literal string argument — not shell syntax. No injection possible at the OS level.

Gemini AI Error Analysis
When a script exits with a non-zero code and analyze_errors is enabled, I send the stdout/stderr to Gemini:
rustasync fn analyze_error(output: &str, api_key: &str) -> Result {
let prompt = format!(
"Analyze this error output and provide a concise diagnosis:\n\n{}",
output
);

let response = reqwest::Client::new()
    .post("https://generativelanguage.googleapis.com/v1beta/models/gemini-2.5-flash:generateContent")
    .header("X-goog-api-key", api_key)
    .json(&serde_json::json!({
        "contents": [{"parts": [{"text": prompt}]}]
    }))
    .send()
    .await?;

// parse response...

}

Secure API Key Storage with macOS Keychain
Never store API keys in plain JSON files. I use the keyring crate to store secrets in macOS Keychain:
rustuse keyring::Entry;

fn save_api_key(key: &str) -> Result<()> {
let entry = Entry::new("hiyoko-bar", "gemini-api-key")?;
entry.set_password(key)?;
Ok(())
}

fn load_api_key() -> Result {
let entry = Entry::new("hiyoko-bar", "gemini-api-key")?;
entry.get_password()
}

License Verification with Machine Binding
To prevent license sharing, I bind each license to a machine fingerprint:
rustuse sha2::{Sha256, Digest};

fn get_machine_id() -> String {
let uuid = get_io_platform_uuid(); // IOPlatformUUID via IOKit
let hostname = hostname::get().unwrap_or_default();

let mut hasher = Sha256::new();
hasher.update(format!("{}{}", uuid, hostname.to_string_lossy()));

format!("{:.16x}", hasher.finalize())

}
The license is verified against Gumroad's API on first activation, then cached locally with a 7-day offline grace period.

Window Hide on Focus Loss
A subtle but important UX detail — the HUD should disappear when you click elsewhere:
rustwindow.on_window_event(|event| {
if let WindowEvent::Focused(false) = event {
window.hide().unwrap();
}
});

Result
The app went from idea to Gumroad listing in a single day, reusing architecture from my previous Tauri apps. Rust + Tauri 2.0 is an incredibly productive stack for macOS utilities.
HiyokoBar: https://hiyokoko.gumroad.com/l/hiyokobar

🇯🇵 日本語版: https://hiyokoko.gumroad.com/l/hiyokobar_jp

🐤 Launched on Product Hunt today — would love your support!
https://www.producthunt.com/products/hiyokobar

X: @hiyoyoko

1,000-Page PDF. No Freeze. Here's the Rendering Architecture That Made It Possible. [Devlog #4]

hiyoyo — Mon, 20 Apr 2026 02:33:12 +0000

My first implementation was simple.

Open PDF → render all pages → dump into the DOM.

It worked fine up to about 100 pages. At 300 it started dragging. At 1,000 the app froze for 8 seconds on open.

The fix wasn't clever. It was just the right architecture from the start — and here's exactly what that looks like.

The core problem: rendering what you can't see

Loading a 1,000-page PDF shouldn't mean processing 1,000 pages of content. At any given moment, a user sees maybe 2-3 pages.

The solution is virtual scrolling — only render what's visible, destroy what isn't.

The tricky part for PDFs specifically: you need each page's dimensions before rendering it, so the scroll container knows its total height. PDF pages aren't always the same size.

I solve this upfront with lopdf, reading just the MediaBox from each page:

pub fn get_page_sizes(doc: &Document) -> Vec<(f64, f64)> {
    doc.page_iter().map(|page_id| {
        let page = doc.get_object(page_id).unwrap();
        let media_box = page.as_dict()
            .and_then(|d| d.get(b"MediaBox"))
            .and_then(|o| o.as_array())
            .map(|arr| (
                arr[2].as_float().unwrap_or(595.0),
                arr[3].as_float().unwrap_or(842.0),
            ))
            .unwrap_or((595.0, 842.0));
        media_box
    }).collect()
}

This runs instantly — no rendering, just metadata. Now the scroll container knows exactly how tall it needs to be.

Ghost Batch: eliminating process spawn overhead

Virtual scrolling alone still caused jank. Every scroll event fired a new render request, and each one had process spawn overhead.

Ghost Batch fixes this by queuing render requests and processing them together:

Without Ghost Batch:
scroll → spawn process → render page A → return
scroll → spawn process → render page B → return

With Ghost Batch:
scroll → queue page A
scroll → queue page B
queue threshold hit → spawn once → render A + B together → return

This alone cut process creation overhead by ~90% in practice.

Intelligent Prefetch: rendering ahead of the user

Detect scroll direction, pre-render the next 2 pages in the background:

const handleScroll = (e: React.UIEvent) => {
  const { scrollTop, clientHeight } = e.currentTarget;
  const direction = scrollTop > prevScrollTop.current ? 'down' : 'up';
  const visiblePages = getVisiblePages(scrollTop, clientHeight);

  const prefetchPages = direction === 'down'
    ? [visiblePages.last + 1, visiblePages.last + 2]
    : [visiblePages.first - 1, visiblePages.first - 2];

  prefetchPages
    .filter(p => p >= 0 && p < totalPages)
    .forEach(p => prefetchPage(p));

  prevScrollTop.current = scrollTop;
};

By the time the user scrolls to the next page, it's already rendered.

Results

Metric	Before	After
1,000-page open time	~8s freeze	Near-instant
Memory usage	All pages	~3x visible pages
Scroll jank	Noticeable	Gone

Current state (dev build)

1,000+ pages, no freeze. The architecture holds.

Next devlog

Magic Pipeline — chaining OCR → compress → save into a single click. The workflow automation engine behind it.

Hiyoko PDF Vault → https://hiyokoko.gumroad.com/l/HiyokoPDFVault
X → @hiyoyok

Most "privacy-focused" PDF Tools Make One Quiet Compromise. Mine Doesn't. [Devlog #3]

hiyoyo — Sun, 19 Apr 2026 03:33:48 +0000

Most "privacy-focused" PDF tools make one quiet compromise.
They still phone home.

Hiyoko doesn't. Not once.

Here's the architecture decision behind that —
and what breaks if you get the encryption wrong.

The rule I set on day one

The app only touches the network when the user explicitly asks it to.

PDFs carry contracts, medical records, tax documents. A lot of tools still run background telemetry or license checks while you work. I didn't want any of that.

Everything in Hiyoko PDF Vault runs locally. No exceptions.

Why AES-256-GCM — and what breaks with CBC

This is where most implementations quietly fail.

Mode	Integrity check	What happens if someone tampers with the file
AES-256-CBC	None	You decrypt corrupted garbage. Silently.
AES-256-GCM	Built-in (AEAD)	Decryption fails immediately. You know.

CBC encrypts fine — but it has no authentication. That means a tampered ciphertext can decrypt into something without raising any alarm. You'd need to bolt on HMAC separately, and that's exactly where implementation mistakes happen.

GCM gives you encryption + integrity in one pass. Wrong password or modified file → immediate failure, clear error. No ambiguity.

Rust implementation

Using the aes-gcm crate:

use aes_gcm::{
    aead::{Aead, KeyInit, OsRng},
    Aes256Gcm, Nonce,
};
use aes_gcm::aead::rand_core::RngCore;

pub fn encrypt_pdf(data: &[u8], key: &[u8; 32]) -> Result, String> {
    let cipher = Aes256Gcm::new(key.into());

    let mut nonce_bytes = [0u8; 12];
    OsRng.fill_bytes(&mut nonce_bytes);
    let nonce = Nonce::from_slice(&nonce_bytes);

    let ciphertext = cipher
        .encrypt(nonce, data)
        .map_err(|e| e.to_string())?;

    // prepend nonce so we can recover it on decrypt
    let mut result = nonce_bytes.to_vec();
    result.extend_from_slice(&ciphertext);
    Ok(result)
}

pub fn decrypt_pdf(data: &[u8], key: &[u8; 32]) -> Result, String> {
    if data.len() < 12 {
        return Err("data too short".to_string());
    }
    let (nonce_bytes, ciphertext) = data.split_at(12);
    let cipher = Aes256Gcm::new(key.into());
    let nonce = Nonce::from_slice(nonce_bytes);

    cipher
        .decrypt(nonce, ciphertext)
        .map_err(|_| "decryption failed — wrong password or corrupted file".to_string())
}

Nonce is randomly generated on every encrypt call. Same file encrypted twice → completely different output. Makes pattern analysis useless.

Key derivation: why Argon2id over bcrypt

User passwords are variable length, so we need a fixed 32-byte key. The choice of KDF matters more than most people realize.

pub fn derive_key(password: &str, salt: &[u8]) -> [u8; 32] {
    let mut key = [0u8; 32];
    Argon2::default()
        .hash_password_into(password.as_bytes(), salt, &mut key)
        .expect("key derivation failed");
    key
}

Argon2id is memory-hard. Brute-forcing it requires not just compute but RAM — which makes GPU-based attacks expensive. bcrypt and PBKDF2 don't have that property. For new implementations, there's no reason not to use Argon2id.

What "zero leak" actually means in practice

Beyond no network calls, I built a few extra guarantees:

Temp files go under NSTemporaryDirectory(), deleted immediately after processing — not dumped in /tmp and forgotten
Clipboard auto-clears 30 seconds after sensitive text is copied (in progress)
Log files record file paths and operation types only — never file contents

Current state (dev build)

Wrong password → GCM auth tag verification fails instantly → clear error message. The user always knows exactly what went wrong.

1000-page PDFs rendered without freezing — virtual scroll + Ghost Batch architecture.

Hiyoko PDF Vault → https://hiyokoko.gumroad.com/l/HiyokoPDFVault
X → @hiyoyok

Calling Apple Vision API from Tauri for Offline OCR [PDF Devlog #2]

hiyoyo — Fri, 17 Apr 2026 09:28:59 +0000

Devlog #2. Last time I covered the hybrid PDF engine setup (Rust + PDFKit + Swift). This time: getting Apple Vision API working from Tauri for fully offline OCR.

The goal

Extract text from scanned/image-based PDFs — completely offline, no cloud involved.

Apple's Vision Framework ships with every Mac, handles Japanese and English well, and costs nothing. The challenge: Tauri is Rust-based, and you can't call Swift APIs directly.

The bridge architecture

React (UI)
  ↓ invoke()
Tauri Command (Rust)
  ↓ std::process::Command
Swift CLI binary
  ↓
Apple Vision Framework (OCR)
  ↓ stdout (JSON)
Rust → back to React

Compile Swift as a standalone CLI binary, call it from Rust as a child process. Simple, effective.

Swift CLI (excerpt)

import Vision
import Foundation

func recognizeText(imagePath: String) -> String {
    guard let image = NSImage(contentsOfFile: imagePath),
          let cgImage = image.cgImage(forProposedRect: nil, context: nil, hints: nil)
    else { return "{\"error\": \"image load failed\"}" }

    var results: [String] = []
    let request = VNRecognizeTextRequest { req, _ in
        guard let observations = req.results as? [VNRecognizedTextObservation] else { return }
        results = observations.compactMap { $0.topCandidates(1).first?.string }
    }
    request.recognitionLevel = .accurate
    request.usesLanguageCorrection = true
    request.recognitionLanguages = ["ja-JP", "en-US"]

    let handler = VNImageRequestHandler(cgImage: cgImage)
    try? handler.perform([request])

    let json = try? JSONSerialization.data(withJSONObject: ["text": results.joined(separator: "\n")])
    return String(data: json ?? Data(), encoding: .utf8) ?? "{}"
}

let args = CommandLine.arguments
if args.count > 1 { print(recognizeText(imagePath: args[1])) }

Rust caller (excerpt)

use std::process::Command;

pub fn ocr_pdf_page(image_path: &str) -> Result {
    let output = Command::new("/path/to/vision-ocr-cli")
        .arg(image_path)
        .output()
        .map_err(|e| e.to_string())?;

    let stdout = String::from_utf8_lossy(&output.stdout);
    Ok(stdout.to_string())
}

Where I got stuck

1. Sandbox permissions

Tauri apps run sandboxed by default. External process execution needs an explicit allowlist in tauri.conf.json:

"allowlist": {
  "shell": { "execute": true }
}

2. Japanese OCR accuracy

Without setting recognitionLanguages, Vision defaults to English-first. Adding ["ja-JP", "en-US"] made a significant difference for Japanese documents.

Current state (dev build)

Load a scanned PDF, get selectable/copyable text out. Everything runs locally — no data leaves the machine.

Next devlog

AES-256 encryption and Zero Leak Architecture — how I designed a PDF tool that never touches the internet.

Hiyoko PDF Vault → https://hiyokoko.gumroad.com/l/HiyokoPDFVault
X → @hiyoyok

I'm Building My Own PDF Tool to Escape Adobe Tax — Here's How It's Going [Devlog #1]

hiyoyo — Thu, 16 Apr 2026 12:11:49 +0000

A few days ago I published a post about building a PDF tool in Rust because I got tired of paying for Adobe.

It got more attention than I expected, so I figured: why not document the actual build process as I go?

This is devlog #1.

Why Rust + Tauri + PDFKit? (The hybrid approach)

The first real problem when building a PDF app: which PDF engine do you use?

I went through a few options before landing on a "hybrid" architecture.

Pure lopdf (Rust)

My first instinct was to handle everything in Rust with lopdf. Clean, fast, no Apple dependencies.

Reality: macOS PDF rendering is surprisingly deep. lopdf is great for manipulation, but high-quality rendering alone is rough.

macOS PDFKit (Swift)

Apple's native PDF engine — excellent rendering quality, it's what Preview uses.

The catch: bridging it cleanly from Tauri's Rust backend takes work.

The solution: clear separation of concerns

PDFKit  → page rendering, redaction
lopdf   → Bates numbering, metadata manipulation  
Swift   → Apple Vision API (OCR), Core Image filters
Rust    → encryption, batch logic, all business logic

Each layer has one clear job. Much cleaner than trying to force one engine to do everything.

What I'm building right now

Currently working on the Sanctuary Automator — a workflow engine that chains operations like OCR → compress → save into a single click.

Still rough in the dev build, but the pipeline architecture is coming together.

Next devlog

Calling Apple Vision API from Tauri for offline OCR — bridging Swift into Rust/Tauri isn't well documented. I'll walk through how I got it working.

Hiyoko PDF Vault → https://hiyokoko.gumroad.com/l/HiyokoPDFVault
X → @hiyoyok

I launched on Product Hunt with 0 followers — honest results

hiyoyo — Thu, 16 Apr 2026 05:37:01 +0000

I launched on Product Hunt with 0 followers — honest results

Yesterday, I launched my macOS app "Hiyoko AutoSync" on Product Hunt.
The result: 4 upvotes. Small number on paper. But honestly? More reaction than I expected.

What I was actually afraid of
It wasn't nervousness exactly — it was the fear that nobody would even see it.
Zero followers on X. Maybe 1–2 on other platforms. On dev.to, I had no idea if anyone was reading at all. I launched with basically no social foundation whatsoever.

What actually happened
People saw it. For real.
Even with zero followers, getting listed on Product Hunt's feed means people can find you. The people who upvoted me had no connection to my social accounts — they were strangers who just came across it.
The feeling of "someone knows this exists now" hit harder than the number itself.

What I learned as an indie dev
・Launching with zero followers is still worth doing
・Even when you're scared, the move is to take action and get yourself out there
・The act of shipping itself becomes the foundation for what comes next

I'll keep launching
I have more apps I'm proud of under the Hiyoko brand. With this experience under my belt, I think I can do better next time.
Product Hunt isn't just for people with an audience — and I'm going to keep proving that.

If you're curious, the Product Hunt launch is still live for the next couple of hours — would love your support!

🐤Hiyoko AutoSync on Product Hunt
https://www.producthunt.com/products/hiyoko-autosync?utm_source=other&utm_medium=social

I Built a Mac App That Makes Android File Sync Feel Like Magic (No More MTP Hell)

hiyoyo — Wed, 15 Apr 2026 13:30:06 +0000

description: Hiyoko AutoSync uses ADB + Rust/Tauri to give you zero-touch, blazing-fast file sync between your Android and Mac. Here's why I built it and how it works under the hood.

If you've ever plugged your Android into a Mac and waited... and waited... for MTP to do literally anything — this post is for you.

I've spent way too many hours staring at a progress bar reading "Copying 1 of 847 files" while my Mac and phone had a slow, painful conversation through the world's worst protocol. So I built something to fix it.

The Problem with MTP

MTP (Media Transfer Protocol) is the default way Android and Mac communicate over USB. It works. Technically. But:

Speeds cap out around 3–5 MB/s in practice, even on USB 3
Connections are flaky and drop mid-transfer
You have to manually tap "File Transfer Mode" on your phone every. single. time.
There's zero automation — you have to babysit every sync

For me, the daily ritual looked like this:

Plug in phone → tap "File Transfer" on Android → open sync app on Mac → manually start sync → wait

Multiply that by every day, for years. I got fed up and built my way out.

The Solution: ADB Instead of MTP

ADB (Android Debug Bridge) ships with the Android SDK and is designed for development tooling. But it's also a dramatically superior file transfer protocol that almost no one uses for everyday sync.

With ADB you get rock-solid connections, full scriptability, and speeds up to 45 MB/s on USB 3.x — roughly 10x what MTP delivers in practice.

The one-time cost: enabling Developer Mode and USB Debugging on your Android. For anyone technical enough to care about fast, reliable sync, that's a 30-second setup you do once and forget.

What I Built: Hiyoko AutoSync

Hiyoko AutoSync is a macOS menu bar app that wraps ADB in a zero-touch experience. Here's the full flow after the one-time setup:

Plug in your Android via USB
HiyokoAutoSync detects the device and auto-switches USB mode to ADB
Sync starts instantly — zero taps on your phone
Next time, it connects over Wi-Fi. You may never need the cable again.

That's it. The entire manual ritual is gone.

Under the Hood

This is the part I actually want to talk about.

Tauri + Rust (not Electron)

The app is built with Tauri and Rust for the backend. I made this call specifically to avoid Electron bloat — a Mac menu bar app that eats 300MB of RAM to wrap a web UI is not a menu bar app, it's a punishment.

Tauri gives a native feel with a tiny binary footprint. Rust gives me the performance headroom to do things like...

4-Parallel ADB Engine (Tokio)

Standard ADB transfers one file at a time. Hiyoko AutoSync uses Tokio (Rust's async runtime) to run 4 parallel ADB streams simultaneously.

The result: moving gigabytes of 4K video or thousands of RAW photos takes seconds instead of minutes. Measured throughput hits 45 MB/s+ on USB 3.x connections.

Bundled ADB — Zero Setup

ADB is bundled inside the app. Users don't need to install Android SDK, add things to $PATH, or touch a terminal. It just works out of the box.

Wi-Fi Auto-Sync

Set up once over USB, and the app handles pairing your device to your local network. From then on, sync triggers automatically whenever your phone and Mac are on the same Wi-Fi — no cable required.

Safety Net: HiyokoTrash

Overwritten or deleted files during sync are moved to a HiyokoTrash folder on both your Mac and Android instead of being permanently deleted. You can always recover anything that got swept up in a sync.

Bonus Pro Tools

A few extra utilities I added because I needed them myself:

HEIC → JPG conversion on transfer
Storage analyzer for your Android device
Safe deletion with trash-based recovery

Feature Comparison

Requirements

macOS 12.0 Monterey or later — Universal Binary (Apple Silicon & Intel)
Android 5.0 or later — Developer Mode + USB Debugging enabled (one-time setup)

Why I'm Writing This Now

I shipped to Product Hunt and... completely forgot to write anything about it. Classic.

The app has been getting solid feedback from photographers, video creators, and developers who move large files regularly between their phone and Mac. Figured it was time to actually explain the technical decisions behind it.

Pricing

One-time purchase on Gumroad. Lifetime access to all future updates. No subscriptions.

If you're curious about the Tokio parallel streaming implementation or how the ADB device detection works, drop a comment — happy to go deeper on any of it.

🐤 Hiyoko AutoSync on Product Hunt ·
[Download on Gumroad]
https://hiyokoko.gumroad.com/l/hiyokoautosync_en
https://hiyokoko.gumroad.com/l/hiyokoautosync_jp

Stop Switching Tabs: I Built a Lightweight Rust/Tauri Menu Bar App to Summon Gemini for Instant Debugging🐤

hiyoyo — Wed, 15 Apr 2026 12:48:55 +0000

💻 The Struggle: Coding on a 10-Year-Old Mac
I’m still using a MacBook from 10 years ago. It’s a great machine and I love the keyboard, but modern browsers are memory hogs.

Whenever I hit a bug, I used to follow this tedious routine:
1.Open a new browser tab.
2.Wait for the heavy UI of AI tools to load.
3.Paste my error and wait for the response while my Mac's fans scream at max volume.

It felt like every time I tried to solve a problem, I was losing my "flow state." I needed something lighter, faster, and native.

🐤 Introducing: HIYOKOHELPER
To solve this, I built HIYOKOHELPER, a minimalist menu bar assistant powered by Rust and Tauri. It brings the power of Gemini AI directly to my desktop without the overhead of a web browser.

🐤 Why Rust and Tauri?
If you're using an old machine, every megabyte of RAM counts. I chose Tauri for a few reasons:

1.Tiny Footprint: Unlike Electron, which bundles a whole Chromium instance, Tauri uses the OS-native WebView.
2.Performance: Rust handles the background tasks with incredible speed and safety.
3.Startup Speed: It pops up instantly when I need it and hides away when I don't.

The result? A dev tool that runs smoothly even on hardware from a decade ago.

🛠 Key Features for Developers
I added three specific features to make my daily coding life easier:

Auto Monitor (Clipboard Error Detection) 📋
This is my favorite feature. When enabled, the app monitors my clipboard. If I copy an error message from my terminal or IDE, HIYOKOHELPER is already prepared to help. No more manual copying and pasting back and forth.
Bring Your Own API Key (Gemini Pro Support) 🔑
The app allows you to input your own Gemini API key. This means you can use Gemini 1.5 Pro or any other model Google offers in their developer tier. It’s private, cost-effective (often free for personal use), and fast.
Native & Always Ready ⚙️
With the "Auto Start" feature, the app is ready the moment I log in. It sits quietly in the menu bar, waiting for me to "summon" it.

🌟 Conclusion: Old Hardware, Modern AI
Working on an old machine doesn't mean you have to miss out on the latest AI breakthroughs. By choosing the right tech stack—Rust and Tauri—I was able to build a tool that makes my 10-year-old Mac feel like a modern powerhouse.

If you find yourself constantly distracted by browser tabs while debugging, I highly recommend building (or finding) a native desktop assistant. It’s a game-changer for your focus!

I launched my Mac app on Product Hunt today — zero-touch Android sync built with Rust🐤

hiyoyo — Wed, 15 Apr 2026 07:41:49 +0000

Hey devs! I just launched HiyokoAutoSync on Product Hunt today.

https://www.producthunt.com/products/hiyoko-autosync

It's a Mac app that makes Android sync completely invisible — plug in via USB once, it auto-switches to MTP mode via ADB, starts syncing, and pairs over Wi-Fi so you never need the cable again.

Built with:

Tauri + Rust (no Electron bloat)
Tokio async runtime, 4-parallel engine (45MB/s+)
Bundled ADB binary — works out of the box

Solo indie dev here. Would love any feedback if this sounds useful to you! 🐤