DEV Community: hiyoyo

MTP on Android Is a Minefield — What I Learned After Building My Own Mac Client

hiyoyo — Sat, 30 May 2026 07:15:06 +0000

I built HiyokoMTP because the existing tools kept failing me.

Android File Transfer has been effectively abandoned. OpenMTP is Electron-based — which means every USB operation runs through JavaScript, and its device recognition layer differs fundamentally from a native implementation. So I wrote my own MTP stack in Rust using nusb.

(All tests run on an 8-year-old MacBook Air — if it works there, it works anywhere.)

Why Existing Tools Fall Short

Android File Transfer: no longer actively maintained, frequently fails to recognize modern Android devices.
OpenMTP: every USB operation runs through the Electron runtime; its device recognition approach differs from native, leading to inconsistent behavior across manufacturers.

The 5 MTP Landmines

1. Manufacturer quirks

Pixel, Samsung, and Xiaomi all behave differently. Xiaomi defaults to "charging only" mode on connect; switching modes mid-session can silently terminate the MTP session.

2. The 4 GB wall

MTP uses 32-bit object size counters. Files over 4 GB require special handling, or transfers silently corrupt.

3. Special characters

Filenames containing \ / : * ? " < > | must be sanitized before transfer. No sanitization = silent error or crash.

4. Cable-pull at 90%

Unplugging during a transfer is the most common user mistake. Without clean disconnect detection, the app crashes or enters an undefined state.

5. USB hub instability

Hubs introduce instability. MTP is far more sensitive to this than mass storage protocols. Always test through a hub.

If you're building your own MTP client, plan for these edge cases — they're invisible until a real user hits them.

Building HiyokoMTP forced me to handle every one of these cases explicitly. All of the above is baked in. One-time purchase, no subscription.

→ https://hiyokomtp.lemonsqueezy.com/checkout/buy/2e966b64-554e-42a0-b865-4240281978a1

What's the weirdest USB/MTP behavior you've run into?

Tauri Sandbox Permissions — Why Your Command Silently Does Nothing

hiyoyo — Sat, 30 May 2026 03:29:40 +0000

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

The most common Tauri v2 frustration: you write a command, invoke it from the frontend, and nothing happens. No error. No crash. Just silence. It's almost always permissions.

How Tauri v2 permissions work

Tauri v2 introduced a capability system. Every plugin action — reading files, executing shell commands, sending notifications — requires an explicit permission declaration in your config. Without the permission, the plugin call fails silently on the frontend. The Rust code never runs.

// src-tauri/capabilities/main.json
{
  "identifier": "main-capability",
  "description": "Permissions for main window",
  "windows": ["main"],
  "permissions": [
    "core:default",
    "fs:read-all",
    "fs:write-all",
    "shell:allow-execute",
    "opener:allow-open",
    "global-shortcut:allow-register",
    "global-shortcut:allow-unregister"
  ]
}

Note: As of Tauri v2.1, shell:allow-open is deprecated. Use tauri-plugin-opener and opener:allow-open instead.

The debugging flow

When a command does nothing:

Open DevTools (Cmd+Option+I in dev mode) — check the console for a rejected Promise or permission error
Check your terminal output — the Rust side logs errors directly in the tauri dev terminal; look for lines like [tauri] permission denied or not allowed
Enable verbose logging — set RUST_LOG=tauri=debug before running tauri dev for more detailed backend output
Check your capabilities file — missing or misspelled permission identifiers are the #1 cause

Permission errors in the console typically look like a rejected Promise with a message such as plugin:shell|execute not allowed. The capabilities file is always the first thing to check.

Common permissions you'll need

"permissions": [
  "core:default",
  "fs:read-all",              // read any file
  "fs:write-all",             // write any file
  {
    "identifier": "shell:allow-execute",
    "allow": [{ "name": "my-cmd", "cmd": "adb", "args": true }]
  },
  "opener:allow-open",        // open URLs / files (replaces shell:allow-open)
  "path:allow-app-data-dir",  // access app data directory
  "notification:default",     // send notifications
  "global-shortcut:allow-register",
  "clipboard-manager:allow-read-text",
  "clipboard-manager:allow-write-text"
]

shell:allow-execute now requires an explicit allow scope — wildcards are blocked by default for security.

The scope system

For filesystem access, Tauri supports scoped permissions — allow access only to specific directories:

{
  "identifier": "fs:allow-app-data-read",
  "allow": [{ "path": "$APPDATA/**" }]
}

Use scoped permissions in production. fs:read-all is convenient for development, but shipping with it exposes more than needed.

The verdict

Tauri v2's permission system is correct. The sandboxing is good for security. The silent failure mode is painful until you know the pattern. When something stops working after a plugin update, always check whether the permission identifiers have changed — opener replacing shell:allow-open is a real example of this happening.

Check the capabilities file first. Always.

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

Hiyoko PDF Vault → https://hiyokomtp.lemonsqueezy.com/checkout/buy/a1b4d7d8-a4b8-433c-9d36-abdc0f3937c3

X → @hiyoyok

I Can Copy on My Phone and Paste on My Mac Instantly — Across 10 Devices at Once

hiyoyo — Fri, 29 May 2026 07:57:56 +0000

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

Copy something on your phone. Paste it on your Mac. No QR codes, no cloud accounts, no manual steps.

Now do that with 10 devices simultaneously.

That's what HiyokoClip does.

The Problem with Clipboard on Android

If you've ever tried to sync clipboard between Android and Mac, you already know the pain.

The usual options:

Cloud clipboard tools that require an account and internet
Browser extensions with privacy concerns
Manual copy-paste via messaging apps

None of these feel seamless. And Android 10+ makes it even harder — apps can no longer read the clipboard in the background by default.

How HiyokoClip Solves It

HiyokoClip runs entirely on your local network. No cloud. No accounts. No data leaving your devices.

The moment you copy something on your Android device, it appears on your Mac clipboard. Instantly.

And it works the other way too — copy on Mac, paste on any connected Android device.

N-to-N Sync: The Part That's Actually Fun

Most clipboard tools are 1-to-1. One phone, one Mac.

HiyokoClip supports N-to-N sync:

Copy on Phone A → paste on Phone B, Phone C, and Mac simultaneously
Copy on Mac → paste on all connected Android devices
Connect up to 10 devices at once

If you work with multiple test devices, or just have a tablet and a phone on your desk, this changes how you move information around.

Fully Local, Fully Private

Everything stays on your local network:

No internet connection required after setup
No account needed
No clipboard data sent to any server

For developers handling sensitive data — API keys, tokens, internal URLs — this matters.

Seamless Link Included

HiyokoClip also includes Seamless Link: plug in your Android via USB once, and it automatically switches to Wi-Fi. Pull the cable out and the sync keeps running wirelessly.

Try It

HiyokoClip for Mac

hiyokomtp.lemonsqueezy.com

If you're an Android developer or just tired of the clipboard gap between your devices, give it a shot. Let me know how it goes in the comments

Claude API Cheatsheet 2026 — Models, Pricing, Limits in One Place

hiyoyo — Thu, 28 May 2026 17:19:33 +0000

Claude API Cheatsheet 2026 — Models, Pricing, Limits in One Place

All information verified from Anthropic's official documentation as of May 2026.

Updated May 29, 2026: Claude Opus 4.8 released. Model ID, pricing, and tips updated.

Models

Model	ID	Context	Best For
Claude Opus 4.8	`claude-opus-4-8`	1M	Complex reasoning, hardest tasks
Claude Sonnet 4.6	`claude-sonnet-4-6`	1M	Most production workloads
Claude Haiku 4.5	`claude-haiku-4-5-20251001`	200K	Fast, simple tasks

💡 Opus 4.8 and Sonnet 4.6 both support 1M token context at flat rate — no surcharge.

API Pricing (per million tokens)

Model	Input	Output	Batch Input	Batch Output
Opus 4.8 (regular)	$5.00	$25.00	$2.50	$12.50
Opus 4.8 (fast mode)	$10.00	$50.00	—	—
Sonnet 4.6	$3.00	$15.00	$1.50	$7.50
Haiku 4.5	$1.00	$5.00	$0.50	$2.50

⚠️ Batch API = 50% discount, but processes within 24 hours (async only).

💡 Fast mode runs at 2.5× speed. Now 3× cheaper than fast mode was for previous Opus models.

¹ fast mode note: Opus 4.8 fast mode ($10/$50) is separately priced from the older Opus 4.6/4.7 fast mode ($30/$150). The fast mode docs now confirm speed: "fast" works with Opus 4.8, but explicit 4.8 pricing is not yet listed there. Prices above are from the official release announcement and Anthropic's pricing page.

Prompt Caching

Cache Type	Cost
Cache write (5 min TTL)	1.25x input rate
Cache write (1 hour TTL)	2x input rate
Cache hit	~0.1x input rate (up to 90% savings)

💡 Best for: system prompts, repeated context, long documents.

💡 Opus 4.8 lowers the minimum cacheable tokens from 4,096 to 1,024 — making caching practical for shorter system prompts too.

Subscription Plans (not API)

Plan	Monthly	Annual	Notes
Free	$0	$0	Sonnet 4.6, rolling 5hr limit
Pro	$20/mo	$17/mo	All models + Claude Code
Max 5x	$100/mo	—	5x Pro usage
Max 20x	$200/mo	—	20x Pro usage
Team Standard	$25/seat	$20/seat	Min 5 seats
Team Premium	$125/seat	$100/seat	Includes Claude Code & Cowork

⚠️ Subscriptions ≠ API access. API is always billed separately per token.

Basic API Call

import anthropic

client = anthropic.Anthropic(api_key="your_key")

message = client.messages.create(
    model="claude-opus-4-8",
    max_tokens=1024,
    messages=[
        {"role": "user", "content": "Hello!"}
    ]
)
print(message.content[0].text)

Batch API

import anthropic

client = anthropic.Anthropic()

batch = client.messages.batches.create(
    requests=[
        {
            "custom_id": "request-1",
            "params": {
                "model": "claude-sonnet-4-6",
                "max_tokens": 1024,
                "messages": [{"role": "user", "content": "Hello!"}]
            }
        }
    ]
)
print(batch.id)

Mid-task System Updates (NEW in Opus 4.8)

The Messages API now accepts system entries inside the messages array.
This lets you update Claude's instructions mid-task without breaking the prompt cache.

messages=[
    {"role": "user", "content": "Start the migration."},
    {"role": "assistant", "content": "Starting now..."},
    {"role": "system", "content": "Updated instruction: also update test files."},
    {"role": "user", "content": "Continue."},
]

💡 Useful for updating permissions, token budgets, or environment context while an agent is running.

Key Tips

Haiku → simple classification, summaries, high-volume tasks
Sonnet → most production use cases, best price/performance
Opus → complex reasoning, long-horizon agentic tasks (~1.7x more expensive than Sonnet, 5x more than Haiku)
Use Batch API for non-realtime workloads (50% cheaper)
Use prompt caching for repeated system prompts (up to 90% cheaper)
Opus 4.8 defaults to high effort. Use xhigh (Claude Code) or max for harder tasks — more tokens, better results. Rate limits in Claude Code have been increased to accommodate this.
Opus 4.8 fast mode runs at 2.5× speed at $10/$50 per million tokens — 3× cheaper than fast mode was on previous Opus models.
Opus 4.8 is ~4× less likely than Opus 4.7 to let code flaws pass unremarked (per Anthropic's evaluations).
Migrating from Opus 4.7? No new breaking changes have been officially announced for 4.8. Constraints introduced in 4.7 (non-default temperature/top_p/top_k returning 400, adaptive thinking replacing extended thinking) are expected to carry over. Tokenizer is assumed unchanged, but actual token cost may vary — verify with your own inputs.
Extended thinking: not supported on Opus 4.8 (confirmed in Anthropic's model overview). Use adaptive thinking instead.

Sources: Anthropic news — Introducing Claude Opus 4.8 · Claude API docs

If this was useful, a ❤️ helps more than you'd think.

Gumroad Cut Off My Payments Without a Word. Their Support Never Replied.

hiyoyo — Thu, 28 May 2026 02:16:32 +0000

7 Mac apps shipped as a solo developer. No sponsored opinion.

I sold Mac apps on Gumroad for over a year.

It worked. Simple setup, clean JP/EN storefront split, flat 10% fee. For a solo dev
shipping their first paid app, the simplicity matters more than the fee. I recommended
it. I built my entire payment infrastructure around it.

Then it fell apart in the most frustrating way possible.

The first sign: a UI I couldn't even use

I hadn't logged in for about a month. When I did, there was an error message telling
me to contact support — with a link I couldn't click. The UI itself was broken.

I want to be upfront about this: yes, I hadn't checked in for a month. But the problem
wasn't that I'd neglected something that needed maintenance. The problem was that
Gumroad's own interface for reporting a problem was broken. I couldn't even follow
their instructions.

So I went around it and contacted support directly.

The support loop

Gumroad's support starts with an AI bot. Fine. I answered its questions. It asked the
same questions again. I answered again. Same questions.

The bot wasn't moving toward a resolution. It was just looping.

I asked to be escalated to a human.

They agreed.

That was the last response I ever received.

For over a month, nothing. No follow-up. No resolution. No acknowledgment that my
storefront had an active error.

Then I opened Gumroad one day and payment was just... gone

No warning email. No violation notice. No explanation of any kind.

I just logged in one day and both Stripe and PayPal were no longer functional. My
Gumroad account still existed — I could log in, see my products, see my sales history.
But payment processing was dead. Stripe banned, PayPal frozen, simultaneously.

In practice, it didn't matter that my account was technically alive. No payment
processor means no sales. For a solo dev with no backup platform, it was effectively
a shutdown.

I still don't know why. No reason was ever given. My support ticket was still open
and unanswered when it happened.

Emergency migration to LemonSqueezy

I had apps listed. Customers trying to buy. Zero way to process payment. I had no
choice but to move immediately.

The migration meant:

Rewriting Cloudflare Worker license validation from scratch — the logic that verifies purchase keys on every app launch had to be rebuilt for LemonSqueezy's API. Several hours of work across multiple apps.
Rebuilding DMGs for every app — each binary needed updating to point to the new validation endpoint. With 7+ apps, this alone took the better part of a day.
Registering all products on LemonSqueezy and submitting W-8BEN tax paperwork.

Time I hadn't budgeted. Time I should have spent building.

LemonSqueezy works. The checkout is cleaner. Tax handling as merchant of record is
genuinely better. I should have diversified earlier.

What I actually learned

Two things, not one.

First: check your storefronts regularly. Platforms can break silently. A month of
not logging in was enough time for something to go wrong without me knowing. That's
on me, and it's a cheap lesson compared to what it could have been.

Second — and this is the bigger one — Gumroad didn't fail because it's a bad product.
It failed as a platform dependency. The lesson isn't "use LemonSqueezy instead." The
lesson is: never build your payment infrastructure around a single platform you don't
control.

Concretely:

Have a backup payment processor ready before you need it
If support goes silent for weeks, start migrating — don't wait for resolution
Platform risk is real, boring, and easy to ignore until it isn't

The ticket is probably still open.

If you're a solo dev selling digital products — how are you handling platform risk?
Have you ever had a payment processor disappear on you?

I Fed 100 Files to Claude and Gemini to Find Bugs — Here's Why It Failed

hiyoyo — Wed, 27 May 2026 10:49:23 +0000

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

I regularly feed 100+ files into LLMs as part of my development workflow. One day I thought: why not just dump everything in and let it find all the bugs?

Spoiler: it didn't work. Here's exactly what happened — and what actually does work.

The Setup

I tested both Claude Opus 4.7 and Gemini 3.5 Flash with thinking mode enabled on both. The task: find bugs across a multi-file Rust (Tauri v2) codebase. I suspect this happens regardless of language.

What Actually Happened

The models didn't crash or throw errors. They confidently returned answers. The problem was those answers were wrong — and if you don't know the codebase well enough, you'd never catch it.

This is the part nobody talks about: AI output is only as trustworthy as your ability to verify it. If you hand 100 files to an LLM and it says "no bugs found," how would you know it's lying?

Claude Opus 4.7:

Up to ~5 files: accuracy was excellent. Genuinely impressive.
10+ files: started getting shaky. Missing things it should catch.
15 files (confirmed with src-tauri): hallucinations increased significantly.

Gemini 3.5 Flash:

Single file up to ~300 lines: barely usable. Handles simple logic fine when the prompt is clear.
Multiple files: fell apart quickly. Results vary significantly depending on prompt quality.

Both models, even with thinking mode on, returned "no bugs found" on code that definitely had bugs.

Why This Happens: Lost in the Middle

This is a known phenomenon called "Lost in the Middle". LLMs don't read context linearly like humans do. Information in the middle of a large context window gets significantly less attention than content at the beginning or end.

So when you dump 15 files into the context, the model "sees" all of it technically — but effectively ignores large chunks in the middle.

Important distinction: thinking mode increases reasoning depth, but it doesn't fix the fundamental information retrieval problem. A wider context window ≠ the model can actually process all of it accurately.

The Fix: One File at a Time

The solution I landed on from experience: feed files one at a time.

# Instead of this:
"Here are 100 files, find all bugs"

# Do this:
"Here is file X. Find bugs in this file only."
→ repeat for each file
→ aggregate results manually via copy-paste

More tedious? Yes. More accurate? Dramatically.

For Opus specifically, staying under 5 files per request keeps the quality high. For Gemini, one file at a time with under 300 lines is the safe zone.

Practical Takeaways

Model	Sweet spot	Starts breaking down
Claude Opus 4.7	1–5 files	10+ files, confirmed at 15
Gemini 3.5 Flash	1 file, <300 lines (prompt quality matters)	Multiple files

Don't trust "no bugs found" on large inputs — the model may have simply stopped paying attention
Thinking mode helps with reasoning, not with reading everything accurately
Context window size is marketing. Effective context is much smaller in practice.
When in doubt, split the task smaller

Closing

Large context windows are impressive on paper. In practice, the effective range where you can trust the output is much smaller than advertised.

The fix isn't a better model — it's a better workflow. One file at a time, aggregated manually, beats dumping everything in and hoping for the best.

Progress updates on X: @hiyoyok

I Built a macOS ADB GUI Tool with Tauri v2 + Rust — Here's What I Actually Implemented

hiyoyo — Wed, 27 May 2026 08:45:38 +0000

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

After getting tired of googling ADB commands every time I needed one, I built HiyokoADB — a macOS GUI tool for Android developers. Here's a breakdown of what I actually shipped.

Stack

Rust + Tauri v2 + React — same stack I use across all my Hiyoko tools. Lightweight, fast, and runs fine on older hardware.

What I Built

1. Custom Command CRUD

The core feature. In the Custom tab, you can register any ADB command with a label, then run it with one click.

Storage: localStorage — commands persist across sessions without a database
Operations: Add via label + command input, delete via trash icon
Use case: Stop copy-pasting from Stack Overflow. Register once, run forever.

2. Preset Commands

A full set of commonly used ADB commands, organized by category:

Network: WiFi On/Off, Airplane Mode Toggle
Display: Keep Screen On, Screen Off, Animation Speed x0 (instant UI)
Input: Unlock Screen, Home Button, Back Button
System Debug: GPU Rendering ON/OFF, Check ADB State, Reset WM/Density
Settings (Direct): Developer Options, Accessibility, Battery Optimization, Notification Settings

The Settings category uses adb shell am start to open Android settings screens directly from your Mac — no need to dig through your phone.

3. Color-coded Result Log

Every command execution outputs to the Result Log at the bottom:

Yellow — Executing: adb ... (the command being run)
White/Gray — stdout (normal output)
Red — stderr (errors)

Reused and adapted from my HiyokoKit codebase, so this was mostly a copy-paste job.

4. Batch Mode (Multi-device)

Toggle "Batch Mode" in the sidebar and the same command fires to all connected devices simultaneously. Useful if you're testing across multiple Android devices.

5. Tools Tab — Advanced Input

Beyond simple button commands, the Tools tab handles precision input:

Swipe: Set start point, end point, and duration in milliseconds
Long Press: Coordinate + hold duration
Text Input: Send strings directly from your Mac keyboard to the device
Coordinate Converter: Convert scrcpy window coordinates to ADB tap coordinates automatically

6. System Utilities

Resolution + DPI change (with reset button)
GPU rendering toggle
ADB state check

What I Reused from HiyokoKit

Honest answer: a lot. The USB device detection, ADB command execution layer, and color log display were all adapted from my existing HiyokoKit codebase. The new work was:

Custom command CRUD with localStorage
Coordinate converter logic
Batch mode implementation
Sequence runner (register multiple commands, execute in order)

Building on existing code meant shipping faster. The whole thing came together in roughly one day.

Closing

HiyokoADB is still a work in progress, but the core is solid. If you're an Android developer on macOS who's tired of typing ADB commands, give it a look.

Progress updates on X: @hiyoyok

Built with Rust + Tauri v2 + React. macOS only.

Building a Card Game AI with Reinforcement Learning — Implementation Details#2

hiyoyo — Wed, 27 May 2026 08:06:54 +0000

Introduction

This is a follow-up to my previous article. If you haven't read it yet, check it out below.

👇 Part 1 here
(link to simple version)

In Part 1, I covered the basics of Google Colab. This time, I'll go deeper into the mechanics — specifically how I used reinforcement learning to train an AI to play a card game.

What Is Reinforcement Learning?

Reinforcement learning is a method where an AI learns by repeatedly trying things and adjusting based on the results.

Think of it like solving a maze:

Go the right way → reward
Hit a wall → penalty

Do this enough times and the AI gradually figures out the optimal path.

Applied to a card game:

Play a good move → reward
Lose the game → penalty

I ran this loop 200,000 times.

Representing the Game State as Numbers

To train an AI with reinforcement learning, every aspect of the game needs to be expressed as numbers. "Dimensions" here just means the number of data fields passed to the AI.

I ended up representing the game state with 20 dimensions:

State parameters: 10 dimensions
Numerical values representing the current game situation — things like HP and defense values
Card information: 10 dimensions
Numerical values representing the cards in hand and available options

I started with 17 dimensions and ran 100,000 training episodes, but the accuracy wasn't good enough. As I iterated, I realized certain game elements were missing from the representation. Adding those brought the total to 20 dimensions.

Deciding what to include in the state representation was both the hardest and most interesting part of the whole project.

Results After 200,000 Episodes

After upgrading to 20 dimensions and running 200,000 episodes, the AI reached stable, reasonable accuracy.

Situations where the 17-dimension / 100,000-episode model made poor decisions were handled correctly after the upgrade.

Honestly, reinforcement learning itself was easier than I expected. If you can clearly define the rules of the game in numerical form, the rest is just running the training loop.

That said, deep knowledge of the game is a prerequisite. I was able to design the state representation properly because I understood the game well enough to clear the hardest difficulty. Without that, the numbers wouldn't have captured what actually matters.

Closing

I covered the basics of reinforcement learning, how I represented a card game's state in 20 dimensions, and what 200,000 training episodes produced.

Reinforcement learning sounds intimidating, but if you understand the game you're modeling, it's surprisingly approachable. The hardest part isn't the ML — it's accurately translating the game into numbers.

If this gets a good response, I might write about the Rust implementation too — no promises though 😊

👇 Part 1 here

hiyoyo

May 21

My Old MacBook Air Couldn't Handle It — So I Used Google Colab to Train an AI＃1

#ai #python #googlecolab #rust

Comments

3 min read

I'm Building a GUI Tool for ADB Commands on macOS (Work in Progress)

hiyoyo — Wed, 27 May 2026 03:25:06 +0000

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

I got tired of googling ADB commands every single time.

adb shell dumpsys battery — what was the exact syntax again?
adb shell svc wifi disable — or was it enable?
adb shell am start -a android.settings.APPLICATION_DEVELOPMENT_SETTINGS — yeah, nobody memorizes that.

So I started building HiyokoADB — a macOS GUI tool that lets you run ADB commands without typing anything.

What it does (so far)

The app has three sections:

Dashboard — shows connected device info at a glance: battery level, Android version, IP address, model, serial number.

Presets — a collection of commonly used ADB commands organized by category (Network, Display, Input). One click to run.

Custom — save your own ADB commands with a label. No more copy-pasting from Stack Overflow.

Tech stack

Built with Rust + Tauri v2 + React.

Why Tauri v2 instead of Electron? The usual reasons — it's lightweight, fast, and works great on older hardware. My 8-year-old MacBook Air runs it without breaking a sweat.

The ADB execution layer is pure Rust, which makes command output parsing reliable and fast. Device discovery, shell commands, output capture — all handled in adb.rs on the backend.

Current preset commands

WiFi On / Off
Airplane Mode Toggle
Keep Screen On
Screen Off
Animation x0 (developer favorite)
Unlock Screen
Home Button / Back Button

More coming. The custom command feature means you can add whatever's missing for your workflow.

What's next

This is still a work in progress. Planned for upcoming versions:

Coordinate converter (scrcpy coords ↔ ADB coords ↔ Android real coords)
Android settings shortcuts (open Developer Options, Accessibility, Battery Optimization directly from your Mac)
Device profiles (name your devices, multi-device command broadcast)
Command sequences (chain multiple commands into one button)

Why I'm sharing this now

Honestly, I want feedback. If you use ADB regularly on macOS, what commands do you run most? What would you want in a tool like this?

Drop a comment — I'm actively building and would love to hear what's missing.

If you're interested in HiyokoADB, follow the progress on X: @hiyoyok

Built with Rust + Tauri v2 + React. macOS only.

Code Signing a Tauri App for macOS — The Complete Flow

hiyoyo — Wed, 27 May 2026 02:36:18 +0000

How to Sign and Notarize a Tauri Mac App for Distribution

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

Every Mac app I've shipped required this. Here's the exact flow I use.

An unsigned Mac app triggers a Gatekeeper warning that looks like malware. Users close it immediately. Code signing is not optional for a shipping product.

What you need

Apple Developer account ($99/year)
Developer ID Application certificate (for distribution outside App Store)
App-specific password for notarization

Tauri's built-in signing
Tauri v2 handles signing automatically if you configure it:

// tauri.conf.json
{
"bundle": {
"macOS": {
"signingIdentity": "Developer ID Application: Your Name (TEAMID)",
"providerShortName": "TEAMID"
}
}
}

Set environment variables for the build:

export APPLE_SIGNING_IDENTITY="Developer ID Application: Your Name (TEAMID)"
export APPLE_ID="your@email.com"
export APPLE_PASSWORD="your-app-specific-password"
export APPLE_TEAM_ID="YOURTEAMID"
npm run tauri build

Tauri signs the app and submits for notarization automatically.

Manual notarization when needed

Build without auto-notarize

npm run tauri build

Submit DMG manually

xcrun notarytool submit \
"target/release/bundle/dmg/YourApp.dmg" \
--apple-id "$APPLE_ID" \
--team-id "$APPLE_TEAM_ID" \
--password "$APPLE_PASSWORD" \
--wait

Staple the notarization ticket

xcrun stapler staple "target/release/bundle/dmg/YourApp.dmg"

--wait blocks until notarization completes (usually 1-5 minutes).

Verifying the result

Check signing

codesign -dv --verbose=4 YourApp.app

Check notarization

spctl -a -v YourApp.app

Should output: "accepted"

Check DMG

spctl -a -v YourApp.dmg

The entitlements file
Some capabilities require entitlements. For a Tauri app that runs shell commands:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "...">

com.apple.security.cs.allow-unsigned-executable-memory

com.apple.security.cs.disable-library-validation

Tauri configures entitlements via tauri.conf.json. Check the docs for your specific requirements. For my ADB-based apps, these two entitlements were the minimum needed to run shell commands without Gatekeeper blocking the process.

The $99/year question
Worth it if you're selling apps. Without it, users see a Gatekeeper warning. Many won't proceed. The developer account pays for itself with the first few sales.

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

Hiyoko Kit → https://hiyokomtp.lemonsqueezy.com/checkout/buy/2c94dd0f-e28a-4a17-8efc-7bd93087d46d

X → @hiyoyok

I Used Gemini 3.5 Flash via Direct API for a Week — An Honest Report on Its Speed Trade-offs and Real-World Pitfalls

hiyoyo — Tue, 26 May 2026 14:26:55 +0000

Introduction

After publishing a piece on debugging Rust code with Gemini 3.5 Flash, the response was bigger than I expected. So I spent the following week integrating it directly into my personal development workflow via the API and documenting the results.

The previous article was a controlled test. This one is about real-world usage. Bottom line: it can be a powerhouse depending on how you use it — but use it without thinking and you'll hit a wall fast.

What Worked Well

Simple tasks are accurate and blazing fast

For straightforward requests like "which files do I need to touch to remove the dock icon display for this app?", the speed is genuinely impressive. My gut feeling is it's at least 10x faster than 3.1 Pro.

Bulk edits are stable — if your instructions are solid

I threw cross-file edits totaling around 300 lines at it in a single prompt, and when the instructions were precise, it handled them cleanly. For developers who can write tight, complete instruction documents, this becomes a seriously fast tool.

Evaluations feel more grounded than 3.1 Pro

When I asked it to "evaluate this critically," the feedback felt more realistic than what I'd get from 3.1 Pro. This is specifically for non-code evaluation — ideas, writing, etc. For use cases where you want "tell me the real situation, not the ideal," there's a noticeable improvement.

What Was Genuinely Painful

Token consumption burns through your budget alarmingly fast

This was the biggest surprise. Even in casual exchanges, I'd watch nearly 10% of my available tokens disappear within 5 minutes. A significant portion of that is thinking tokens — the model reasoning internally while you wait. If you're planning any long sessions, you need to design your cost model carefully or you'll get hit with an unexpected bill.

Under server load, the "blazing fast" reputation disappears

Speed is one of the main selling points, but when the server is under heavy load, it's just... normal speed. Sometimes nearly identical to 3.1 Pro. "Blazing fast" is more accurately "blazing fast when the servers aren't busy."

Complex logic chains start to break down

Simple bug fixes and single-file edits are fine. But in real development, I noticed things going wrong when around five or more pieces of logic were interconnected.

When you have something like "A triggers B triggers C triggers D triggers E, and changing A affects E," it starts missing intermediate connections and making edits that ignore those dependencies. The previous benchmark (200 lines, 14 bugs, all correct) worked because the bugs were relatively independent. Real-world dependency chains are a different animal.

Round-trip costs pile up on complex problems

There was a bug I handed off to Gemini where we went through multiple cycles of investigation → fix → re-investigation, and I eventually spent more time reviewing its attempts than I would have spent just fixing it myself.

"Just hand it to AI and it'll be faster" only holds when the problem is simple. On complex problems, the round-trip overhead stacks up, and doing it yourself can be quicker.

Security-related code gets missed

I had Gemini work on a file that mixed front-end and back-end logic, and it moved forward with a fix while quietly missing a gap in security-related processing.

I only caught it because I later handed the code to Claude Opus, which flagged it immediately: "This code is missing its security processing." If I hadn't run that second check, I wouldn't have caught it.

Whether Gemini actively removed it or simply missed an existing gap is unclear, but I've since made it a habit to verify any security-related code with a separate model or by hand after Gemini edits it. For complex cases, doing it myself often ends up being faster anyway.

Long-context ingestion is mediocre — but that's not unique to Gemini

Feeding in large amounts of text at once degrades accuracy. This happens with Claude Opus too. Bulk long-context reading is an industry-wide problem, not a Gemini-specific one.

How to Get the Most Out of It

After a week of use, what became clear is that Gemini 3.5 Flash is a model that's very sensitive to how you use it.

Stick to well-scoped, simple tasks
If you can write a precise instruction document, bulk edits are fair game
For security-related code, verify with a separate model or by hand after any Gemini edit — and for complex cases, just fix it yourself
For complex problems, going straight to Opus or Sonnet is often faster overall

How I Split Work Between Claude and Gemini

Use Case	Better Model
Simple repetitive edits	Gemini 3.5 Flash
Bulk file edits (with a solid instruction doc)	Gemini 3.5 Flash
Security-related code	Claude, no question
Problems with complex interdependent logic	Claude Sonnet / Opus
Core architecture and foundation work	Claude Opus
Long-context bulk ingestion	Neither is great

Gemini's strengths are speed and volume. Claude's are complexity and precision. It's not about which is better — it's about matching the model to the task.

Conclusion

Gemini 3.5 Flash is a powerful tool for developers who use it deliberately. But if your approach is "just throw it at the AI and see what happens," expect to be let down.

Understand the token consumption rate and plan your costs accordingly
Invest in writing better instruction documents
Always verify security-related code with a separate model or by hand — complex cases are usually faster to fix yourself
For genuinely complex problems, consider reaching for a different model from the start

If you read this alongside my previous benchmark article, you'll get both sides: what it can do in controlled testing, and what it's actually like in daily development.

Appendix: Music Analysis via URL Doesn't Work

Unrelated to development, but I saw claims that "Gemini 3.5 improved significantly at music analysis," so I tested it by passing a YouTube link and asking it to analyze the track. It started describing a completely different song.

In hindsight, the model isn't actually listening to the audio at the URL, so this shouldn't be surprising — but there's a meaningful gap between the hype and the reality. For music, my own ears and knowledge are faster and more accurate.

I build Mac × Android utilities as a solo indie developer.
X → @hiyoyok

What I Learned Shipping 7 Mac Apps in 12 Months — The Honest Retrospective

hiyoyo — Tue, 26 May 2026 13:20:34 +0000

All tests run on an 8-year-old MacBook Air. All results from shipping 7 Mac apps as a solo developer. No sponsored opinion. Seven apps. Twelve months. One developer. Here's what I'd tell myself at app number one.

Ship earlier than you're comfortable with
The first version of every app I shipped was incomplete. That's correct. The users who buy version 1.0 are telling you what they actually need. No amount of building in isolation produces that signal. The features I was most proud of at launch often weren't the ones users cared about. The features users wanted most were often things I hadn't thought of. Ship, then iterate.

Free tools are more valuable than paid tools at the start
HiyokoLogcat is free and open source. It's driven more paid app sales than any other marketing I've done. A free tool that solves a real problem builds trust and audience. Users who trust your free tool buy your paid tools. The funnel works.

The platform matters less than the problem
I agonized over Gumroad vs App Store, Tauri vs Electron, Rust vs Swift. None of these decisions mattered as much as: does this solve a real problem for a real person who will pay for it? Pick a platform and build. Optimize the platform decision later.

AI makes solo development viable at a scale it wasn't before
I couldn't have shipped 7 apps this fast without AI assistance. Not because AI writes the code — it doesn't, not reliably. But because AI compresses the time between "I don't know how this works" and "I understand this well enough to build it." The bottleneck shifted from "can I figure this out" to "do I have time to build it." That's a better bottleneck. If you're a solo developer who's been hesitant about AI tooling — it's not about replacing your judgment. It's about spending less time being stuck and more time building.

The things that didn't matter

Perfect architecture on v1
Comprehensive test coverage before shipping
Having a large audience before launching
Waiting until I felt ready

None of these mattered. Shipping mattered. Everything else is refinement.

What actually moved the needle

Solving a problem I had myself
Writing about what I built
Making the free tool good enough that people shared it
Responding to every user question personally

Small things. Done consistently.

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

Hiyoko Kit → https://hiyokomtp.lemonsqueezy.com/checkout/buy/2c94dd0f-e28a-4a17-8efc-7bd93087d46d

X → @hiyoyok