Tauri 2.0 and Next.js 16 template: a desktop app front end

The author's own warning comes first

The most important line in the README is the important callout at the very top. It says that Next.js is typically overkill for the frontend of a Tauri application, and that the author would personally recommend checking out the tauri-tanstack-start-react-template first. That is a maintainer telling you that this repository is not the first thing to reach for, which is rare and worth taking seriously. The rest of the README is an accurate description of what the template does, and the two facts sit together without contradiction. This is a working, opinionated starting point for a specific pairing, published by someone who has thought about the alternatives and considers this one the second best option for a new project. If you are evaluating rather than committing, that framing should shape the questions you ask.

How the two halves fit together

The template is a Tauri project using Next.js, bootstrapped by combining create-next-app and create tauri-app, so it is a merge of two official scaffolds rather than something hand built from scratch. It uses pnpm as the Node.js dependency manager and the App Router model for Next.js. The source layout is split the way you would expect, with the Next.js front end source files in `src/` and the Tauri Rust application source files in `src-tauri/`, and the README points you to the respective documentation for questions about either technology. The top level of the repository reflects that division, with `src/`, `src-tauri/`, `public/`, `next.config.ts`, `tsconfig.json`, `postcss.config.mjs`, `biome.json`, `vitest.config.mts`, a `pnpm-workspace.yaml` and a `.node-version` file. The package.json confirms the versions in play, with Next 16, React 19, the Tauri API at 2.12.1 and the Tauri CLI at 2.12.1, and the project marked as an ES module with pnpm 12.8.1 as the package manager.

One command, and the identifier you must change first

The getting started section is short and the order matters. After cloning for the first time, you change your app identifier inside `src-tauri/tauri.conf.json` to your own, and the reason is given in a comment in the file itself:

{
  // ...
  // The default "com.tauri.dev" will prevent you from building in release mode
  "identifier": "com.my-application-name.app",
  // ...
}

That is a genuinely useful kind of comment, because the failure it prevents is the sort that only shows up when you try to produce a release build. Once that is done, you develop and run the front end in a Tauri window with:

pnpm tauri dev

This loads the Next.js front end directly in a Tauri webview window, in addition to starting a development server on `localhost:3000`. The README also gives a shortcut for inspecting it, pressing Ctrl and Shift and I in a Chromium based WebView, for example on Windows, to open the web developer console from the Tauri window. That combination of a dev server and a webview is the workflow you will spend most of your time in.

Static export, and why SSR is out

The caveats section covers the constraint that shapes the whole template. Next.js supports both server-side rendering and static site generation, but for a Tauri front end only SSG can be used, since SSR requires an active Node.js server, and a Tauri app has no server, it has a webview loading local files. The README links the Next.js documentation on static exports for the supported and unsupported features. The second caveat is the `next/image` component, which is an enhancement over the regular img element with server-side optimizations to scale image quality dynamically. It is only supported when deploying the front end onto Vercel directly, and must be disabled to export the front end statically, which is why the `unoptimized` property is set to true for the next/image component in the `next.config.js` configuration. The effect is that the image is served as is, without changes to its quality, size or format. The repo actually ships a `next.config.ts`, so the README's reference to `next.config.js` is a small inconsistency.

The window and navigator trap

The third caveat is the one that will cost you an hour if you meet it cold. If you are using Tauri's `invoke` function or any OS related Tauri function from within JavaScript, you may encounter a ReferenceError saying window or navigator is not defined when importing the function in a global, non-browser context. The cause is the nature of the Next.js dev server, which effectively runs a Node.js server for SSR and for hot module replacement, and Node.js has no notion of window or navigator. The fix is to ensure that the Tauri functions are imported as late as possible from within a client-side React component, or via lazy loading. This is a genuinely awkward consequence of the pairing, and it is a direct argument for the author's other template, where the dev server is not running a Node.js server in the same way. It is also the kind of constraint that a linter or a type checker will not catch for you, because the import is perfectly valid JavaScript.

One linter for TypeScript, two for Rust

The formatting and linting story is opinionated and already set up, which is one of the main reasons to start from a template rather than from an empty directory. For TypeScript it is Biome, a combination of fast formatting, linting and import sorting, run through the `biome format` and `biome check` scripts. For Rust it is clippy and rustfmt, and the repository has a `.clang-format` style of config for the native side as well. GitHub Actions are set up to check code formatting and linting for both TypeScript and Rust, so a pull request that breaks either side fails on the server rather than in review. On the styling side, the example page in the template has been updated to use only TailwindCSS, and the README suggests considering React Aria components and HeadlessUI components for completely unstyled and fully accessible UI components, which integrate nicely with TailwindCSS.

The build and the test setup

The package.json scripts are short and they expose the whole workflow. `dev:next` runs the Next.js dev server with Turbopack, `build:next` runs the production build, and `tauri` is the passthrough to the Tauri CLI, with `dev` and `build` wrapping it as `tauri dev` and `tauri build`. The release build is the same command the developer uses, since the difference between development and release is handled inside Next.js by exporting the front end statically rather than by a separate script. Tests are `vitest run` with a `vitest.config.mts` at the top level, and the dev dependencies show a full modern testing setup with vitest 5, vite 8, jsdom, the React testing library and the React plugin, plus TypeScript around 7.0. So the template ships with a test runner, a browser-like environment and React component testing already configured rather than leaving you to add them.

Where this is the wrong choice

The limits are clear. The first is the author's own verdict, that Next.js is typically overkill for a Tauri front end, and the existence of an alternative template by the same author is the evidence. If you have not yet chosen the front end framework, the decision you are making here is a real one with real costs, and this repository is the more expensive side of it. The second is the static export constraint. A Tauri app with a Next.js front end cannot have server-side rendering, cannot use the image optimisation of next/image, and inherits a dev server that runs in Node, which is the direct cause of the window and navigator error. The third is the version churn, with Next 16, React 19, Tailwind 4, Biome 2, Vite 8, vitest 5 and TypeScript 7 all in the dependency list at once, so the template will age and the fixes will be yours to chase. The fourth is that the template is a starting point rather than a product, so the app identifier, the window configuration, the theme and the packaging are all left for you, and the repository publishes no releases, so there is no version history to consult when something breaks.

Editorial conclusion

The template fits a team that has decided on Next.js for a Tauri desktop app and wants the linting, formatting and CI wiring already in place, particularly because the caveats around static export and the window and navigator error are exactly the ones you would otherwise hit in an afternoon. It is the wrong choice if you are starting a new Tauri project, since the README's own advice is to check the author's TanStack Start template first on the grounds that Next.js is typically overkill for a Tauri front end. Before you build, change the app identifier in `src-tauri/tauri.conf.json`, because the default prevents a release build, and read the caveats on `next/image` and the client-only import rule. The last push was on 2026-10-17, the repository publishes no GitHub releases, and the licence is MIT.

Frequently asked questions

Official sources

1. Issues
2. kvnxiao/tauri-nextjs-template on GitHub
3. License: MIT
4. README