How to make your Tauri dev faster

Tauri lets us build cross-platform desktop apps using web stack. Compared to Electron, Tauri apps often have smaller bundle sizes and use less memory at runtime. That's why I usually pick Tauri for my desktop projects. However, during development, especially after changing the Rust code, the tauri dev command can sometimes take a really long time to compile. It might even recompile many dependencies every single time you make a change, which seriously slows down development. This post shares some tips and tricks I found while trying to speed up the development compile times for my app. Why Is It So Slow? First things first: why does tauri dev take so long? If you look at the command's output, you might notice it recompiles a bunch of unchanged dependencies every time you modify your Rust code. After some digging, I found the reason: Tauri uses the bundle.macos.minimumSystemVersion setting from your tauri.config.json as the value for the MACOSX_DEPLOYMENT_TARGET environment variable during its build process. If you haven't set it, it defaults to 10.13. When you save changes in your editor, rust-analyzer often runs cargo check to look for errors. But, it usually runs without MACOSX_DEPLOYMENT_TARGET being set. This difference in environment variables between rust-analyzer's check and the actual tauri dev build forces some dependencies to be recompiled twice – once by rust-analyzer and then again by tauri dev. For my app, a simple code change initially meant waiting about a minute for the compile to finish. So, how do we fix this? We need to make sure both rust-analyzer and Tauri use the same value for MACOSX_DEPLOYMENT_TARGET. Add this to your editor's settings (e.g., VS Code's settings.json.): { "rust-analyzer.cargo.extraEnv": { "MACOSX_DEPLOYMENT_TARGET": "10.13" } } And add this to your tauri.config.json: { "bundle": { "macos": { "minimumSystemVersion": "10.13" } } } Make sure the version string ("10.13" in this case) matches in both places. After saving these changes, restart your editor and the tauri dev process. Now, try changing your Rust code again. You should see a noticeable improvement. My one-minute compile time dropped to around 25 seconds. rust-analyzer Still Causing Issues? Even after fixing the environment variable mismatch, you might still hit frustrating delays. Sometimes, you'll see tauri dev stuck on a message like Blocking waiting for file lock on build directory. What's happening here? rust-analyzer runs cargo check in the background to give you live feedback. Both this background check and your manual tauri dev command need to access and modify files in your project's target directory. When they try to do this at the same time, one has to wait for the other to release the "lock", causing your build to pause. Fortunately, rust-analyzer has a setting to fix this: you can tell it to put its build files in a separate directory, avoiding conflicts with tauri dev. Add this to your editor's settings: { "rust-analyzer.cargo.targetDir": "target/analyzer" // Alternatively, setting it to true uses 'target/rust-analyzer' by default // "rust-analyzer.cargo.targetDir": true } This tells rust-analyzer to put its temporary build artifacts in the target/analyzer subdirectory. With this change, rust-analyzer's background checks won't block tauri dev anymore. The trade-off is that you'll use a bit more disk space for this extra build cache, but the boost in development speed is usually well worth it. Try changing Rust code one more time, tauri dev start compiling almost instantly. The total compile time should drop further, maybe down to 15-20 seconds. Setting targetDir actually solves the original environment variable problem too! Because rust-analyzer now uses a completely separate build cache, its environment doesn't interfere with tauri dev's environment. This is why I recommend using the targetDir setting over manually setting MACOSX_DEPLOYMENT_TARGET, it solves both problems with one configuration change. Tweaking Cargo Profiles We've tackled the environment conflicts and file lock issues, significantly speeding things up. Can we go even faster? Yes! Let's look at Cargo's build profiles, specifically the development profile (profile.dev), to squeeze out a few more seconds. The profile.dev section in your src-tauri/Cargo.toml controls how cargo build (and thus tauri dev by default) behaves during development. Key settings include: opt-level: How much optimization the compiler applies. Default is 0 for fastest compiles. debug: How much debugging information is included. Default is true. incremental: Whether to use incremental compilation (only recompile changed parts). Default is true. Incremental compilation (incremental = true) is crucial for fast rebuilds, so we usually want to keep that enabled. However, we can often speed things up by slightly changing the settings for dependencies. We

May 2, 2025 - 00:19
 0
How to make your Tauri dev faster

Tauri lets us build cross-platform desktop apps using web stack.
Compared to Electron, Tauri apps often have smaller bundle sizes and use less memory at runtime.
That's why I usually pick Tauri for my desktop projects.

However, during development, especially after changing the Rust code, the tauri dev command can sometimes take a really long time to compile.
It might even recompile many dependencies every single time you make a change, which seriously slows down development.

This post shares some tips and tricks I found while trying to speed up the development compile times for my app.

Why Is It So Slow?

First things first: why does tauri dev take so long?
If you look at the command's output, you might notice it recompiles a bunch of unchanged dependencies every time you modify your Rust code.

After some digging, I found the reason: Tauri uses the bundle.macos.minimumSystemVersion setting from your tauri.config.json as the value for the MACOSX_DEPLOYMENT_TARGET environment variable during its build process.
If you haven't set it, it defaults to 10.13.

When you save changes in your editor, rust-analyzer often runs cargo check to look for errors. But, it usually runs without MACOSX_DEPLOYMENT_TARGET being set.
This difference in environment variables between rust-analyzer's check and the actual tauri dev build forces some dependencies to be recompiled twice – once by rust-analyzer and then again by tauri dev.

For my app, a simple code change initially meant waiting about a minute for the compile to finish.
So, how do we fix this? We need to make sure both rust-analyzer and Tauri use the same value for MACOSX_DEPLOYMENT_TARGET.

Add this to your editor's settings (e.g., VS Code's settings.json.):

{
  "rust-analyzer.cargo.extraEnv": {
    "MACOSX_DEPLOYMENT_TARGET": "10.13"
  }
}

And add this to your tauri.config.json:

{
  "bundle": {
    "macos": {
      "minimumSystemVersion": "10.13"
    }
  }
}

Make sure the version string ("10.13" in this case) matches in both places. After saving these changes, restart your editor and the tauri dev process.
Now, try changing your Rust code again. You should see a noticeable improvement. My one-minute compile time dropped to around 25 seconds.

rust-analyzer Still Causing Issues?

Even after fixing the environment variable mismatch, you might still hit frustrating delays. Sometimes, you'll see tauri dev stuck on a message like Blocking waiting for file lock on build directory.

What's happening here? rust-analyzer runs cargo check in the background to give you live feedback. Both this background check and your manual tauri dev command need to access and modify files in your project's target directory.
When they try to do this at the same time, one has to wait for the other to release the "lock", causing your build to pause.

Fortunately, rust-analyzer has a setting to fix this: you can tell it to put its build files in a separate directory, avoiding conflicts with tauri dev.

Add this to your editor's settings:

{
  "rust-analyzer.cargo.targetDir": "target/analyzer"
  // Alternatively, setting it to true uses 'target/rust-analyzer' by default
  // "rust-analyzer.cargo.targetDir": true
}

This tells rust-analyzer to put its temporary build artifacts in the target/analyzer subdirectory.

With this change, rust-analyzer's background checks won't block tauri dev anymore.
The trade-off is that you'll use a bit more disk space for this extra build cache, but the boost in development speed is usually well worth it.

Try changing Rust code one more time, tauri dev start compiling almost instantly. The total compile time should drop further, maybe down to 15-20 seconds.

Setting targetDir actually solves the original environment variable problem too!
Because rust-analyzer now uses a completely separate build cache, its environment doesn't interfere with tauri dev's environment.
This is why I recommend using the targetDir setting over manually setting MACOSX_DEPLOYMENT_TARGET, it solves both problems with one configuration change.

Tweaking Cargo Profiles

We've tackled the environment conflicts and file lock issues, significantly speeding things up.
Can we go even faster? Yes! Let's look at Cargo's build profiles, specifically the development profile (profile.dev), to squeeze out a few more seconds.

The profile.dev section in your src-tauri/Cargo.toml controls how cargo build (and thus tauri dev by default) behaves during development. Key settings include:

  • opt-level: How much optimization the compiler applies. Default is 0 for fastest compiles.
  • debug: How much debugging information is included. Default is true.
  • incremental: Whether to use incremental compilation (only recompile changed parts). Default is true.

Incremental compilation (incremental = true) is crucial for fast rebuilds, so we usually want to keep that enabled.

However, we can often speed things up by slightly changing the settings for dependencies.
We rarely debug directly into third-party library code, so we might not need full debug info for them.
Sometimes, applying a small amount of optimization to dependencies can even make the final linking step faster.

You can add or modify the [profile.dev] and [profile.dev.package."*"] sections in your src-tauri/Cargo.toml:

# src-tauri/Cargo.toml

# ...

[profile.dev]
incremental = true
opt-level = 0
debug = true

[profile.dev.package."*"]
opt-level = 1
debug = false

Notes:

  • Changing profiles involves trade-offs. Less debug info makes debugging harder. Optimizing dependencies might hide bugs that only appear at opt-level = 0.
  • The first compile after changing these settings will likely be slow as Cargo rebuilds things. Judge the improvement based on subsequent incremental builds.

After applying this, my compile times settled into the 10-15 second range.

Wrapping Up

By making a few adjustments, we can significantly cut down on frustratingly long Tauri development compile times:

  1. Configure rust-analyzer.cargo.targetDir: This is the most crucial and recommended step. Giving rust-analyzer its own build directory solves file lock conflicts with tauri dev and indirectly fixes environment variable mismatches (like MACOSX_DEPLOYMENT_TARGET). It provides the biggest speed boost with minimal downsides.
  2. Adjust [profile.dev.package."*"]: After fixing the main bottlenecks, you can potentially gain a little more speed by applying slight optimizations and disabling debug info for your dependencies in Cargo.toml. This is more of a fine-tuning step and requires testing.

With these optimizations, the compile time for an app dropped from over a minute to just 10-15 seconds. While using a separate targetDir consumes extra disk space, the time saved makes it a worthwhile trade-off.

Hopefully, these tips, gathered from troubleshooting real problems and exploring community solutions, will help you escape slow tauri dev builds and let you focus more on building great Tauri app!

References