Take a photo of a printed sheet-music part, get it back transposed into a different key and clef, with every accent and repeat intact, and print it. That's the whole product. It needs a 200 MB recognition engine written in Java, a PDF rasteriser, a local web server for the phone, and the ability to spawn and kill processes. None of that runs in a tab.
\nSo I built a desktop application. It’s called Semitone, it’s not public yet, and it’s a React app inside Tauri 2 with a Rust backend that does everything the browser can’t. This post is the Tauri half: what a React developer needs to know, what I’d do again, and the bits that ate whole days.
\nThe example that started the project is a 1. Flügelhorn in B part from a brass-band folder that has to be played from bass clef in C. Today the options are transposing by hand, re-entering it in a notation editor, or not playing. I’ll leave the music side for another post, because the desktop side is plenty.
Tauri gives you a native window with a system webview in it (WebKit on macOS, WebView2 on Windows) and a Rust process behind it. Your frontend is whatever you’d build for the web. Mine is React 19, Vite, Tailwind v4 and shadcn/ui, with Vitest for tests, and if you removed Tauri from the repository it would still start in a browser and render every screen. The Rust side exposes functions the frontend can call, and that’s the entire contract.
\nnpm create tauri-app@latestThat scaffolds both halves. The frontend lives in src/, the native side in src-tauri/, and tauri.conf.json describes the window, the bundle and the security policy. The dev loop is npm run tauri dev, which starts Vite on a fixed port and opens a window pointed at it. Hot reload works. Rust changes recompile and restart the window, which takes a few seconds and is the one place where the loop is slower than a web project.
Two Vite settings matter and the template sets both. The port is fixed and strict, because Tauri expects to find the dev server where it said it would be, and Vite is told to ignore src-tauri/ so a Rust edit doesn’t trigger a frontend rebuild.
A command is a Rust function with an attribute on it:
\n#[tauri::command]\npub fn host_info() -> HostInfo {\n HostInfo {\n platform: std::env::consts::OS.to_string(),\n app_version: env!(\"CARGO_PKG_VERSION\").to_string(),\n }\n}Register it in the builder, and the frontend calls it by name:
\nimport { invoke } from '@tauri-apps/api/core';\n\nconst info = await invoke<HostInfo>('host_info');Arguments and return values go through JSON, so anything that derives Serialize on the Rust side arrives as a plain object. The naming convention differs between the two languages, so nearly every struct I return carries #[serde(rename_all = \"camelCase\")], and errors are enums tagged with a code field so the frontend can switch on them rather than parse sentences.
Long work must not run on the thread that owns the window. Marking a command async puts it on Tauri’s runtime, and CPU-bound work goes one step further to the blocking pool:
#[tauri::command]\npub async fn export_pdf(svg_pages: Vec<String>, destination: String) -> Result<(), String> {\n tauri::async_runtime::spawn_blocking(move || {\n let pdf = svg_pages_to_pdf(&svg_pages).map_err(|e| e.to_string())?;\n std::fs::write(&destination, pdf).map_err(|e| e.to_string())\n })\n .await\n .map_err(|e| e.to_string())?\n}Laying out a twenty-page part is not something to do on a thread other commands are waiting on, and the frontend’s progress bar is one of those commands.
\nFor the other direction, Rust to frontend, there are events. The recognition engine runs for minutes and writes a log, so the Rust side follows the log and emits progress events that the React side subscribes to with listen. Same mechanism when the phone submits a photo, and when a second document is double-clicked while the app is already open.
Nothing in the frontend imports @tauri-apps/* except one folder, src/platform/. It exports a Host interface, every invoke in the application lives behind it, and the rest of the app asks for getHost() and doesn’t know what answers.
The reason is that a web version is a plausible future, and with this boundary it is one module swap: an HTTP-backed host instead of a Tauri-backed one. Without the boundary it’s a rewrite. So it is enforced by ESLint rather than remembered:
\n{\n files: ['src/**/*.{ts,tsx}'],\n ignores: ['src/platform/**'],\n rules: {\n 'no-restricted-imports': ['error', {\n patterns: [{\n group: ['@tauri-apps/*'],\n message: 'Reach the host through src/platform instead of calling Tauri directly.',\n }],\n }],\n },\n}The second lint rule in that config is the one I’d recommend to anyone shipping a product in two languages. react/jsx-no-literals with noStrings: true makes a hardcoded user-facing string a lint error. Every string comes from a catalog through t(), the English catalog is the authoritative set of keys, and the German type is derived from it, so a missing translation is a type error rather than a blank label found by a user. I wrote about switching to Biome last year and I still like it. This project stayed on ESLint because both of those rules are the reason the codebase has the shape it has, and I wasn’t going to give them up for a faster linter.
Tauri 2 replaced the old allowlist with capabilities. A JSON file per window says which permissions the webview gets, and by default it gets almost nothing:
\n{\n \"identifier\": \"default\",\n \"windows\": [\"main\"],\n \"permissions\": [\n \"core:default\",\n \"dialog:allow-save\",\n \"dialog:allow-open\",\n \"dialog:allow-ask\",\n \"dialog:allow-message\",\n \"core:window:allow-destroy\"\n ]\n}This is the first thing to look at when a plugin call silently does nothing. Your own commands don’t need entries here, but every plugin API does, and the error when you forget is not always loud. The model is sound: the webview is running content you control today and possibly content you don’t tomorrow, and a save dialog it wasn’t granted is a save dialog it can’t open.
\nThe content security policy lives next to it in tauri.conf.json. Mine needed 'wasm-unsafe-eval' in script-src because the engraving library is WebAssembly, blob: in worker-src because it runs in a worker, and the asset: protocol in img-src so the app can show a page it wrote to disk. Each of those fails silently when it’s missing: a blank pane and nothing in the console.
Recognition is done by Audiveris, an open-source optical music recognition engine. It is written in Java, it ships with its own trimmed runtime, and it is AGPL. Semitone is not.
\nThat combination is workable only under strict process separation, and I wrote the rules down before writing the code. Audiveris runs as a subprocess. Arguments go in on the command line, MusicXML comes back out of a directory, and that is the whole interface. No JVM linked into my process, no calls into its classes, no parsing its project files, no source patches, no forks. The launcher and its runtime are vendored into the bundle by a script that downloads the exact upstream release, checks it against the digest upstream publishes, and unpacks it without modification.
\nnpm run audiveris:vendorIt is deliberately absent from the licence inventory, because the inventory describes what is compiled or bundled into Semitone and the whole position rests on the answer being “none of it”. The position itself is written up for a lawyer to read before anyone pays for this. I’m a developer, not a lawyer, and the honest version of that sentence is that I built the process boundary as narrow as it can be and then stopped guessing.
\nOn the Rust side the interesting problems are the ones every subprocess has and nobody plans for. A run takes minutes, so the log is followed to make the wait legible. The user can cancel, so the child is in its own process group and the signal reaches the whole tree; on Windows that means taskkill, an external program that can be missing, with Child::kill as the fallback. Quitting during a run must not leave an orphan JVM behind. And the working directory is removed on every path out, so a cancelled job leaves nothing on disk.
Engraving, turning MusicXML into a picture of music, is done by Verovio, compiled to WebAssembly and running in a Web Worker so the UI stays responsive. Verovio is LGPL, and its WASM is inlined into its JavaScript as a string, so bundling it into the app chunk would be a lot closer to static linking than to dynamic.
\nThe answer is to not bundle it. A script copies the two files verbatim out of node_modules into public/, where Vite treats them as static assets loaded at runtime, and it fails the build if the version in package.json isn’t pinned exactly. It runs on predev and prebuild, so nobody has to remember it.
I mention both of these because licensing is the part of a desktop app that a web developer has never had to think about. On the web you serve, you don’t distribute. The moment you ship a binary, every dependency is something you’re conveying, and the difference between “an aggregate” and “a combined work” decides whether you have to publish your own source.
\nWhich is why there’s a CI job for it. Two scripts generate an inventory of every npm package and every Rust crate that ends up in the bundle, with its licence text, and a third checks them against a list of what we permit. Not what we recognise, what we permit. AGPL, SSPL, Commons Clause, non-commercial terms and packages with no licence declared all fail the build, and so does anything nobody has thought of yet, because it isn’t on the list.
\nnpm run licences:npm\nnpm run licences:cargo\nnpm run licences:checkThe committed inventories have to match the tree, so CI regenerates them and diffs. The app shows the whole inventory under a Licences entry in the header, which is about 750 kB of licence text in a chunk of its own that Vite would otherwise warn about on every build.
\nIt also shaped the Rust dependencies more than I expected. The PDF rasteriser is hayro, a pure Rust crate, because the obvious choices are MuPDF and Poppler and both are copyleft, and the third is a C++ blob I’d have to vendor per platform. Most crates have default-features = false, partly for size and partly because the default feature set of an image library is twenty decoders, every one of them a parser running on a file a stranger sent you.
The release profile has panic = \"unwind\" where the template had abort. Abort is smaller. But the app runs two parsers over files that arrive from outside, images and PDFs, and the “we show a message rather than crash” behaviour only exists if a panicking task can be caught. With abort, the same panic takes the process down with the user’s corrected part in it, unsaved since the last thirty-second autosave. I measured the cost: 9.27 MB to 11.05 MB, plus 19 percent on my binary. Against the 200 MB engine sitting next to it, that’s under one percent of the download. Crash safety on hostile input is worth nine tenths of one percent.
The updater was the other one. Tauri’s updater doesn’t patch, it replaces the whole bundle. So an update from 0.1.0 to 0.2.0 downloads 101.5 MiB, of which 93 MiB is a recognition engine that hasn’t changed. Semitone’s own binary, frontend, fonts and engraver come to 8.4 MiB compressed. The update is twelve times larger than it needs to be, and for now that stands, because splitting the engine into its own installable piece is a real build and the release cadence doesn’t justify it yet. The updater itself added 4.6 MiB to the binary, which is what an HTTP client, a TLS stack and a tar reader weigh. It’s written down with the numbers so the next person doesn’t re-measure it.
\nFour jobs. A fast one on Ubuntu with no Rust toolchain: format, lint, typecheck, tests, the fixture and inventory checks, the licence gate. A Rust one, also on Ubuntu because it’s the cheapest place to run Clippy with -D warnings and the unit tests, including a golden-PDF test that catches print regressions nobody would otherwise notice until they printed. A build matrix for the two platforms we ship, macOS on Apple Silicon and Windows x64, which vendors the engine, builds the installer, weighs it against a committed size budget and uploads it. And a nightly job on macOS that runs the real engine on a real picture of music and checks that MusicXML comes out, because that’s too slow and too large for every push. The Windows build only exists in CI. You cannot build it on a Mac.
I’ve written about containerising a Next.js app and the shape here is the same one: the artefact you test is the artefact you ship, or the test is theatre.
\nThe release workflow is the part I’m most pleased with, for a reason that has nothing to do with code. It runs end to end with no secrets configured at all. No signing certificate, no Apple account, no updater key. It builds both installers, weighs them, labels them UNSIGNED in the artefact name, and refuses to publish. A release pipeline nobody can exercise until the certificates arrive is a pipeline nobody has tested, and the day the certificates arrive is the worst possible day to find out it doesn’t work. The label has three states, not two, because signed-not-notarized on macOS still stops at Gatekeeper with a different message and the same outcome.
Two small things from that pipeline that I’d have paid to know in advance. The macOS runner’s bash is 3.2, where expanding an empty array under set -u is an error, which the modern bash on your own machine will never show you. And Tauri’s .dmg step drives Finder over AppleScript to lay out the window, which stalls on a permission prompt the first time you run it on a machine. CI=true skips that cosmetic step, and the runner sets it for you, so this only ever bites locally.
One feature that’s worth a paragraph because the obvious approach is wrong. You can photograph a part with your phone and have it land in the app: the app starts a small web server on the LAN, shows a QR code, and the phone opens the page. My first instinct was a live camera preview with getUserMedia. That requires a secure context, a phone hitting http://192.168.x.x:port doesn’t have one, and a self-signed certificate produces a full-page warning that reads as a broken app. A plain <input type=\"file\" capture=\"environment\"> needs no secure context and uses the phone’s own, better, camera app. Less code and a nicer photo 🎺.
The thing I should say plainly: the go/no-go for this whole product, whether correcting recognition output on real photographs actually beats transposing by hand, has not been run. It needs eight to ten real photographed band parts and a half-day against a protocol that’s written and ready. Everything downstream of it is built. That order is backwards and I know it. The MusicXML-in, transposed-part-out path stands on its own if the answer is no, which is the excuse I’m using.
\nTwo release blockers are open and named: the updater has no public key yet, and the AGPL written offer inside the bundle still names a placeholder address. Both need a person, not a build.
\nWould I use Tauri again? Yes, without much hesitation. The window is the OS’s own webview, the binary is small, the command boundary is simple, and Rust on the other side of it is a good deal more pleasant than I expected for a job that is mostly “run this program and read its output”. The parts that cost time were never Tauri. They were the parts of shipping software to strangers’ machines that the web had let me forget about.
\n‘Till next time!
","rawMarkdownBody":"\n## The browser was never going to do this\n\nTake a photo of a printed sheet-music part, get it back transposed into a different key and clef, with every accent and repeat intact, and print it. That's the whole product. It needs a 200 MB recognition engine written in Java, a PDF rasteriser, a local web server for the phone, and the ability to spawn and kill processes. None of that runs in a tab.
\n\nSo I built a desktop application. It's called Semitone, it's not public yet, and it's a React app inside Tauri 2 with a Rust backend that does everything the browser can't. This post is the Tauri half: what a React developer needs to know, what I'd do again, and the bits that ate whole days.\n\nThe example that started the project is a `1. Flügelhorn in B` part from a brass-band folder that has to be played from bass clef in C. Today the options are transposing by hand, re-entering it in a notation editor, or not playing. I'll leave the music side for another post, because the desktop side is plenty.\n\n### What Tauri actually is\n\nTauri gives you a native window with a system webview in it (WebKit on macOS, WebView2 on Windows) and a Rust process behind it. Your frontend is whatever you'd build for the web. Mine is React 19, Vite, [Tailwind v4](/blog/tailwind-css-v4/) and shadcn/ui, with Vitest for tests, and if you removed Tauri from the repository it would still start in a browser and render every screen. The Rust side exposes functions the frontend can call, and that's the entire contract.\n\n```sh\nnpm create tauri-app@latest\n```\n\nThat scaffolds both halves. The frontend lives in `src/`, the native side in `src-tauri/`, and `tauri.conf.json` describes the window, the bundle and the security policy. The dev loop is `npm run tauri dev`, which starts Vite on a fixed port and opens a window pointed at it. Hot reload works. Rust changes recompile and restart the window, which takes a few seconds and is the one place where the loop is slower than a web project.\n\nTwo Vite settings matter and the template sets both. The port is fixed and strict, because Tauri expects to find the dev server where it said it would be, and Vite is told to ignore `src-tauri/` so a Rust edit doesn't trigger a frontend rebuild.\n\n### Commands, the door between the two worlds\n\nA command is a Rust function with an attribute on it:\n\n```rust\n#[tauri::command]\npub fn host_info() -> HostInfo {\n HostInfo {\n platform: std::env::consts::OS.to_string(),\n app_version: env!(\"CARGO_PKG_VERSION\").to_string(),\n }\n}\n```\n\nRegister it in the builder, and the frontend calls it by name:\n\n```ts\nimport { invoke } from '@tauri-apps/api/core';\n\nconst info = await invoke