"The config file is the contract between your web half and your native half. Read it like one."
The Four Sections That Matter
tauri.conf.json is small but load-bearing. Four top-level sections do almost all the work:
- Identity —
productName,version, andidentifier(a reverse-DNS string likecom.acme.myapp). The identifier is how the OS names your app's data folders and signs your bundle. build— how the frontend connects:beforeDevCommand(start your dev server),devUrl(where it lives, e.g.http://localhost:1420),beforeBuildCommand(build for production), andfrontendDist(the folder of built static files Tauri ships).app— runtime UI: the initialwindowsarray (size, title, resizable…) andsecurity(notably the Content Security Policy).bundle— packaging: whether bundling isactive, whichtargetsto build (.dmg, .msi, AppImage…), and theiconset.
devUrl vs frontendDist: the Dev/Prod Switch
This pair confuses everyone once. In dev, Tauri points the webview at devUrl — a live dev server with hot-reload. In build, there is no server; Tauri loads the static files in frontendDist bundled inside the app. Same app, two ways of feeding it HTML. If your built app shows a blank window but dev works, frontendDist pointing at the wrong folder is the usual culprit.
The Schema Line Is Your Friend
The first line, "$schema": "https://schema.tauri.app/config/2", isn't decoration — it gives your editor autocomplete and validation for every field. If a key turns red in your editor, you typo'd it or it doesn't exist in v2. Trust the schema over a blog post written for v1.