A Real Tauri App: Cinder

"Abstractions are easy to nod along to. A real app is where they either hold or break."

Meet Cinder

Throughout this quest I'll ground the concepts in Cinder — a desktop creative tool Dad and I built and shipped on Tauri 2.0. Cinder is a second canvas that lives beside Photoshop: a candidate board, a lineage tracker, and a place an AI sidekick can paint into. It is desktop-only (macOS, specifically) — that matters, because the mobile track later teaches Tauri's phone story, which Cinder deliberately does not use. When I say 'in Cinder,' I mean a real, working desktop app, not a toy.

One honesty note: Cinder is not something you can git clone. I'm sharing its shape — the architecture and the decisions — not a download. The shape is the lesson; the lesson transfers to whatever you build.

The Two Halves, in a Real App

Cinder is exactly the two-process model you just learned. The webview is a React 19 + Vite frontend — the candidate board, the controls, the sidekick panel. The core is a small Rust crate split into focused modules: one file for the IPC commands, one for talking to a separate brain process over the network, one for window behavior, one for on-disk persistence. None of those modules is huge; each owns one concern. That is the normal end state of a Tauri core — not a monolith, a few sharp files behind the bridge.

What the Core Actually Pulls In

Cinder's core registers three plugins, and each exists for a concrete reason you'll meet again in the plugins track: a store plugin for settings that must survive restarts, a clipboard plugin to hand finished images back to Photoshop, and a window-state plugin so the window reopens where you left it. No plugin is added 'just in case' — each earns its place. That restraint is itself a lesson: a Tauri app stays small partly because you only pull in what you use.

Code

A real core, distilled to its skeleton·rust

// The SHAPE of a real Tauri 2 core entry (simplified from Cinder's lib.rs).
// Concepts shared, not a repo to clone. Each .plugin() earns its place.
pub fn run() {
    tauri::Builder::default()
        .plugin(tauri_plugin_store::Builder::new().build())            // settings that survive restarts
        .plugin(tauri_plugin_clipboard_manager::init())               // hand images to Photoshop
        .plugin(tauri_plugin_window_state::Builder::default().build()) // remember window pos + size
        .invoke_handler(tauri::generate_handler![/* your commands */])
        .run(tauri::generate_context!())
        .expect("error while running the app");
}

Exercise

Sketch the module split for YOUR app's Rust core the way Cinder splits its: name 3–5 files, each owning one concern (commands, persistence, a network client, window behavior, etc.). You're not writing code yet — you're deciding the shape. A good split has no file that does 'everything.'

Hint

Start from your IPC surface (the commands) and your side effects (disk, network, OS). Each distinct side effect tends to want its own module. If a file's name would be 'utils' or 'misc,' you haven't found its real concern yet.