DEV Community: hiyoyo

One Input Box, Two AI Modes — Detecting Whether the User Wants Error Help or Command Explanation

hiyoyo — Sun, 10 May 2026 16:15:18 +0000

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

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

HiyokoHelper has one input box but handles two completely different use cases:

Error diagnosis — "Why did this fail and how do I fix it?"
Command explanation — "What does this command actually do?"

The user doesn't select a mode. The app detects which one they need.

Detecting the mode

pub enum InputMode {
    ErrorDiagnosis,
    CommandExplain,
}

pub fn detect_mode(input: &str) -> InputMode {
    let trimmed = input.trim();
    let lines: Vec<&str> = trimmed.lines().collect();

    if lines.len() == 1 {
        let line = lines[0];
        let command_prefixes = [
            "sudo ", "git ", "npm ", "yarn ", "cargo ",
            "brew ", "pip ", "docker ", "kubectl ",
            "ls ", "cd ", "mv ", "cp ", "chmod ",
            "systemctl ", "launchctl ",
        ];
        let looks_like_command = command_prefixes.iter()
            .any(|p| line.starts_with(p))
            || line.starts_with("$ ")
            || line.starts_with("% ");

        if looks_like_command {
            return InputMode::CommandExplain;
        }
    }
    InputMode::ErrorDiagnosis
}

Different prompts for each mode

pub fn build_prompt(input: &str, mode: &InputMode, lang: &Lang) -> String {
    match (mode, lang) {
        (InputMode::ErrorDiagnosis, Lang::Japanese) => format!(
            "あなたはターミナルエラーの専門家です。\
             以下のエラーの原因を1〜2文で説明し、\
             解決コマンドがあれば示してください。\n\n{}", input
        ),
        (InputMode::CommandExplain, Lang::Japanese) => format!(
            "あなたはターミナルコマンドの先生です。\
             以下のコマンドが何をするか初心者向けに説明し、\
             危険な副作用があれば警告してください。\n\n{}", input
        ),
        (InputMode::ErrorDiagnosis, Lang::English) => format!(
            "You are a terminal error specialist. \
             Explain the cause in 1-2 sentences and provide a fix.\n\n{}", input
        ),
        (InputMode::CommandExplain, Lang::English) => format!(
            "You are a terminal command teacher. \
             Explain what this command does for a beginner. \
             Warn about dangerous side effects.\n\n{}", input
        ),
    }
}

Live mode indicator in UI

const mode = detectMode(inputText);


  {mode === 'error' ? '🔍 エラー診断モード' : '📖 コマンド解説モード'}

Updates live as they type. No confusion about what will happen on submit.

HiyokoHelper (OSS) → github.com/hiyoyok/HiyokoHelper
X → @hiyoyok

AI Overlay UI in Tauri — Designing the "Ask AI" Button That Doesn't Annoy Users

hiyoyo — Thu, 07 May 2026 16:07:38 +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.
Every app has an AI button now. Most of them are annoying. Here's how I approach AI UI in my Tauri apps.

The problem with most AI UI
The bad pattern: a prominent "Ask AI" button that's always visible, always tempting users to click it, and produces results that take 3 seconds to load with a full-screen loading state.
The result: users click once, wait, get a mediocre response, and never click again. The button becomes visual noise.

What works: contextual, fast, optional
Contextual: the AI button appears near the content it analyzes, not in a toolbar. In HiyokoLogcat, the "Diagnose" button appears next to each log entry. In HiyokoHelper, the analyze button appears next to the clipboard content. The button makes sense where it lives.
Fast feedback: show something immediately. Even if the full response takes 2 seconds, stream the first tokens within 200ms. The user sees progress. Waiting feels shorter when something is happening.
Optional: AI features are enhancements. The app is fully usable without clicking the AI button. Users who want it will find it. Users who don't won't be forced through it.

The loading state that works
Don't show a spinner for 2 seconds then replace everything with text. Stream the response:
typescriptconst [response, setResponse] = useState('')
const [isStreaming, setIsStreaming] = useState(false)

// As chunks arrive from Gemini streaming
listen('ai-chunk', (event) => {
setResponse(prev => prev + event.payload)
})
Text appearing character by character feels fast even when it isn't.

The error state that doesn't panic users
When Gemini returns a 429 or 503, don't show a technical error. Show:

"Analysis unavailable right now. Try again in a moment."

One sentence. No stack trace. No HTTP status code. The user doesn't care why it failed — they care what to do next.

The API key UX
Apps that require an API key have an onboarding problem. Users don't want to get an API key before trying your app.
Solution: make the AI features clearly optional, show them working in screenshots/demos, and make the API key setup flow short. Three steps maximum: get key → paste key → done.

The verdict
AI UI that respects the user's attention works. Streaming responses, contextual buttons, graceful degradation on errors. The "AI" label doesn't make a feature valuable — solving a real problem does.

If this was useful, a ❤️ helps more than you'd think — thanks!
Hiyoko PDF Vault → https://hiyokoko.gumroad.com/l/HiyokoPDFVault
X → @hiyoyok

"You Got This Error Last Week" — Building an AI That Remembers Your Past Errors

hiyoyo — Thu, 07 May 2026 14:52:21 +0000

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

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

The same error appears twice. Most AI tools diagnose it twice — two API calls, same answer.

HiyokoHelper remembers. When the same error appears again, it responds instantly from cache: "💡 先日も同じケースが発生し、〇〇で解決しました"

Here's how the history cache works.

The data structure

#[derive(Serialize, Deserialize, Clone)]
pub struct HistoryEntry {
    pub error_hash: String,
    pub error_preview: String,
    pub diagnosis: String,
    pub resolved: bool,
    pub created_at: u64,
    pub hit_count: u32,
}

Stored in history.json via tauri-plugin-store. Local only, never leaves the machine.

Normalizing before hashing

Same error, different timestamps → same hash:

pub fn normalize_error(text: &str) -> String {
    let mut result = text.to_string();

    let timestamp_re = Regex::new(r"\d{4}-\d{2}-\d{2}[T ]\d{2}:\d{2}:\d{2}").unwrap();
    result = timestamp_re.replace_all(&result, "[TIMESTAMP]").to_string();

    let line_re = Regex::new(r"line \d+").unwrap();
    result = line_re.replace_all(&result, "line [N]").to_string();

    let pid_re = Regex::new(r"\bpid[: ]\d+").unwrap();
    result = pid_re.replace_all(&result, "pid [PID]").to_string();

    result.split_whitespace().collect::>().join(" ")
}

The lookup flow

pub async fn diagnose_with_history(
    input: &str,
    api_key: &str,
    history: &mut HistoryCache,
) -> DiagnosisResult {
    let hash = error_hash(input);

    if let Some(entry) = history.get(&hash) {
        entry.hit_count += 1;
        let msg = if entry.resolved {
            format!("💡 先日も同じエラーが発生し、解決済みです。\n\n{}", entry.diagnosis)
        } else {
            format!("⚠️ このエラーは以前も発生しています（{}回目）。\n\n{}", entry.hit_count, entry.diagnosis)
        };
        return DiagnosisResult::FromHistory { diagnosis: entry.diagnosis.clone(), message: msg };
    }

    let diagnosis = call_gemini(input, api_key).await?;
    history.insert(hash, HistoryEntry {
        error_hash: hash.clone(),
        error_preview: input.chars().take(100).collect(),
        diagnosis: diagnosis.clone(),
        resolved: false,
        created_at: unix_now(),
        hit_count: 1,
    });

    DiagnosisResult::Fresh { diagnosis }
}

The "resolved" button

pub fn mark_resolved(history: &mut HistoryCache, hash: &str) {
    if let Some(entry) = history.get_mut(hash) {
        entry.resolved = true;
    }
    history.save();
}

Next time: "You had this issue and resolved it. Here's what worked."

Cache eviction

Unresolved entries older than 30 days evicted. Resolved entries kept forever.

pub fn evict_old_entries(history: &mut HistoryCache) {
    let cutoff = unix_now() - (30 * 24 * 60 * 60);
    history.entries.retain(|_, entry| {
        entry.created_at > cutoff || entry.resolved
    });
}

HiyokoHelper (OSS) → github.com/hiyoyok/HiyokoHelper
X → @hiyoyok

Detecting Dangerous Terminal Commands Before Sending Them to an AI — My Safety Layer

hiyoyo — Thu, 07 May 2026 01:14:37 +0000

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

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

HiyokoHelper sends terminal errors to Gemini for diagnosis. But what if the user pastes rm -rf / or a fork bomb?

Two problems: wasting API quota on non-errors, and potentially getting an "explanation" of a command that could destroy the system.

Here's the safety layer I built.

Layer 1: Is it actually dangerous?

#[derive(Debug, PartialEq)]
pub enum SafetyLevel {
    Safe,
    Warning(String),
    Danger(String),
}

pub fn assess_safety(input: &str) -> SafetyLevel {
    let input_lower = input.to_lowercase();

    let critical = [
        ("rm -rf /", "This deletes your entire filesystem."),
        ("rm -rf ~", "This deletes your home directory."),
        ("rm -rf *", "This deletes everything in the current directory."),
        ("mkfs", "This formats a disk, erasing all data."),
        ("dd if=/dev/zero", "This overwrites a disk with zeros."),
        (":(){:|:&};:", "This is a fork bomb — it will crash your system."),
        ("chmod -R 777 /", "This removes all security from your filesystem."),
    ];

    for (pattern, reason) in &critical {
        if input_lower.contains(pattern) {
            return SafetyLevel::Danger(reason.to_string());
        }
    }

    let warnings = [
        ("sudo rm", "This runs a deletion command as administrator."),
        ("sudo chmod", "This changes file permissions as administrator."),
        ("kill -9", "This forcefully terminates a process."),
        ("pkill", "This kills processes by name."),
    ];

    for (pattern, reason) in &warnings {
        if input_lower.contains(pattern) {
            return SafetyLevel::Warning(reason.to_string());
        }
    }

    SafetyLevel::Safe
}

Layer 2: Different UI for each level

Danger → block entirely. Warning → user decides. Safe → proceed silently.

function SafetyBanner({ level }: { level: SafetyResult }) {
  if (level.type === 'danger') {
    return (


        ⚠️ 危険なコマンドが含まれています

{level.reason}



AIへの送信をブロックしました。




    );
  }
  if (level.type === 'warning') {
    return (


        🔶 注意: {level.reason}
        表示する


    );
  }
  return null;
}

Layer 3: sudo gets automatic explanation

pub fn detect_mode(input: &str) -> DiagnosisMode {
    let trimmed = input.trim();
    if trimmed.starts_with("sudo ") && !trimmed.contains('\n') {
        return DiagnosisMode::CommandExplain;
    }
    if looks_like_error(input) {
        return DiagnosisMode::ErrorDiagnosis;
    }
    DiagnosisMode::CommandExplain
}

sudo systemctl restart nginx → explains what it does, warns about administrator privileges.

HiyokoHelper (OSS) → github.com/hiyoyok/HiyokoHelper
X → @hiyoyok

Offline-First Architecture in a Tauri App — What It Actually Means

hiyoyo — Wed, 06 May 2026 17:09:11 +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.
"Offline-first" gets thrown around a lot. For a Tauri desktop app, it has a specific meaning — and it's not complicated.
Here's what I mean when I say my apps are offline-first, and how I built it.

What offline-first means for a desktop app
A desktop app is already local by default. The question is what happens when it needs external resources — AI APIs, sync endpoints, update servers.
Offline-first means: the app is fully functional without any network connection. Network access enhances the experience; it doesn't enable it.
For my apps:

HiyokoAutoSync: syncs files when ADB device is connected. No internet required.
PDF Vault: all PDF operations run locally. Gemini OCR is optional enhancement.
HiyokoHelper: all history, caching, and UI runs locally. AI analysis requires network.

The distinction: required vs optional network.

The practical implementation
Local-first data. Everything goes to SQLite first. Network sync (if any) happens after.
rustasync fn process_action(input: Input) -> Result {
// Write to local DB immediately
db.save(&input).await?;

// Try network enhancement — fail gracefully
match enhance_with_api(&input).await {
    Ok(enhanced) => Ok(enhanced),
    Err(_) => Ok(Output::from_local(&input)), // degrade gracefully
}

}
Graceful degradation for AI features. If Gemini is unavailable, show the raw data. Don't block the UI waiting for a network response.
No blocking network calls on the hot path. The user's primary workflow should never wait for the network. Background sync, optional enrichment — yes. Mandatory network call before the user can do anything — no.

Why it matters for desktop apps
Desktop apps get used in planes, conferences, basements, rural areas. Users expect desktop software to work without internet. Web app expectations don't apply.
More practically: a flaky network call that hangs the UI is the fastest way to get a bad review.

The one exception
Update checks and license validation. These require network by definition. Handle them gracefully: check in the background, don't block launch, degrade to last-known state on network failure.

If this was useful, a ❤️ helps more than you'd think — thanks!
Hiyoko PDF Vault → https://hiyokoko.gumroad.com/l/HiyokoPDFVault
X → @hiyoyok

How I Price My Indie Mac Apps — The Thinking Behind $7, $39, and $50

hiyoyo — Wed, 06 May 2026 15:33:11 +0000

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

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

I have apps priced at $7, $20, $29, $39, and $50. Each price reflects a different decision. Here's the thinking.

The framework I use

Two questions:

Who is the buyer? Consumer (buying for personal use, price-sensitive) vs. professional (buying for work, outcome-focused).

What pain does it solve? Occasional convenience vs. recurring time savings vs. risk reduction.

$7 — HiyokoShot (screenshot transfer)

Consumer buyer. Occasional use. Solves a mild inconvenience (getting screenshots from Android to Mac).

At $7, the decision is instant. No comparison shopping, no deliberation. The friction of evaluation costs more than the price.

Rule: If the buyer will use the app once a week or less, keep it under $10.

$39 — HiyokoBar (menubar tool)

Mixed buyer — some consumers, some professionals. Daily use. Saves 5-10 minutes per day for people who use it seriously.

At $39, it's in "considered purchase" territory — buyers spend 2-3 minutes evaluating. The sales page needs to be clear about the value proposition.

Rule: Daily-use tools for a mixed audience price between $20-50.

$50 — HiyokoAutoSync (zero-touch Android sync)

Professional buyer. Solves a real workflow problem (automatic sync without thinking). Time savings compound daily.

At $50, buyers are outcome-focused. They're not asking "is $50 a lot?" — they're asking "does this solve my problem?" The price signals quality and commitment.

Rule: If the app replaces a workflow that currently takes manual effort daily, $50+ is defensible.

What I got wrong

Starting too low. My first app launched at $9. After 50 sales I raised it to $19. Conversion rate barely changed. The $9 price was anchoring expectations low without driving meaningfully more sales.

Underestimating professional buyers. I assumed everyone was price-sensitive. Some buyers emailed asking if there was a "pro" tier. There wasn't. Left money on the table.

Practical notes

Odd prices ($39 not $40, $7 not $8) perform slightly better — no strong evidence why, but it's consistent in my data
Offering a permanent license (not subscription) is a strong selling point for Mac utility apps — buyers are tired of subscriptions
"One-time purchase" in the product title or description noticeably improves conversion for this audience

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

What I Learned Building HiyokoBar — A Menubar App That Does One Thing Per Click

hiyoyo — Wed, 06 May 2026 14:30:05 +0000

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

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

HiyokoBar is a menubar app. Click the icon — panel appears. Do the thing. Click away — panel disappears.

It sounds trivial. It took longer than expected to get right. Here's what I learned.

The constraint that shaped everything

A menubar panel has maybe 400px of vertical space. That's it.

This constraint forced decisions I wouldn't have made otherwise:

Every feature had to earn its place. No "maybe someone will want this" features.
Each action had to complete in one click or one step. Two-step actions don't belong in a menubar panel.
Visual hierarchy matters more than in a full window — users scan, not read.

Constraints produce clarity. The limited space was the best design tool I had.

The technical decisions

Activation policy: accessory — no Dock icon, no Cmd+Tab entry.

Panel positioning: calculate from tray icon position on every click — the user might have moved it.

Focus behavior: hide on blur, but suppress blur-hiding during native dialogs. Took 3 iterations to get right.

Launch at login: LaunchAgent plist, not SMAppService — better compatibility with older macOS versions.

What users actually use

I added analytics (opt-in, local only) to see which features got tapped.

The top 3 features account for 80% of all interactions. The bottom 5 features combined account for under 5%.

I removed two features entirely after seeing the data. The app got better immediately — less to scan, less to understand, faster to use.

The lesson: ship with more features than you think users need. Then watch what they actually use. Then remove everything else.

The Product Hunt launch

HiyokoBar launched on Product Hunt on April 20, 2026.

Traffic spike: yes. Sustained sales from it: modest. The real value was the comments and feedback — several feature ideas came directly from PH discussions that I'd never have thought of.

My view on PH: worth doing once per app for the feedback loop, not for the traffic.

The one thing that surprised me

The users who emailed me feedback. Not bug reports — genuine "here's what this does for my workflow" messages.

Menubar apps attract a specific kind of user: people who care about their tools, who customize their environment, who notice when something is done right. These are the best users to have.

Build for them.

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

Bates Numbering in Rust — Automating Legal Document Stamping

hiyoyo — Wed, 06 May 2026 13:20:00 +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.
Bates numbering is sequential page stamping used in legal documents. Every page gets a unique identifier: CASE-001, CASE-002, etc.
I built this into Hiyoko PDF Vault. Here's how it works in Rust.

What Bates numbering actually is
A Bates stamp is a text label added to a fixed position on each page — usually bottom-right or bottom-left. The label increments sequentially across a document set.
Format: [PREFIX][NUMBER][SUFFIX] where number is zero-padded to a fixed width.
Examples: SMITH-000001, EXHIBIT_A_0042, DOC00100

The implementation with lopdf
rustuse lopdf::{Document, Object, Stream, Dictionary, content::Content};

pub struct BatesConfig {
pub prefix: String,
pub suffix: String,
pub start_number: u64,
pub pad_width: usize,
pub position: BatesPosition,
pub font_size: f32,
}

pub enum BatesPosition {
BottomRight,
BottomLeft,
TopRight,
TopLeft,
}

pub fn apply_bates(doc: &mut Document, config: &BatesConfig) -> Result<(), AppError> {
let page_ids: Vec<_> = doc.page_iter().collect();

for (i, page_id) in page_ids.iter().enumerate() {
    let number = config.start_number + i as u64;
    let label = format!(
        "{}{}{}",
        config.prefix,
        format!("{:0>width$}", number, width = config.pad_width),
        config.suffix
    );

    stamp_page(doc, *page_id, &label, &config)?;
}

Ok(())

}

Stamping a page
Adding text to a PDF page requires appending to its content stream:
rustfn stamp_page(
doc: &mut Document,
page_id: (u32, u16),
label: &str,
config: &BatesConfig,
) -> Result<(), AppError> {
let (x, y) = calculate_position(doc, page_id, &config.position)?;

let stamp_content = format!(
    "BT /F1 {} Tf {} {} Td ({}) Tj ET",
    config.font_size, x, y, label
);

// Append to existing page content
// Ensure font is available in page resources
append_content_to_page(doc, page_id, &stamp_content)?;

Ok(())

}

The font dependency
PDF text rendering requires a font reference in the page's resource dictionary. If the page doesn't already have a suitable font, you need to embed one or reference a standard PDF font (Helvetica, Times, Courier — guaranteed to be available in any PDF viewer).
For Bates stamps, Helvetica works fine and requires no font embedding.

Batch processing
The real use case is stamping hundreds of pages across multiple documents. Process sequentially with progress events back to the frontend. Don't try to parallelize PDF mutation — document state is not thread-safe with lopdf's mutable references.

If this was useful, a ❤️ helps more than you'd think — thanks!
Hiyoko PDF Vault → https://hiyokoko.gumroad.com/l/HiyokoPDFVault
X → @hiyoyok

PDF Redaction in Rust — Why "Delete the Text" Isn't Enough

hiyoyo — Wed, 06 May 2026 02:18:52 +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.
Real PDF redaction is harder than it looks. The naive approach — draw a black rectangle over text — doesn't actually remove the text from the file.
Here's what proper redaction requires.

The problem with naive redaction
A PDF with a black rectangle drawn over sensitive text still contains that text in the file structure. Anyone with a PDF editor can remove the rectangle and read the original content.
This has caused real security incidents. Legal documents, medical records, government reports — all leaked because someone drew a box over text and called it redacted.

What actual redaction requires

Identify the content to redact (text, images, or regions)
Remove the actual content from the PDF's content streams
Replace with a filled rectangle
Remove any references in the document structure
Rebuild the PDF without the redacted content in the object stream

Step 2 is where naive implementations fail. Removing visible rendering is not the same as removing the data.

The lopdf approach
With lopdf, you're working directly with PDF objects. Redaction means modifying content streams:
rustfn redact_text_in_stream(content: &[u8], target: &str) -> Vec {
// Parse PDF content stream operations
// Find text rendering operations containing target
// Replace text content with spaces or remove operations
// Rebuild content stream

// This is genuinely complex — PDF content streams
// interleave text positioning and rendering commands
todo!("non-trivial implementation")

}
PDF content streams aren't plain text. They're a sequence of operators and operands. Text appears across multiple operators: font selection, positioning, encoding, rendering. A complete redaction implementation needs to parse all of these.

What I ship in PDF Vault
Hiyoko PDF Vault implements region-based redaction: the user selects a region, we remove all content operations that render within that region, then fill with a solid rectangle.
It's not forensic-grade redaction. It removes content from the file structure rather than just drawing over it. For the use case — personal documents, not classified government files — it's appropriate.
For truly sensitive documents requiring certified redaction, professional tools with documented audit trails are the right choice. I'm honest about this in the app description.

The verdict
True PDF redaction is a solved problem in professional tools. In a Rust implementation, it's achievable but requires careful PDF content stream parsing. The naive approach (draw a rectangle) should never be called redaction.
Know what level of redaction your users actually need before deciding how to implement it.

If this was useful, a ❤️ helps more than you'd think — thanks!
Hiyoko PDF Vault → https://hiyokoko.gumroad.com/l/HiyokoPDFVault
X → @hiyoyok

Selling Mac Apps on Gumroad — What Works, What Doesn't, Honest Numbers

hiyoyo — Wed, 06 May 2026 01:09:39 +0000

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

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

I sell Mac apps on Gumroad. Not the App Store — Gumroad, direct to buyers.

Here's the honest account: what the platform is like, what drives sales, and what I'd do differently.

Why Gumroad over the App Store

No code signing requirement. Apple Developer Program costs $99/year. Before you've made $99, that's a high bar. Gumroad accepts unsigned apps.

No 30% cut. Gumroad takes 10% (or less with volume). Apple takes 30%. On a $30 app, that's $3 vs $9 per sale.

No review process. Ship when it's ready. Update when you want. No waiting.

The tradeoff: users see a "cannot verify developer" dialog on first launch. Right-click → Open bypasses it. Some users won't do this. It costs conversions — I'd estimate 15-20% drop-off at that step.

What actually drives sales

Technical articles. Every spike in sales correlates with a published article. Not product announcements — articles about how I built something. "Adobe税を払うのをやめた" (I stopped paying the Adobe tax) outperformed every product post I've written.

Specific problem, specific solution. "PDF tool" is too broad. "Remove metadata from PDFs before sharing" is a specific problem someone is actively searching for. The more specific the problem the app solves, the easier the sales page writes itself.

Price anchoring. Listing a Japanese version and English version separately at slightly different prices helps. The existence of two options makes choosing feel like a decision rather than a yes/no on buying.

What doesn't drive sales

Product Hunt launches. One-day spike, then nothing. Useful for social proof and backlinks, not for sustained revenue.

Generic social media posting. "Check out my new app!" gets ignored. Technical content with a mention of the app at the end works better.

The numbers (directionally)

Articles that perform well drive 5-15 sales in the following week. Product announcements drive 0-3. The difference in effort between writing a good technical article and a product announcement is small. The difference in result is large.

Practical Gumroad tips

Offer both a Japanese and English listing for Japan-market apps — different buyers find different listings
Include a clear "how to open on first launch" note in the product description (for the security dialog)
Respond to every support email — Gumroad shows buyer reviews and support responsiveness matters
Use the "pay what you want" minimum for free tools to collect emails

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

Rust Async Patterns in Tauri — Keeping the UI Responsive While Rust Does Heavy Work

hiyoyo — Tue, 05 May 2026 16:35:14 +0000

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

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

A Tauri app has two threads that matter: the main thread (UI) and whatever tokio spawns. Block the main thread and the UI freezes. Block for too long in a command and the frontend times out.

Here's how I keep things responsive in practice.

The basic rule

Never do blocking work in a #[tauri::command] without async.

// Bad — blocks the thread pool
#[tauri::command]
pub fn compress_pdf(path: String) -> Result<(), String> {
    heavy_compression_work(&path)?;  // takes 3 seconds, blocks
    Ok(())
}

// Good — async, non-blocking
#[tauri::command]
pub async fn compress_pdf(path: String) -> Result<(), String> {
    tokio::task::spawn_blocking(move || {
        heavy_compression_work(&path)
    })
    .await
    .map_err(|e| e.to_string())?
    .map_err(|e| e.to_string())
}

spawn_blocking moves CPU-heavy work to a dedicated thread pool, freeing the async executor for other tasks.

Progress reporting during long operations

For operations that take more than a second, report progress via events:

#[tauri::command]
pub async fn batch_process(
    paths: Vec,
    window: tauri::Window,
) -> Result<(), String> {
    let total = paths.len();

    for (i, path) in paths.iter().enumerate() {
        process_single(&path).await?;

        window.emit("batch-progress", serde_json::json!({
            "current": i + 1,
            "total": total,
            "percent": ((i + 1) as f64 / total as f64 * 100.0) as u32,
        })).ok();
    }

    Ok(())
}

// Frontend shows live progress
await listen('batch-progress', (event) => {
  setProgress(event.payload.percent);
});

await invoke('batch_process', { paths });

Cancellation

Users cancel long operations. Support it with a shared flag:

use std::sync::{Arc, atomic::{AtomicBool, Ordering}};

pub struct CancelToken(Arc);

impl CancelToken {
    pub fn new() -> Self { Self(Arc::new(AtomicBool::new(false))) }
    pub fn cancel(&self) { self.0.store(true, Ordering::Relaxed); }
    pub fn is_cancelled(&self) -> bool { self.0.load(Ordering::Relaxed) }
}

#[tauri::command]
pub async fn batch_process(
    paths: Vec,
    cancel_token: tauri::State<'_, CancelToken>,
    window: tauri::Window,
) -> Result<(), String> {
    for (i, path) in paths.iter().enumerate() {
        if cancel_token.is_cancelled() {
            return Err("cancelled".to_string());
        }
        process_single(&path).await?;
        window.emit("batch-progress", i + 1).ok();
    }
    Ok(())
}

// Cancel button
await invoke('cancel_batch');

Parallel processing with Semaphore

Process multiple files concurrently, but not all at once:

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

pub async fn process_parallel(paths: Vec) -> Vec> {
    let semaphore = Arc::new(Semaphore::new(4)); // max 4 concurrent
    let mut handles = Vec::new();

    for path in paths {
        let sem = semaphore.clone();
        let handle = tokio::spawn(async move {
            let _permit = sem.acquire().await.unwrap();
            process_single(&path).await.map_err(|e| e.to_string())
        });
        handles.push(handle);
    }

    futures::future::join_all(handles)
        .await
        .into_iter()
        .map(|r| r.unwrap_or_else(|e| Err(e.to_string())))
        .collect()
}

4 concurrent transfers on a 2017 MacBook Air runs well without saturating the disk or CPU.

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

Rust Error Handling Patterns I Actually Use in Production

hiyoyo — Tue, 05 May 2026 14:45:20 +0000

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

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

Every Rust tutorial covers Result and ?. Few cover what to actually do when you have 5 different error types flying around a real application.

Here's what I settled on after shipping multiple Tauri apps.

The problem: heterogeneous errors

A PDF processing command might fail due to:

IO error (file not found)
lopdf parse error (malformed PDF)
Encryption error (wrong key)
Swift sidecar error (process failed)
Serialization error (JSON parse)

Returning Box works but loses type information. Returning String works but is unstructured. Neither is great.

Pattern 1: domain error enum

Define one error type per domain:

#[derive(Debug, thiserror::Error)]
pub enum PdfError {
    #[error("file not found: {path}")]
    NotFound { path: String },

    #[error("malformed PDF: {reason}")]
    ParseError { reason: String },

    #[error("decryption failed — wrong password or corrupted file")]
    DecryptionFailed,

    #[error("sidecar process failed: {stderr}")]
    SidecarError { stderr: String },

    #[error("IO error: {0}")]
    Io(#[from] std::io::Error),
}

thiserror generates the Display and Error impls. #[from] generates From automatically — ? just works.

Pattern 2: convert at the boundary

Tauri commands need Result for the frontend. Convert at the command boundary, not inside business logic:

// Business logic — rich error types
pub fn process_pdf(path: &str) -> Result {
    // ...
}

// Tauri command — converts at boundary
#[tauri::command]
pub fn process(path: String) -> Result {
    process_pdf(&path).map_err(|e| e.to_string())
}

The frontend gets a human-readable error string. The backend keeps structured errors for matching and logging.

Pattern 3: context with anyhow

For scripts and one-off tools where rich error types aren't worth the boilerplate, anyhow adds context without ceremony:

use anyhow::{Context, Result};

pub fn load_config(path: &str) -> Result {
    let content = std::fs::read_to_string(path)
        .with_context(|| format!("failed to read config from {}", path))?;

    serde_json::from_str(&content)
        .with_context(|| "config file is not valid JSON")
}

Error messages chain automatically: "config file is not valid JSON: unexpected character at line 3"

Pattern 4: never panic in library code

unwrap() and expect() in library functions crash the whole app. In a long-running desktop app, a crash from a malformed PDF file is unacceptable.

Rule: unwrap() only in main() for setup that must succeed, or in tests.

// Bad — panics if PDF is malformed
let doc = Document::load(path).unwrap();

// Good — surfaces error to caller
let doc = Document::load(path)
    .map_err(|e| PdfError::ParseError { reason: e.to_string() })?;

What I actually use

thiserror for domain error enums in library code
anyhow for scripts and one-off tools
.map_err(|e| e.to_string()) at Tauri command boundaries
Never unwrap() in non-test, non-main code

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