We are very proud to finally announce the stable release for the new major version of Tauri. Welcome to Tauri 2.0!

What is Tauri?

In a Tauri application the frontend is written in your favorite web frontend stack. This runs inside the operating system WebView and communicates with the application core written mostly in Rust.

When Should I Use Tauri?

If you check any of the boxes below, you should use Tauri:

• Do you want a single UI codebase for all platforms?
• Do you want to reach as many users as possible on their platform (eg. Windows, MacOS, Linux, Android, iOS)?
• Are you a frontend web developer and want to write native applications?
• Are you a Rust developer looking to write applications with a nice looking UI with the option to do it in Rust?
• Do you have an existing team of web developers and want to expand to native application markets with low upfront investment?
• Do you have an existing team of rustaceans and want everything written in Rust?

How Popular is Tauri?

On GitHub the Tauri repository has ~4,878 Pull Requests and ~3,570 Issues closed and around 1000 discussions, at the time of writing. To get a more detailed insight take a look at the OSSinsight analysis of the Tauri repository.

Our Discord Server currently has ~17,700 members. We are seeing a lot of individual user support, questions on Tauri itself, questions directly to the working group or just discussions between fellow Tauri app developers.

We are very happy about the positive and supportive community and grateful to all the community members answering or helping others in Discord or GitHub.

We maintain a curated list of Tauri related projects, applications, plugins, guides and more at awesome-tauri. Check this out if you want to get inspiration, see what others are building and ideally create a PR to add your project.

Of course this is only a representative sample set and we don’t know exactly who else is building on Tauri.

How Did We Get to 2.0?

In June 2022 we released Tauri 1.0 with a great impact on the desktop operating system market and how cross platform applications can be built.

In the end of 2022 we released our initial alpha version of 2.0 to get initial feedback and to test out how mobile interaction should be defined.

After the initial alpha we spent close to two years refining and changing the architecture of Tauri in public. After we saw the broad picture clear enough ourselves we released the beta in Februrary this year. At the same time we collaborated and worked with external security auditors to check our decisions, architecture changes and much more.

This August we published the release candidate version of 2.0 to iron out major bugs and to get more feedback from productive use. At the same time the external audit was concluded and made public.

The release candidate time frame was considerably shorter and consisted mainly of high impact bugfixes and documentation improvements. Some breaking changes we had to make during the release candidate phase were bundled up until the end and are now included in the stable release. Take a look at the migration section if your main concern is upgrading from a previous version.

In total we spent over two years working on improvements, new features, bugfixes, documentation, rewrites and a lot of discussions.

This all happened while we released 8 minor versions of the Tauri 1.x branch and backported security fixes and other important bug fixes in several patch releases.

Who Made This Release Possible?

This release and Tauri itself is only possible due to massive amount of contributions from Lucas, who has provided a constant stream of code changes over the years ❤️.

Obviously, Lucas is not the only individual working and contributing to Tauri, but we feel he deserves a very special mention for carrying, starting, and supporting the project and its community throughout the years.

We have had major contributions to the Tauri repository in 2.0 from Amr, Fabian-Lars, Tony, Chip, Jason, YuWei, icb , Simon, Oliver Lemasle and many more contributors (source data).

We received an increasing number of drive-by contributors (one or very few PRs). We are grateful for these, but naming everyone would make this a very long list here.

We have a lot(!) of repositories in our organization, which are supporting the success of Tauri and without community and working group contributions Tauri would not be where it is now. A big thank you to everyone involved!

Another special shout out and thanks for their constant involvement in the community goes to Fabian-Lars and Simon. If you have been involved in Tauri’s Discord or Github discussions you likely know their name or avatar.

If you ever searched on Google or YouTube for Tauri, you have probably seen one of Jacob’s streams. If that’s not the case please make sure to check it out and subscribe as his sessions are beyond just educational.

Another special place in our heart has the Tauri Board, highlighting Daniel Yvetot-Thompson for the numerous hours, sweat, blood and dedication to make Tauri known and sustainable.

One important thing we should not forget, is that we acquired support from a stable partner of this open source project.

CrabNebula granted multiple people mentioned above and others that are not mentioned here, the privilege to work on the Tauri ecosystem not only in their private time, but also during work time. You can find the partnership announcement on our blog and we have been more than happy about this collaboration over the last year.

In 2024 alone they spent over 2,870 work hours on this project, which massively pushed the progress and allows us to announce the stable 2.0 release today.

If you were not aware of CrabNebula yet, make sure to check out their products and services and consider the symbiotic relationship with Tauri if you are interested in not only improving your workflows, but also supporting the Tauri ecosystem.

What Makes 2.0 Great?

With this major release we improved and changed several aspects of how and where you can build, develop and publish your Tauri app. In the following sections we have more detailed insight. This does not cover everything, but should give you a decent impression on what you can expect from Tauri.

Getting Started Experience

One thing you are always going to go through when starting with a new framework or tool is the initial onboarding or getting started process.

We value developer experience (DX) and try to make this initial process as seamless as building and distributing your final application.

For this we created another project, which is called create-tauri-app or in short CTA. This tool allows developers to start from scratch and get to a running Tauri app in a few minutes instead of hours.

Of course you need to install some prerequisites on your development system before you can start building your application. For this we have extensive guides with operating system specific sections in our official documentation.

This whole onboarding experience has been improved and now also bootstraps mobile development templates for iOS and Android.

Hot-Module Replacement

After the initial onboarding you will regularly develop and debug your Tauri application. We considered what would improve your development process already in 1.x of Tauri and extended the Hot-Module Replacement (HMR) to mobile devices and emulators.

This means that all changes to the frontend of your application do not require a rebuild of your whole application and you can live preview how it will look like in the device or operating system your are developing for.

Plugins

With Tauri 2.0 we built a more advanced plugin system. We transferred a lot of our previous functionality into our official plugins (see plugins-workspace), to allow the community an easier entry into contributing to Tauri. We also hope to attract more maintainers for plugins and to speed up the process of implementing new features.

This move to plugins has another benefit. We are going to be able to define a definition of done for Tauri’s core. We hope to stabilize the core functionality and offer a stable framework, where the moving parts are mostly plugins offering access to system specific functionality.

You no longer need to understand all of Tauri to improve or implement specific features. The plugins usually do not depend on other plugins, with some exceptions. This means to implement a new file system access functionality it is only required to contribute to the fs plugin instead of Tauri itself.

As this release also targets mobile platforms, the plugin system also supports mobile plugins. You can write or re-use native code in Swift on iOS and Kotlin on Android and directly expose functions to the Tauri frontend using Annotations (@Command on Android), implementing a Subclass (YourPluginClass: Plugin) on iOS, or by invoking the Swift or Kotlin code from a Rust based Tauri command. Check out the documentation on how to write your own plugin.

As we are releasing Tauri as 2.0, the official plugins will follow the major version of Tauri to make compatibility with Tauri’s major version visible at a glance. Not all plugins are as stable as Tauri itself though.

Each plugin’s stableness is defined per plugin and documented (soon) in the plugin documentation. The plugin API can possibly break in minor versions, but we will try to keep these changes to a minimum, especially for plugins considered stable.

Mobile Support

A very much awaited part of this release is the mobile operating system support. The previous version of Tauri allowed to have a single UI code base for desktop operating systems but now this extends to iOS and Android.

We have investigated and experimented with different solutions to support mobile and decided on using the operating system native language (Swift and Kotlin) to build an interface for the Rust code and to allow developers to write part of their functionality in these languages.

This means you can re-use existing logic of your Swift or Kotlin app that interacts with the system and expose it to Rust or the frontend. Right now this works as mentioned above via the plugin system.

We support development with an emulator or a real device and provide a lot of tooling to make the process as seamless as possible. We are not completely happy about the developer experience at the moment but are actively improving to bring it up to par with the desktop experience.

On mobile not all of the official plugins are supported. Some are by design not a good fit for mobile and some are just not implemented to support mobile yet. If you would like to contribute on this part check the last section of this post.

The Allowlist is Dead, Long Live the Allowlist

Yes, there is no allowlist anymore, as we hit the limits of this system pretty quickly. We made it exclusive for Tauri core features and it did not even cover all of Tauri’s APIs. Our new system not only covers all of Tauri’s core API surface, it also supports app and plugin developers to implement their own access control and scoping with a unified approach.

The new system we implemented is using permissions - “On-off toggles for Tauri commands”, scopes - “Parameter validation for Tauri commands” and capabilities - “Attaching permissions and scopes to Windows and WebViews”, to create a flexible but simple to use access control system.

It allows the creation of named permission or scoping files and to re-use and combine them with other named permissions or scopes. This makes it possible to build more fine grained descriptive sets containing several simple or complex permissions and scopes.

As a plugin developer you can abstract away several base permissions into a default permission. This can be based on your default security assumptions and threat model. All official Tauri plugin default permissions are reasonably secure by default.

As an app developer you can use, extend or reduce plugin permissions. Of course you can also build permissions and scopes for your own application.

With this addition, Tauri’s core is now able to understand if a command invoke message from a frontend WebView is allowed to reach the command function. It is also able to attach the configured scope to the message.

The command implementation is responsible for interpreting and enforcing the scope. You can read more about our Threat Model and approach to security in our documentation.

External Security Audit

The major changes and architecture of v2 was independently audited by Radically Open Security during the beta and release candidate period. Please take your time to read the report and learn more about the awesome work of @gronke and @pcwizz.

The whole audit was funded by the great folks at NLNet via funding from NGI and we are super grateful to be in the privileged position to get fully funded external security audits for major releases.

The results of this audit caused us to rewrite parts of how our dev server is exposed, specifically for mobile development. Without the help and guidance of the auditors this rewrite would not have been possible ❤️.

Additionally, we hardened our iFrame API exposure, fixed scope validation and resource identifier access for the fs and http plugin, improved our inter-process communication stability, and many other security related fixes and improvements.

Inter Process Communication (IPC) Rewrite

With the rewrite of our IPC layer we now support a long wished feature of Raw Payloads and generally changed how it works under the hood.

Previously all IPC payloads were json serialized and deserialized which caused an overhead. This was noticeable once more than a few kilobytes were transfered between frontend and backend.

The new system supports Raw Requests. These speed up the transfer of large data from backend to frontend and vice versa, where you can either use raw bytes directly or use your own (de)serialization process (eg. bson, protobuf, avro and others).

For directly reading files from the filesystem into the WebView we still recommend the convertFileSrc functionality, as it is most likely still faster if you do not need to process the data on the Rust backend.

Distribution Guides

With Tauri 2.0 the distribution diversity greatly increased. Partially, due to the mobile ecosystem and partially due to our community contributions.

We have official guides on how to ship to the Apple Appstore, Google Play, Microsoft Store, CrabNebula Cloud, Flathub, Snapcraft, AUR and more distribution formats in our distribution docs.

Changelog

This section contains all changes going from 1.x in a concise list.

Migration

As we try to make the migration from previous Tauri versions as smooth as possible, we have documentation available to guide you through the process.

If you are migrating from a 1.x release please check out this migration guide.

For upgrading from a 2.0 beta or release candidate version check out this migration guide.

The Tauri v2 CLI includes a migrate command that automates most of the process and helps you finish the migration:

Call To Action

If you are familiar with Tauri and have used it already during your journey, please take your time to check out the Github Discussions, Github Issues. Maybe you have already solved the issues your fellow newcomers to Tauri are experiencing right now.

If you think that some of these problems you have seen are generic and should be documented somewhere we probably have the perfect place for it in our official documentation.

To contribute improvements or additions we are open for PRs in the tauri-docs repository. Please make sure you’ve read the guidelines for contribution though.

If you are in the position to understand and translate the current documentation into your native language we appreciate content translations to our documentation.

The repositories surrounding Tauri are also looking for contributors, especially we would love more maintainers and contributors to the plugin-workspace.

The plugins are now a major part of the development and user experience of Tauri and all kind of help is welcome there. From discussing new plugin ideas, collaborating with others to write new plugins, contributing PRs to fix bugs in existing plugins or documenting weird workarounds and knowledge in the plugin readme or code.

Roadmap

You probably expect solid plans for the future and new cool ideas from us. We currently have some in mind but have not committed to a roadmap beyond 2.x yet.

We mainly want to focus on improving this major version with a better developer experience, better documentation and less impactful bugs. We want to improve especially the mobile development experience and make the whole flow from idea to published application as seamless as possible.

Things on our radar for the future we feel we should mention at least:

• Providing or Bundling Chromium Embedded Framework (CEF) for Linux as an alternative to WebKit2GTK
• Servo as Tauri WebView (POC in Wry)

If you want to collaborate on these ideas, please let us know and we will figure it out together.

We are very proud to finally announce the first release candidate for the new major version of Tauri.

After over half a year of beta versions, following over a year of alpha versions we are finally at the point where we consider Tauri 2 stabilized and do no longer expect breaking changes.

We want to use a comparably short release candidate time frame to focus on our documentation and important bug fixes, which have been reported by our awesome community and working group members.

A simplified TL;DR can be found at the end of this post.

The Road to Stable and Beyond

With this release candidate we want to communicate our expectations and timeline for the stable release.

We have been asked countless times “Wen Tauri 2.0?” and always gave broad answers. Especially in open source projects overpromising can be a quick way to burn out developers and maintainers or lead to angry comments from disappointed adopters.

This is one of the reasons for the long alpha and beta stage and why we waited with the release candidate, as we strive to get things right and simple to use.

Another reason is that we made the mistake of overpromising this major version with “mobile as a first class citizen” and realized over the past months that we can only build the foundation for mobile on our own and need to iterate on this together with the community and our adopters to get it right.

This doesn’t mean that mobile is broken and unsupported. We have mobile plugins in our official plugin repository and have seen developers who have built cool apps on Android and iOS with Tauri.

Our partner CrabNebula also provided us with feedback on how easy (or complicated) the developer experience was when they built or supported mobile applications for customers. They even contributed multiple mobile plugins (NFC, Barcode Scanner, Biometric, Haptics, Geolocation) as part of their work.

We see improvements to be made in the development experience for mobile and we acknowledge that not all of our desktop features and plugins are ported or available on mobile yet.

This causes us to say that we don’t want to raise expectations that Tauri 2.0 will be the “mobile as a first class citizen” release but we want to make clear that you can develop production ready mobile applications with Tauri NOW.

What you can expect from stable after this release candidate is:

• Clearer and comprehensive documentation
• Less critical bugs preventing productive usage

We plan to release the stable version for 2.0 in the end of August. This will, at the time of writing, allow for a ~4 week release candidate cycle.

After the stable release our focus will be shifting to providing feature parity wherever possible and to improve the development process for mobile. This will happen in minor releases of Tauri.

Feature parity and plugin development will be aligned with major versions of Tauri but will be mostly independent from Tauri core features and happen in our plugin-workspace repository.

Developer experience is a very important topic for us. If you have improvement suggestions or want to improve the status quo on your own please do not hesitate to reach out with PRs, issues or friendly conversations on our discord server.

Breaking Changes

Before we enter the “no more breaking changes” expectation phase we discussed and planned some from our perspective necessary breaking changes a while ago.

These changes affect a lot of developers, so we wanted to bundle them and make it as painless as possible to upgrade from the latest beta to release candidate or stable.

For app developers we have breaking changes in how core plugins are referenced in the permissions.

You should be able to automatically migrate from the latest beta to release candidate. For this to succeed you must be sure to be on the latest (RC not beta) version of the Tauri CLI.

Otherwise please read the detailed section below explaining the changes and how to manually migrate.

For downstream consumers of Tauri as a library or app developers fiddling with the internals of Tauri we have a bigger refactor you should check out.

Tauri Core Plugins

With Tauri 2.0 we migrated most of the 1.x core functionality into separate plugins, which allows us to iterate on these independently of Tauri’s core and lowers the barrier for first contributors on functionality.

This migration also included keeping some functionality inside Tauri as pseudo plugins. Fully qualified plugins need to implement the Plugin Trait and need to be individual crates following the tauri-plugin-<plugin name> naming scheme. For core plugins, the second condition was not possible as we would have circular dependencies on Tauri. So we created pseudo plugins, which are always initialized by Tauri itself and only implement the plugin trait. These are for example window, path or webview. Right now these are allowed in the capabilities of your Tauri application in the following way:

...

"permissions": [


    "path:default",


    "event:default",


    "window:default",


    "app:default",


    "image:default",


    "resources:default",


    "menu:default",


    "tray:default"

]
...

This has multiple problems:

• Any plugin crate which has a colliding name will break our build process (e.g. tauri-plugin-window crate) and our cli for adding plugins (e.g. cargo tauri add window)
• We can’t use any core pseudo plugin naming that is already used by existing plugins (e.g. if we would ever want to createtauri-plugin-mobile-core and it is already used we will encounter the first problem)
• It is unclear for developers what is a core plugin and what is a dedicated plugin when looking at capabilities

Our approach is to use a fixed namespace for core plugins, which is documented and enforced by the Tauri core. All plugins starting with core: or the plugin name core are now considered core pseudo plugins and will only be initialized if they are in the Tauri codebase.

This will cause a breaking change to all capabilites enabling Tauri core features. The above example will be changed to look like this:

...

"permissions": [


    "core:path:default",


    "core:event:default",


    "core:window:default",


    "core:app:default",


    "core:image:default",


    "core:resources:default",


    "core:menu:default",


    "core:tray:default"

]
...

We also added a new special core:default permission set which will contain all default permissions of all core plugins, so you can simplify the permissions boilerplate in your capabilities config.

...

"permissions": [


    "core:default"

]
...

We consider the core default exposure to be reasonably secure and safe to enable by default, with limited impact in case of a compromised frontend.

To migrate from the latest beta version you need to prepend all core permission identifiers in your capabilities with core: or switch to the core:default permission and remove old core plugin identifiers.

Development Server for Mobile

We introduced changes to the network exposure of the built-in development server PR #10437 and PR #10456. With the changes shipped in the 2.0.0-rc.0 release of the Tauri CLI, we can connect to your development server running on localhost when targetting Android and iOS (previously this was only possible when developing a desktop application).

This means you no longer need to expose your development server on the public network.

Rust API Surface Refactor

With a coordinated effort between multiple working group members we partially changed our Rust API exposure. This affects only consumers of our Rust API and should have no breaking change impact for Tauri application developers.

This was motivated by a recent security advisory CVE-2024-35222, as the fix needed to introduce additional fields to a structure that was directly publicly exposed and caused breaking changes to some projects and internal usage.

We concluded that this overexposure will hinder us in the future and will cause unnecessary breaking changes, so we decided that going from beta to RC will be the last chance for us to implement this until we start down the road of Tauri 3.0.

We reduced the amount of publicly exposed components, which are meant for internal use. Additionally, we made our publicly exposed structures either non-exhaustive or transformed them into exposing builder patterns or constructors. In some cases we added a new extend field to allow dynamic additions in the future. Finally, we made sure to document which modules of Tauri are considered unstable.

This will help us to provide (security) fixes or changes without breaking interfaces that are considered stable.

Please take a closer look at the introduced and discussed changes in the #10158 pull request.

External Security Audit

We have been quiet on this front for some time as we have been busy fixing and discussing issues discovered during the beta versions.

We never marketed version 2 beta releases as production ready but were aware of some apps deployed into production. This caused us to announce and distribute a security patch for one of the findings (CVE-2024-35222) which was also independently discovered by a Tauri community member.

All other findings were fixed in multiple beta versions but we did not create advisories for these. We concluded a full heads up could wait until the release candidate, as the findings mainly affect the development phase or have no critical severity.

With the release candidate we will add the full report to our repository. Please take your time to read the report and learn more about the awesome work of @gronke and @pcwizz from RadicallyOpenSecurity.

The whole audit was funded by the great folks at NLNet and we are super grateful to be in the privileged position to get fully funded external security audits.

Call to Action

All of the above topics share a common theme. These would not have been possible without the continuous support of the community, our working group and other movements working towards improving the status quo.

Before we are going to release Tauri 2.0 we want to make sure that your voices are heard, your PRs are acknowledged and the documentation is helpful for YOU so that you can build the next generation of cross platform apps.

Currently we have over 30 people in our working group on Github but even more involved in our Discord. These awesome people are mostly working on Tauri in their free time with very few exceptions. We currently see a number of issues, PRs and discussions being unsolved and open for longer than we would like to.

To improve this situation we ask YOU to get involved into the Tauri project.We have all kinds of situations where we are able to accept event the tiniest contribution.

If you are familiar with Tauri and have used it already during your journey, please take your time to check out the Github Discussions, Github Issues and our Discord Support. Maybe you have already solved the issues your fellow newcomers to Tauri are experiencing right now.

If you think that some of these problems you have seen are generic and should be documented somewhere we probably have the perfect place for it in our official documentation.

To contribute improvements or additions we are open for PRs in the tauri-docs repository. Please make sure you’ve read the guidelines for contribution though.

If you are in the position to understand and translate the current documentation into your native language we appreciate content translations to our documentation.

If you have followed our project for a while but never made a contribution we would be happy to understand what has prevented you from doing so and how we could improve this. Please reach out to us in our Discord or in our Github Discussions.

Too Long Didn’t Read

• Tauri 2.0 Release Candidate out now!
• Some migration from beta is needed. Check out tauri migrate.
• External Security Audit for 2.0 is available here
• All findings are fixed and fixes were verified
• Documentation is our focus until stable release
• Tauri is looking for more contributors and community involvement

The Tauri team is happy to announce the 1.7 release. This version includes several bug fixes, performance improvements and features backported from the upcoming v2 release.

Upgrading

Make sure to update both NPM and Cargo dependencies to the 1.7.0 release. You can update the dependencies with:

What’s in 1.7.0

Shell API performance improvement

The shell’s Command::execute API has been optimized to only use the IPC a single time instead of streaming data, improving usage of verbose shell scripts.

Feature backport from v2

Thanks to community effort we have backported a few bundler features from v2 into the v1 release.

Custom Windows codesign script

By default the Windows packaging uses SignTool, which only works on Windows so it’s not useful when cross compiling. In this release we have backported the custom sign command feature, which allows using osslsigncode, relic and other alternatives that can run on Unix systems and support hardware tokens, Azure Key Vault and more.

RPM bundle

RPM packaging have been available to Tauri v2 users for a while, and it is now also available on the v1 channel.

DMG configuration

DMG installers are now configurable: you can change the position of the icons and the window size to fit better within a custom background.

Other changes

Check out the entire list of changes:

• tauri
• tauri-cli
• tauri-bundler

The Tauri Programme is celebrating its third anniversary of Tauri becoming a programme within The Commons Conservancy. We are hard at work bringing v2 to a stable release, and now the next round of Tauri Board Director elections is upon us! Want to get involved in other ways and help Tauri towards v2? We would love your contributions especially to help evolve the documentation!

Board Elections

The Tauri Board of Directors is the central decision-making body for the Tauri Programme and is responsible for its overall health and stability. Additional details can be found on the Tauri Governance page.

In order to provide continuity from one year to another, the elections of seats are staggered over the course of 2 years. This means that one year a portion of the seats are elected, and the following year the remaining seats are elected. A Tauri Director seat is an elected position with a term of 2 years. The Board has a minimum of 3 Directors and a maximum of 7. This year there are 2 seats open for election.

Applying for Candidacy

There are 3 steps to express interest and apply for candidacy:

1. Learn about the role of a Tauri Board Director on the Governance page.
2. Prepare a written introduction about yourself that covers who you are, your history and relevance for Tauri, and what you would like to bring to the Board.
3. Apply prior to July 5th, 2024 by emailing board@tauri.app, messaging the @board role on the Tauri Discord, or by directly messaging Jacob Bolda on Discord (@jacobbolda) or email (jacob@tauri.app).

Voting will take place starting on July 7th through July 12th, 2024 where Tauri Working Group Members will cast their votes. We’re expecting to announce the results on or before July 16, 2024. If elected, we’ll ask you to sign this pledge if you haven’t done so previously.

If you have any questions or would like more information please reach out by emailing board@tauri.app, messaging the @board role on the Tauri Discord, or by directly messaging Jacob Bolda on Discord (@jacobbolda) or email (jacob@tauri.app).

Interested In Getting Involved?

If joining the Board isn’t for you, we are always looking to enable involvement at any level within Tauri. The documentation for v2 is a large focus of the remaining effort. See the issues within the tauri-apps/tauri-docs repo. Additionally reach out and follow along within Discord. Add a @notify-* role to stay apprised of news and questions from the team, or follow along and ask questions in the #dev or #docs channels under the CONTRIBUTORS section.

Prepared for some more responsibility? A Domain in the Working Group represents a specific area of interest.

• Development: Developing and maintaining the Tauri software
• Community: Looks after the broader community resources and the public presence of Tauri
• Governance & Guidance: Involved with all things organizational in nature
• Operations: Responsible for all the tooling and infrastructure Tauri needs to get work done

This gives clear entry points for a new member of the Working Group to jump into right away. It also allows us to continue growing our core competency of core Tauri development while giving additional focus to all areas which support the Tauri organization as a whole. Each of these domains will be represented by Domain Members and Domain Leads, but membership is not mutually exclusive.

All domains within Tauri are equally important to providing the best experience possible, as well as the wonderful support of the community. ❤️

With your help, we can continue to improve and catalyze the growth and sustainability of the organization. You can learn more in the Governance and Guidance repo on GitHub.

The Rust Security Response WG announced CVE-2024-24576, which affects the Rust Standard Library on Windows.

TL;DR: Upgrade your Rust version to 1.77.2.

How Does it Affect Tauri as a Library?

Some Tauri organization repositories use batch files (cmd.exe under the hood) for developer environment tooling such as build scripts. No reviewed repositories use batch files for runtime code.

We don’t see additional risks for the Tauri project based on this CVE.

Nevertheless, we will update our CI systems to use the latest Rust version.

Is My Tauri App Affected?

In general you are possibly affected if you fulfil all of the below criteria:

• You ship your app on Windows
• Your project enables the Tauri v1 shell feature with "execute": true or the v2 shell-plugin with allow-execute permission
• You allow arguments in the scope element of the shell feature
• You pass untrusted input to cmd.exe or .bat/.cmd files and improperly validate the scope (🚩)

If any of these criteria are not fulfilled in your application you are likely NOT affected.

If you implement custom commands or logic written in your application that directly exposes the Rust Command with arguments provided at runtime, you may be affected. While not Tauri specific, this pattern could affect any Rust project.

Conclusion

Please upgrade your Rust version to 1.77.2 as soon as possible and distribute updates to your users.

This investigation and writeup was performed in cooperation with our partner CrabNebula ❤️.

Read more about this security advisory here. This affects many programming languages, this specific CVE is just the one filed for Rust.

The Tauri team is happy to announce the 1.6 release. This version includes several new features and important bug fixes such as improved code signing on macOS, updater enhancements and an event loop crash on all platforms.

Upgrading

Make sure to update both NPM and Cargo dependencies to the 1.6.0 release. You can update the dependencies with:

What’s in 1.6.0

Event loop crash

We finally got a good stack trace and got a fix for a long standing crash on all platforms. This crash was a challenge to fix since it only happened when the application is running for a long time, so we thank everyone that made sure the fix works.

Code signing improvements

Tauri now detects nested dylib, app, xpc and frameworks inside your macOS app bundle and codesigns each of them. This ensures your app can use some external libraries and be codesigned and notarized.

Updater enhancement

The auto updater now keeps the command line arguments on Windows.

Other changes

Check out the entire list of changes:

• tauri
• tauri-cli
• tauri-bundler

Tauri v2 has been in progress for over a year and it is now ready to take the next step towards being stable! We have just released Tauri v2.0.0-beta.0 which represents a major milestone from our roadmap.

The v2 release introduces mobile support to Tauri and also comes with several new features that have been requested by the community. Let’s get a high level overview of the major changes:

Mobile

Developing an application for desktop and mobile has never been easier. Tauri v2 is a huge statement on cross platform development now that we support Android and iOS. You can bring your existing desktop implementation and seamlessly port it to mobile, with access to native APIs and the great developer experience of the Tauri CLI.

Permissions

The v1 allowlist is a good tool for securing your frontend from accessing unnecessary APIs, but its configuration is not fine grained and it lacks multiwindow support. The 2.0.0-beta.0 release includes a new approach for command access based on Access Control List. It is now possible to allow commands and define scopes for specific windows or even remote URLs.

New Features

v2 includes many of the most requested features by the Tauri community:

Revamped IPC

The v1 Inter-Process Communication (IPC) which is responsible for delivering messages between the Rust and JavaScript layers uses a very rudimentary webview interface which forces us to serialize all messages to strings and is super slow to deliver responses. The new v2 IPC uses custom protocols, which is more reminiscent in function and performance to how the webview handles regular HTTP based communication, see the pull request for more information.

Additionally, there is a new channel API so you can quickly send data from Rust to your frontend.

Multiwebview

Tauri now supports adding multiple webviews to a single window. This is also a highly anticipated feature request. Note this is still an unfinished feature that is hidden behind an unstable Cargo feature flag while we review the API design together with the community.

Menu and tray icon JavaScript APIs

Previously you could only configure window menus and tray icons via Rust code. Now you can do so on the JavaScript side too, which is a lot easier! We also added APIs to manage the macOS application menu specifically.

Context Menus

One of the most requested features is native context menus. It is finally available with both Rust and JavaScript APIs powered by muda.

Window APIs

Several new window APIs have been implemented, making your app much more configurable.

Mobile APIs

The v2 release comes with some mobile native API support by default. Currently there is support for notifications, dialogs, NFC, barcode reading, biometric authentication, clipboard and deep link. More APIs will be added soon after the stable release.

Audit

We are currently being audited to ensure v2 is safe, similar to what we did for the v1 stable release.

Stability

The API is not stable yet, but no major changes are expected. As soon as the audit is completed and the changes are done, we will promote to a Release Candidate and a v2 stable release soon after that. Stay tuned!

As an open-source project, Tauri’s primary mission has always been to provide a secure, efficient framework for multi-platform application development. Understanding the concerns and needs of our community, we are excited to share insights into our partnership with CrabNebula and how it bolsters the stability and future of Tauri.

CrabNebula’s Contribution to Stability and Security

CrabNebula’s role in Tauri’s journey over the past year has been pivotal. By dedicating full-time engineers to work explicitly on Tauri’s development and maintenance, they are helping us enhance the framework’s stability and security. They are literally being paid to resolve bugs and issues, pushing forward on the 2.0 release, and offering their support in the many Discord discussions.

Specifically, we would like to call out some folks from CrabNebula for helping drive the community and the code forward: Daniel, Lucas, Elizabeth, Yu-Wei, Tillmann, Amr, Chip, Fabian-Lars, Alve, Atila, Eleftheria, Tejas, Lorenzo, Robin, David, Jason, and Te-Kai.

Their efforts in conducting thorough security audits of minor releases are particularly crucial. These audits not only help us identify and fix vulnerabilities but also reinforce our commitment to delivering a secure framework for all users. Collaborative features developed with Impierce and Kino AI under this partnership further expand Tauri’s capabilities, which will help it to remain cutting-edge and reliable.

A Partnership Model Focused on Open Source Values

Our collaboration with CrabNebula is grounded in open-source principles. It’s designed not just for mutual benefit but to serve as a sustainable model for future collaborations. We understand the importance of maintaining the integrity and independence of Tauri as an open-source project. This partnership respects these values, ensuring that Tauri continues to be driven by community needs and open-source innovation.

Long-Term Impact on the Tauri Ecosystem

The partnership is more than just a short-term alliance; it’s a strategic move to secure the long-term future of Tauri. By bringing additional resources and diverse perspectives, we’re enhancing the framework’s robustness. Importantly, involvement of companies using Tauri, facilitated by this partnership, gets cycled directly into the development process. This feedback loop is vital for addressing real-world usage challenges, because it is important to all of us that Tauri remains relevant and continues to evolve according to the needs of its users.

Creating Channels for Community Engagement

In line with our commitment to community engagement, we will be launching a #crabnebula channel on Tauri’s Discord. This will be a dedicated space for direct communication, collaboration, and feedback. We want to make sure that our community’s voice is heard and integrated into the ongoing development of Tauri.

Call to Action

To our developers, contributors, users, and donors - we invite you to engage with us on this journey. Your input is invaluable as we continue to develop Tauri in partnership with CrabNebula. Together, we are not just building a framework; we are seeking ways to enhance its longevity and relevance in the ever-changing world of technology.

If you like, go over to the CrabNebula blog and read their perspective on this partnership.

• Discord Tauri
• X Tauri
• Mastadon Tauri
• GitHub Tauri
• Website Tauri
• X CrabNebula
• Mastadon CrabNebula
• GitHub CrabNebula
• Website Crabnebula

The Tauri team is excited to announce the 1.5 release. This version includes several new features and important bug fixes such as improved resources bundling, code signing enhancements, notarytool migration on macOS and Bun support.

Upgrading

Make sure to update both NPM and Cargo dependencies to the 1.5.0 release. You can update the dependencies with:

What’s in 1.5.0

Notarytool

At WWDC 2021 Apple introduced notarytool, a new tool for interacting with the Apple notary service. Before the 1.5 release, Tauri used altool to notarize your application, but that tool has been deprecated and will stop working for notarization on 2023-11-01. You must upgrade your Tauri CLI to 1.5 before that.

If you are using API keys for authentication with the notary service, notarytool no longer automatically searches for your APi key .p8 file. We recommend users to define its path via the APPLE_API_KEY_PATH environment variable, though to avoid breaking changes we perform the same lookup done by altool to find your key file in case you did not set the environment variable. In the future, this might change, so please adjust your publish pipelines accordingly.

Bun support

The Tauri CLI now supports the Bun package manager.

We would like to thank @colinhacks for submitting the pull requests for this feature!

Code signing improvements

Starting on Tauri 1.5, our bundler now signs all executables (including sidecars, app executables and NSIS uninstaller) and macOS frameworks. We also improved our notarization algorithm adding support to the APPLE_TEAM_ID environment variable to properly define the team ID associated with your account in case you belong to multiple teams.

We would like to thank @tr3ysmith for submitting the pull requests for this feature!

macOS frameworks

This release comes with enhanced macOS frameworks support by code signing all custom frameworks you inject via tauri.conf.json > tauri > bundle > macOS > frameworks and defining the @rpath value fixing a crash when updating your app.

We would like to thank @tr3ysmith for submitting the pull requests for this feature!

Mixed content on Windows

We now offer a configuration option to switch our custom protocol on Windows to use the http scheme instead of https. This reduces the security of your application on Windows since it allows connecting to insecure endpoints such as ws://url, but it matches the behavior on Linux and macOS custom protocols. To enable it, set the tauri.conf.json > tauri > security > dangerousUseHttpScheme to true.

Other changes

Check out the entire list of changes:

• tauri
• tauri-cli
• tauri-bundler

Tauri 1.0 was released in June 2022 and introduced an app toolkit for developers to build apps using HTML, CSS, and JavaScript with the security and performance of Rust. Tauri has been pivotal in redefining and asking the question: “What is an app?”

Version 1.0 launched with support for Linux, macOS, and Windows and has been updated with new features, DX improvements, and bug fixes to bring us to Tauri 1.4 that is available now.

But there’s one question the Tauri Working Group gets asked time and time again. We affectionately refer to it as “Mobile when?!?” and today we’d like to outline the path ahead of us to get to Tauri 2.0 and to answer that question.

What is Tauri 2.0?

In essence, the 2.0 release of Tauri is The Mobile Update. But 2.0 is so much more than just mobile. Here are a few of the features that will be included:

• Powerful Plugins: Many of the Tauri APIs have been shifted to use the Tauri plugin system. This allows us to make Tauri code more modular, more maintainable, but also enables us to make the plugin system more powerful for developers to build their own plugins.
• Swift and Kotlin Bindings for Plugins: Now you can write platform-specific code in Swift and Kotlin. Tauri has offered a bridge between Rust and JavaScript code since version 1.0. With Tauri 2.0, plugin developers will be able to write code in Swift and Kotlin to integrate more closely with the systems they’re developing for.
• Support for iOS and Android: You’ll be able to build Tauri apps and run them on iOS and Android.

We’ve already seen developers doing amazing things with the prerelease version of Tauri 2.0 and we’re excited to move forward to a stable version to get it in the hands of everyone.

Path to Tauri 2.0 Stable

Right now, we are in the 2.0 alpha phase. Here are the 3 key milestones to get us to Tauri 2.0 stable:

1. Beta
2. Release Candidate
3. Stable

Below are the steps within each of those milestones that the Tauri Working Group are driving towards.

Beta

To enter a beta phase Tauri 2.0 must be feature-complete and working with no known major issues. This means that the Tauri Working Group are satisfied with the public Tauri APIs and don’t anticipate any breaking changes (although they are possible as we receive community feedback).

Once we’ve entered beta then we will lock down the code base and move onto an auditing phase. No new features will be targeted for Tauri 2.0 after this point.

Security is very important to Tauri. We work with external auditors to review Tauri code so that it can be as secure as possible for Tauri developers and their users. A similar approach was taken with Tauri 1.0 in collaboration with Radically Open Security (Tauri 1.0 Security Audit Report).

More details on the security audit for 2.0 are to come in the future.

Release Candidate

Once all of the audit findings are resolved then we will move on to the release candidate phase. This is where we’ll ask the Tauri community to give it a test drive, see if there are any bugs, and to provide feedback in preparation for the stable release.

The RC phase will be time-locked so that early adopters can help us discover pain points and low-hanging fruit that can be resolved quickly. This will also include a documentation sprint in order to align what we know with what we show. More details on this will be shared as we get get closer to the release candidate phase.

Stable

Tauri 2.0 will be released and generally available for everyone to build amazing things with. We will also continue fixing bugs and releasing updates in line with our current approach of publishing patches and minor updates.

Where We Are

There are a lot of moving parts in moving towards a stable release. The two main parts are the findings and fixes from the security audit alongside the feedback and adjustments from the community. These two pieces are incredibly important and we want to be sure we can prioritize those without sacrificing the security and quality of Tauri.

Because of those priorities we don’t yet have hard timelines for a Tauri 2.0 stable release. We have internal targets that we’re aiming for to keep us on track, but we want to be sure that we’re flexible to accommodate feedback.

What we can share right now is that we’re roughly targeting the stable release of Tauri 2.0 in early 2024. We’re driving sharply ahead to enter the beta phase as soon as possible.

As we make progress towards Tauri 2.0 we’ll be sure to share updates to the community. The primary way to keep up to date is to watch for the Tauri releases as they move through the beta, release candidate, and lastly stable phases. You can also keep an eye on Twitter, Mastodon, and Discord.

Getting Involved

While we’re working towards Tauri 2.0 stable there are a lot of ways for the community to get involved. The more involvement and feedback we have, the better Tauri 2.0 will be for everyone. Here are just a few ways to get involved:

• Test prerelease versions of Tauri and give feedback via Discord and GitHub issues.
• Contribute to documentation and translations on https://v2.tauri.app.
• Help in the Tauri community by supporting others in Discord and GitHub issues and giving feedback for major issues that arise.
• Begin planning content around Tauri 2.0 (although we recommend waiting until at least 2.0 beta). Reach out to the Tauri Working Group on Discord if you would like to collaborate on content ideas such as videos, blogs, courses, or anything else.

We hope this provides a bit of transparency about where we’re at, where we’re headed, and what you can do to help us get there. Give us your feedback by joining us on Discord and joining the GitHub Discussion for this post. Happy building!

The Tauri Programme is celebrating it’s two year anniversary of Tauri becoming a programme within The Commons Conservancy as well as the one year milestone of the Tauri 1.0 release. This also means we’re preparing for the next round of Tauri Board Director elections to welcome in the next chapter of Tauri.

We wanted to celebrate these milestones but also use this as a chance to reflect on how we’ve grown since the Tauri 1.0 launch and how to continue evolving Tauri. The Tauri Working Group has been building the next iteration of the governance model for the past several months to make it more accessible for new and existing contributors, and ultimately sustainable for the future of Tauri.

Board Elections

The Tauri Board of Directors is the central decision-making body for the Tauri Programme and is responsible for the overall health and stability of the Tauri Programme. Additional details can be found on the Tauri Governance page.

In order to provide continuity from one year to another, the elections of seats are staggered over the course of 2 years. This means that one year a portion of the seats are elected, and the following year the remaining seats are elected. A Tauri Director seat is an elected position with a term of 2 years. The Board has a minimum of 3 Directors and a maximum of 7. This year there are 5 seats open for election.

Diversity

This year we’d like to focus on diversifying the Tauri Board. We’re looking for candidates that may be a developer who’s worked on Tauri, a stakeholder in Tauri’s future, experienced individuals from industry, or a person with a passion for regulatory and legal aspects within open source. If any or all of these are of interest to you then we’d invite you to apply as a candidate.

Applying for Candidacy

There are 3 steps to express interest and apply for candidacy:

1. Learn about the role of a Tauri Board Director on the Governance page.
2. Prepare a written introduction about yourself that covers who you are, your history and relevance for Tauri, and what you would like to bring to the Board.
3. Apply prior to July 2nd, 2023 by emailing board@tauri.app, messaging the @board role on the Tauri Discord, or by directly messaging Daniel Thompson-Yvetot on Discord (@Denjell) or email (denjell@tauri.app).

Voting will take place starting on July 5th through July 12th, 2023 where Tauri Working Group Members will cast their votes. We’re expecting to announce the results on or before July 16, 2023. If elected, we’ll ask you to sign this pledge if you haven’t done so previously.

If you have any questions or would like more information please reach out by emailing board@tauri.app, messaging the @board role on the Tauri Discord, or by directly messaging Daniel Thompson-Yvetot on Discord (@Denjell) or email (denjell@tauri.app).

Governance Update

Tauri has always had a Working Group that’s responsible for the day-to-day direction and execution, but as we grew it became clear that we needed to evolve the Working Group. We also wanted to give new Working Group members a clear places to jump in and get started. We thought of how we could achieve this while building and iterating on the existing framework. With these goals in mind, we created two new concepts within the Working Group: Domains and Domain Leads.

Domains

A Domain in the Working Group represents a specific area of interest. We’re starting with these 4 domains:

• Development: Developing and maintaining the Tauri software
• Community: Looks after the broader community resources and the public presence of Tauri
• Governance & Guidance: Involved with all things organizational in nature
• Operations: Responsible for all the tooling and infrastructure Tauri needs to get work done

This gives clear entry points for a new member of the Working Group to jump into right away. It also allows us to continue growing our core competency of core Tauri development while giving additional focus to all areas which support the Tauri organization as a whole. Each of these domains will be represented by Domain Members and Domain Leads, but membership is not mutually exclusive.

Domain Leads

Within a domain, there is a position for 2-3 Domain Leads. These are core individuals in the Working Group that are critical to their respective Domain. They help by setting the direction and priorities for their domain while also serving as key leaders for the Working Group as a whole.

Leads are appointed twice a year, in the spring and in the fall. Since this governance update is being rolled out mid-term we’re appointing interim leads that have been key members of the Working Group. This fall we’ll reflect on the initial experience and host a new round to appoint the Domain Leads. We’ll announce information for that process when we’re closer to “appointment season”.

We hope that these changes provide the foundation to continue the journey the Tauri Working Group has been on while also catalyzing the continued growth and sustainability of the organization. You can learn more about these updates in the Governance and Guidance repo on GitHub. Give us your feedback on the GitHub Discussion for this post.

The Tauri team is excited to announce the 1.4 release. This version includes several new features and important bug fixes such as CLI completions, unit testing capabilities and Windows installer improvements.

Upgrading

Make sure to update both NPM and Cargo dependencies to the 1.4.0 release. You can update the dependencies with:

What’s in 1.4.0

CLI completions

The Tauri CLI now can generate shell completions for Bash, Zsh, PowerShell and Fish. See the documentation for more information.

Disabling window controls

The window’s maximize, minimize and close buttons now can be disabled via configuration or API calls. Check out set_maximizable, set_minimizable and set_closable for the Rust APIs and setMaximizable, setMinimizable and setClosable for the JavaScript APIs.

NSIS improvements

The 1.4.0 release includes several NSIS bundle enhancements:

• Custom language files
• Custom installer template (.nsi file)
• Support for the dutch, japanese, korean, persian, swedish and turkish languages
• If your application is installed via WiX, the installer will prompt the user to uninstall it
• Improved support to updater install modes

See the installer customization guide and installer internationalization for more information.

MSRV change

Tauri 1.4 still has a minimum supported Rust version of 1.60, but due to some dependency incompatibility issues we are no longer pinning the patch version of the time, ignore, and winnow crates. If you are still using Rust 1.60, you will need to pin these versions manually with cargo update.

Unit tests

The tauri crate now exposes the test module under the test Cargo feature. This module is still unstable but allows you to unit test your application by creating a tauri::App instance that can execute without spawning windows. See the documentation for more information and examples.

Other changes

Starting on v1.4.0, our changelog format has been improved. Check out the entire list of changes:

• tauri
• tauri-cli
• tauri-bundler

Audit

The internal¹ audit was performed by Tillmann @tillmann-crabnebula and Chip @chip-crabnebula, who are also involved in security topics at the project under their private handles (@tweidinger and @chippers).

It was performed during paid time at CrabNebula Ltd. and we are grateful to be able to spend parts of our work time contributing to the open source project and making it a more secure environment :heart:.

For this release we manually audited a selection of PRs instead of all PRs coming into the release. The new approach means the reviewers and developers need to decide on their own if a PR is introducing any security relevant change. A review can be triggered by anyone involved in the change, by adding a label to the PR.

For the first time we also audited after the official release due to time constraints. This resulted in a security patch release, fixing the only impactful issue (CVE-2023-34460) discovered during auditing. In general this release was more focused on fixing and improving the NSIS features and introduced less new features and security relevant changes.

The Tauri team is excited to announce the 1.3 release. This version includes security improvements, new features and important bug fixes.

Upgrading

Make sure to update both NPM and Cargo dependencies to the 1.3.0 release. You can update the dependencies with:

What’s in 1.3.0

NSIS

The Tauri CLI can now create Windows application installers using NSIS. This new bundle target is also available on macOS and Linux as an experimental feature, so you can cross-compile your Windows installer. Documentation on the latter will be published soon.

Tauri 1.3 Audit

The internal audit was performed by @tweidinger and @chippers, who are involved in most security topics at the Tauri project. It was performed during paid time at CrabNebula and we are grateful to be able to spend parts of our work time contributing to the open source project and making it a more secure environment :heart:.

We manually audited over 45 PRs. Some PRs (e.g. #5544) lead us to diving into very old RFCs (RFC6068 and RFC3966), NSIS documentation (e.g. #6039) and many other external resources. We documented questions, notes and findings in markdown files and shared these notes with the responsible developers to ensure appropriate fixes.

The changes from a security perspective and findings of the audit are summarized in the following sub-sections.

External API Access #5918

This was by far the most impactful and time consuming PR we investigated. This PR introduces a streamlined way for applications to allow external domains access to the Tauri IPC layer¹ and usage majorly impacts the security model of a Tauri application. Security impact² depends on exposure³ of the feature, enabled Tauri commands and the capabilities of an adversary⁴.

We consider this new feature similar to driving a very fast race car without any safety features enabled and urge developers to very very carefully consider if they really need this exposure.

Before this addition was merged, a semi-known vulnerability was (ab)used by application developers to achieve the same functionality. To make the whole community aware of this risk we published a security advisory to give a heads up. Applications are affected if they allow users to navigate to arbitrary domains or have an open redirect vulnerability⁵. If you implement such a feature you should update to the 1.3 release as fast as possible.

The initial PR changes allowed wildcards (https://*) and glob patterns, which we believe are helpful but shouldn’t be exposed to all Tauri developers. We concluded that the risk of over-exposure, like the allow list toggle to enable all Tauri API endpoints, does not justify this permissive exposure. The final implementation allows to configure specified (sub)domains⁶ (eg: example.com) to gain remote access to the Tauri IPC.

The few edge use cases, which require wildcards or even further exposure can be implemented by custom Rust code which is able to dynamically modify the IPC access. We now expose this remote IPC scope in a similar fashion as the fs or http scope.

Assuming a fully trusted web service on https://trusted.example it is now possible to configure the security scope to allow certain windows or even plugins access to custom implemented commands and optionally the inbuilt Tauri API:

"security": {


  "dangerousRemoteUrlIpcAccess": [


    {


      "windows": ["main", "settings"],


      "domain": "trusted.example",


      "plugins": ["trusted-plugin"],


      "enableTauriAPI": false


    },


  ],

}

Shared domains MUST NOT be used for this in any circumstances. We do not limit access to paths or specific files. You can only scope with trusted (sub)domains⁶. Another very risky catch is that developers must be sure that the domain ownership does not change over the lifetime of the application. Domain takeover could lead to compromised user devices.

Browser Arguments #5799

Due to certain webview features not enabled nor being accessible, a community contribution introduced the possibility to add additional arguments to the webview process, which is created in a new window.

This feature was exposed to the frontend in the window endpoint. We found that this exposure was highly risky, as most webviews have very impactful features and flags that can be allowed via the process arguments.

All of the following threat model assumptions are based on the Tauri window creation being allowed in the allowlist of the tauri.conf and therefore exposed to the frontend. This PR affects Windows only, therefore there is no impact on the other supported operating systems.

An adversary with the capabilities to create windows and pass command line arguments to the webview can elevate their privileges to escape the strict sandboxing of Tauri and the webview.

The flags allow to enable several dangerous webview features, from loading profiles outside of the current default profile folder (stealing browser sessions from the device) to disabling security measurements of the webview (eg: certificate validation, sandboxing, webdriver/headless mode, device management endpoints, …).

We found an old but gold and still unique documentation reference at https://peter.sh/experiments/chromium-command-line-switches/, which helped us understand possible risks on Windows, as the Webview2 uses the same flags.

The feature was then changed to be only exposed on the rust side. Tauri application developers can use this to implement custom commands to invoke webview windows with use case specific arguments.

Possible ZipSlip #4674

We found that the components to extract remote bundler files like the Webview2 installer were manually extracting single files with the extract_zip function, which uses ZipFile::name() instead of ZipFile::enclosed_name() as recommended in the documentation. Files which had names like ../../../../foo.sh could be extracted outside of the intended directory on the filesystem. This kind of vulnerability is called ZipSlip.

As the function was only used on verified and trusted files the impact here was nearly zero. Regardless we changed the implementation to facilitate the proper extraction method.

Bundler Hardening #6039

The bundler was not escaping content passed to the handlebars::Handlebars::render(), which could cause unwanted code execution during the bundler phase. This was also a low impact issue but was promptly fixed.

Other changes

New

• additional_browser_args option when creating windows #5799
• Add is_minimized() window method. #5618
• Add title getter on window. #5515
• content protection APIs #5513
• Added Builder::device_event_filter and App::set_device_event_filter methods. #5562
• Add WindowsAttributes::app_manifest to specify the application manifest on Windows. #5730
• Add support for Cargo’s workspace inheritance. #5775 #6144
• Added window’s url() getter. #5914
• Added Window::on_navigation. #5686
• Allow setting the text of the dialog buttons. #4383
• Implement SystemTray::with_tooltip and SystemTrayHandle::set_tooltip for Windows and macOS. #5938
• Add dylib support to tauri.bundle.macOS.frameworks. #5732

Enhancements

• On Windows, the msi installer’s Launch App checkbox will be checked by default. #5871
• Add --png option for the icon command to generate custom icon sizes. #5246
• On Windows, change webview theme based on Window theme for more accurate prefers-color-scheme support. #5874
• Remove default features from Cargo.toml template. #6074
• Add a method to the WindowBuilder struct to recreate windows from tauri.conf.json configurations.#6073
• Improve the error message when rustc couldn’t be found. #6021
• Added support for pre-release identifiers and build numbers for the .msi bundle target. Only one of each can be used and it must be numeric only. The version must still be semver compatible according to https://semver.org/. #6096
• Add --ci flag and respect the CI environment variable on the signer generate command. In this case the default password will be an empty string and the CLI will not prompt for a value. #6097
• Skip the password prompt on the build command when TAURI_KEY_PASSWORD environment variable is empty and the --ci argument is provided or the CI environment variable is set. d4f89af18d69fd95a4d8a1ede8442547c6a6d0ee

Fixes

• Fix tauri info panicking when parsing crates version on a newly created project without a Cargo.lock file. #5873
• Fix building apps with unicode characters in their productName. #5872
• Sync __TAURI_METADATA__.__windows across all windows. #5615
• Fix resize glitch when double clicking a custom titlebar in the top resize area. #5966
• Disable cursor mouse events on Linux. #6025
• Fix serialization of js Map when used in invoke. #6099

A new alpha release for the 2.0 has been published. This release includes all changes from the upcoming Tauri 1.3 release, an important breaking change on the HTTP client and native mobile capabilities for Tauri plugins.

Updating dependencies

Make sure to update both NPM and Cargo dependencies to the latest alpha release. You can update the NPM dependencies with:

Recreate the mobile projects to use the new features:

rm -r src-tauri/gen


tauri android init


tauri ios init

HTTP Client Breaking Change

The default HTTP client using attohttpc has been removed due to issues with the development server proxy on Windows. All reqwest-* feature flags have been removed because reqwest is now the client we use.

Native Mobile Functionality for Tauri Plugins

A Tauri plugin now can access iOS via Swift and Android APIs via Kotlin or Java code, simplifying usage of platform interfaces such as camera or geolocation. To bootstrap the iOS and Android projects on an existing plugin, run tauri plugin ios add and tauri plugin android add. New plugins automatically include all the configuration needed to write native mobile code.

Here’s an example of a plugin that takes a string value and resolves an object:

Android plugin:

package com.plugin.example




import android.app.Activity


import app.tauri.annotation.Command


import app.tauri.annotation.TauriPlugin


import app.tauri.plugin.JSObject


import app.tauri.plugin.Plugin


import app.tauri.plugin.Invoke



@TauriPlugin

class ExamplePlugin(private val activity: Activity): Plugin(activity) {


    @Command


    fun ping(invoke: Invoke) {


        val value = invoke.getString("value") ?: ""


        val ret = JSObject()


        ret.put("value", value)


        invoke.resolve(ret)


    }

}

iOS plugin:

import UIKit


import WebKit


import Tauri




class ExamplePlugin: Plugin {


  @objc public func ping(_ invoke: Invoke) throws {


    let value = invoke.getString("value")


    invoke.resolve(["value": value as Any])


  }

}



@_cdecl("init_plugin_example")


func initPlugin(name: SRString, webview: WKWebView?) {


  Tauri.registerPlugin(webview: webview, name: name.toString(), plugin: ExamplePlugin())

}

Rust code to initialize the plugin:

use tauri::{


  plugin::{Builder, TauriPlugin},


  Manager, Runtime,

};



#[cfg(target_os = "ios")]


tauri::ios_plugin_binding!(init_plugin_example);




pub fn init<R: Runtime>() -> TauriPlugin<R> {


  Builder::new("example")


    .setup(|app, api| {


      #[cfg(target_os = "android")]


      api.register_android_plugin("com.plugin.example", "ExamplePlugin")?;


      #[cfg(target_os = "ios")]


      api.register_ios_plugin(init_plugin_example)?;


      Ok(())


    })


    .build()

}

A new major version of create-tauri-app has been released. This version adds support for the alpha version of Tauri 2.0, the ability to initialize iOS and Android projects and removes some less commonly used templates to make the project more maintainable.

Tauri 2.0 Alpha & Mobile Support

The first alpha version of Tauri 2.0 was published almost 3 months ago which brought initial mobile support for Android and iOS. Previously there wasn’t an easy way to create a new project to test either the changes in the alpha version nor the mobile support. Well, that ends now!

Starting with version 3 of create-tauri-app, you can now pass --beta flag and it will bootstrap an app that uses tauri@2.0.0-beta. When adding the --beta flag it will automatically prompt you if you’d like to add mobile support. You can also use the --mobile flag to automatically make it mobile compatible.

To get started:

# pnpm

pnpm create tauri-app --alpha



# yarn

yarn create tauri-app --alpha



# npm

npm create tauri-app -- --alpha



# Cargo

cargo install create-tauri-app --locked


cargo create-tauri-app --alpha



# Bash

sh <(curl https://create.tauri.app/sh) --alpha



# Powershell

$env:CTA_ARGS="--alpha";iwr -useb https://create.tauri.app/ps | iex

Prompt Improvements

With version 2 of create-tauri-app we also focused on improving the flow and experience of the prompted questions.

Previously the second prompt would ask “Choose your package manager”. This was a bit vague and could leave some with unanswered questions:

• What is cargo?
• Is it a new Node.js package manager?
• Why choose it over pnpm or yarn?

This would be even more vague if we decided to add a new frontend language (such as a webassembly Golang web application). We added a prompt asking to choose the package manager to ask which language would you prefer. It looks something like this:

? Choose which language to use for your frontend ›

  Rust

❯ TypeScript / JavaScript  (pnpm, yarn, npm)

After choosing the frontend language create-tauri-app will then prompt for package manager to use if the language has multiple (such as Node.js with npm, yarn, and pnpm).

Another prompt that we felt problematic was the template selection prompt. It contained a lot of templates to choose from and was only growing with time:

✔ Choose your package manager · pnpm
? Choose your UI template ›

  vanilla


  vanilla-ts


  vue

❯ vue-ts

  svelte


  svelte-ts


  react


  react-ts


  solid


  solid-ts


  next


  next-ts


  preact


  preact-ts


  angular


  clojurescript


  svelte-kit


  svelte-kit-ts

We decided to split this up into 2 prompts. The first will ask which UI template to use:

✔ Choose your package manager · pnpm
? Choose your UI template ›

  Vanilla

❯ Vue

  Svelte


  React


  Solid


  Angular


  Next


  SvelteKit


  ClojureScript


  Preact

And then the second will then ask any additional choices that are specific to that template (such as choosing between TypeScript or JavaScript for Vue):

✔ Choose your package manager · pnpm
✔ Choose your UI template · Vue - (https://vuejs.org)
? Choose your UI flavor ›
❯ TypeScript

  JavaScript

Even with these refinements the list of templates was still quite large and would only grow over time. The next thing to look at was the list of templates themselves.

Removing Templates

When create-tauri-app version 2 was launched it quickly received PRs to add additional templates beyond what it originally launched with. While it was exciting to receive so much support from the community, it did bring up a couple of new challenges:

• It made it almost impossible to fit them in a single prompt
• Maintaining all the templates was becoming more difficult

It was a hard balance between showing how flexible Tauri is but also making sure that the project was maintainable and had the DX that we wanted.

We decided to focus on the most popular frontend frameworks and used guidance from community surveys like The State of JS and our own Tauri community feedback. With this we removed the next, next-ts, preact, preact-ts, clojurescript, svelte-kit and svelte-kit-ts templates and also closed PRs which aimed to add more templates.

Community-Maintained Templates & Previous Versions

We want to make sure that we offer a place for the Tauri community to provide their own templates for the frameworks they love. The templates section of awesome-tauri is just the place for that. We invite the community to submit a PR to the awesome-tauri repo with their templates so that they can be shared with the Tauri community. We’ll also be creating a section on the Tauri website to highlight and showcase these community templates.

If you’d still like to use the previous templates from version 2 of create-tauri-app they are still published to npm and crates.io. Here’s how you can use a previous version:

# pnpm

pnpm create tauri-app@2



# yarn

yarn create tauri-app@2



# npm

npm create tauri-app@2



# Cargo

cargo install create-tauri-app --version 2.8.0 --locked


cargo create-tauri-app



# Bash

sh <(curl https://create.tauri.app/v/2.8.0/sh)



# Powershell

iwr -useb https://create.tauri.app/v/2.8.0/ps | iex

However, as time goes, these templates will become out of date as Tauri and the frontend frameworks move forward. We’d recommend you look at the community templates in the awesome-tauri repo and welcome submissions if something is missing.

We hope that these changes make it easier for the community to try out the alpha and beta versions of Tauri 2.0 and also make the process to create a new Tauri app easier for everyone! We’d love to hear your feedback and invite you to join the conversation on the GitHub Discussion for this post.

Tauri has had an amazing past year. We launched Tauri 1.0, announced the alpha version of Tauri Mobile and gathered a lot of valuable feedback from our community and users in the 2022 Tauri Community Survey.

Tauri Community Survey Results

This year, we had over 600 responses to the Tauri Community Survey (over 3x more than the previous survey’s responses). We’d like to extend a very special thank you to Wu Yu Wei and DK Liao for translating the survey from English into Simplified and Traditional Chinese so that we could include more people from the community and their feedback in the survey. You can download the public data for the survey here.

We’ve heard your feedback and have started a couple of projects to directly address it. The first one we’d like to talk about is search.

Search Improvements on Tauri.app

Without searching, can you ever find something? And if your telescope is cracked, can you see the planets or stars? We know that our search lens was dusty and scratched; it felt sometimes like a roll of the dice, and some folks even resorted to using ChatGPT to find answers.

Search has been a project that we’ve taken a few runs at over the years, but we’ve also learned that it’s not quite as easy as it first seems. Ken from the Tauri Working Group did inspirational work with the previous tauri-search project. He created a lot of the foundation and research in the previous project for us to understand what goes into search.

With the next iteration of search, we had three goals in mind:

1. Keep it maintainable
2. Keep it working
3. Keep it open source

Search Engine

First, we needed to choose a backend search engine to store and serve the search index. When evaluating search engines, we wanted to make sure we used something that shared our values of open source software and a small footprint. After comparing and researching players in the search market (and also learning from our previous approach with Meilisearch), we decided on Meilisearch because we knew it fit both of those goals.

Meilisearch have a passion for open source software and even has their search engine built in Rust which has a tiny footprint and great performance. They’ve recently announced Meilisearch 1.0 and now also have a cloud offering for those who would like a managed instance.

We decided to partner up with Meilisearch to use their engine and their Meilisearch Cloud offering to host our search engine. They graciously sponsored a hosted plan that they manage for us. This lets us focus on building Tauri, knowing that the maintenance and upkeep of the search engine are in trusted hands.

Search Ingestion & Indexing

The next piece of the puzzle is to actually get the content indexed and ingested into the search engine. Fabian from the Tauri Working Group set up the project using the docs-scraper project from Meilisearch.

Previously, we had a setup that would take our markdown documentation and JavaScript AST and use that to build the search index. Although it led to much faster indexing times, it meant we had a tightly coupled dependency between search indexing and the way we rendered content on our website. This would sometimes lead to the search results getting out of sync with the content on the live website. In order to update the website or optimize the indexer, someone would need to have knowledge of both, making it more difficult to maintain.

With the current version of the scraper, we can handle all of the configuration and tweaking of results with a single JSON file and let the scraper take care of the rest. We set up a GitHub action that would perform the scraping as part of our CI/CD pipeline and then send those results to our Meilisearch Cloud instance.

Search Frontend

The final step was to create the frontend UI that people visiting tauri.app would interact with. Amr from the Tauri Working Group created the meilisearch-docsearch project to help with this. This repo is compatible with Meilisearch 1.0 (we’re using it now on tauri.app).

It’s inspired by the algolia/docsearch and meilisearch/docs-searchbar.js projects that provided a very solid foundation to begin with. The beauty of open source is that we can learn from each other and use that to give back to the ecosystem.

To talk through some of the details, I’ll hand it over to Amr:

The meilisearch/docs-searchbar.js project was good, but I always felt it could use some improvements to get feature parity with algolia/docsearch. I also felt we could help with an update to help with UI/UX.

The main pain points with meilisearch/docs-searchbar.js were:

1. On mobile screens, it needed UI/UX improvements so that the search results wouldn’t go off-screen.
2. On desktop, the search results would normally appear under the search input, which in the case of tauri.app was placed on the top-right. This caused a bad UX because you’d have to keep moving your eyes between the page content in the middle and the search results in the top-right.
3. It is missing a common keybinding. ctrl/command + K to start the search, ctrl/command + K is pretty common in the JS ecosystem documentation sites. It also doesn’t have the ability to select text on the page and then trigger a search directly from that text.

I have been always a big fan of algolia/docsearch UI/UX. It checked all the features on my list, and I always wanted to have that for tauri.app. In fact, several months ago, I tried to change the meilisearch/docs-searchbar.js CSS on our end to improve point 1 and 2 above but I stopped mid-way because of the difficulty of building on top of existing css and fighting for highest specifity (plus CSS is hard :wink:). Other projects also couldn’t benefit from our modifications in an easy way.

Later, we were discussing how to improve the search UI and UX, and we decided that we could improve on the base Meilisearch UI. That project turned into meilisearch-docsearch.

Seeing It In Action

The good news is that all of these changes are live! You can see the new search on tauri.app. We’d love to hear your feedback on what works and what could use improvement in the GitHub Discussion for this blog post. We invite you to not only report bugs, but also if your search result wasn’t expected or should be higher up on the list of results.

We’d like to wrap up by extending a special thank you to Ken for the original Tauri Search project, Amr for the meilisearch-docsearch project, Fabian for writing the revised index scraper and continuous testing, Meilisearch for their partnership and the Meilisearch Cloud instance and finally the Tauri community for their continual feedback to help us drive Tauri and the community forward.

Next Steps

Over the next year, the Tauri Working Group is excited to continue working towards Tauri 2.0. We also have a website rewrite in the works that we’ll be launching in beta this spring. If you’d like to get involved, you can reach out to us in the Tauri Discord and follow us on Mastodon and Twitter.

Hello everybody! We just released Tauri v2.0.0-alpha3 recently. While it doesn’t bring any major feature, it does bring some huge impacts on Linux port. We will use WebKit2GTK–4.1 in 2.0 from now on.

What does this mean?

If you are using Tauri version 1.x, there’s nothing to worry about. Everything you need is still the same. But if you are using Tauri version 2.0 alpha version starting from alpha.3, you will need to install the new WebKit2GTK package with API version 4.1. We will update the prerequisites in our site soon. But if you want to know how to install such version, here are some instructions from wry:

# On Arch Linux / Manjaro:

sudo pacman -S webkit2gtk-4.1

# On Debian / Ubuntu:

sudo apt install libwebkit2gtk-4.1-dev

# On Fedora:

sudo dnf install webkit2gtk4.1-devel

Will this bring breaking changes to my code?

The main difference between version 4.0 and 4.1 are the soup library. WebKit2GTK-4.0 uses soup2 and WebKit2GTK-4.1 uses soup3. So if you didn’t use any soup2-specific APIs, your applications should continue to work fine.

The reason behind this change is because we aim to add flatpak support, but Gnome runtime uses webkit2gtk-4.1. There are also some subtle bugs like this that only happen in soup2 and they can be fixed by upgrading to soup3.

What other breaking changes we are going to expect?

The major one will be the MSRV. With Tauri v2.0.0-alpha.3 released, MSRV is bumped to 1.64. We will also update windows-rs in the future. This Rust version should satisfy the latest version of windows-rs. We do plan to update our MSRV with minor releases after 2.0. This could ease the friction to stick to any fixed Rust version while updating dependencies.

Tauri mobile is here! The first alpha release 2.0.0-alpha.0 has been published.

Updating dependencies

Make sure to update both NPM and Cargo dependencies to the 2.0.0-alpha.0 release. You can update the dependencies with:

Preview

You can adapt your existing desktop application to run on mobile or start a fresh project. Tauri runs on the connected device or starts an emulator if available.

Getting started

Read the complete guide on the next documentation website.

Known issues

• TLS support has been moved behind a Cargo feature until we figure out how to cross compile OpenSSL on Windows.
• Currently running on a device is not supported when using Xcode 14.

The Tauri team is happy to announce the 1.2.0 release. It includes a security fix, so we encourage new and existing users to update to one of the fixed versions. Other changes were internally audited and no security issues were found.

Make sure to update both NPM and Cargo dependencies to the 1.2.0 release. You can update the dependencies with:

What’s in 1.2.0

Security patch

This release includes a patch for a security vulnerability reported by MessyComposer. Due to incorrect escaping of special characters in paths selected via the file dialog and drag and drop functionality, it was possible to partially bypass the fs scope definition. It was not possible to traverse into arbitrary paths, as the issue was limited to neighboring files and sub folders of already allowed paths. A successful bypass requires the user to select a pre-existing malicious file or directory during the file picker dialog and an adversary controlled logic to access these files. This means the issue by itself can not be abused and requires further intentional or unintentional privileges. The patch is also available in 1.0.7 and 1.1.2. See the advisory for more details.

Rust version update

This release includes a minimum supported Rust version bump. Tauri now requires at least Rust 1.59 to compile. This was necessary due to several dependency updates that demanded this change.

Custom protocol headers on Linux

The Linux webview binding has been updated and it now has support to custom protocol headers when running on webkit2gtk version 2.36 or above. This fixes CORS issues on production when manually fetching a build asset.

Enhanced titlebar configuration on macOS

We finally merged one of the most awaited pull requests, introducing the titlebar style configuration. Your application can now define a transparent or overlay titlebar, hide the window title text and define the window to accept first mouse events so it can be focused immediately after receiving a click event to be dragged.

Window with overlay titlebar style

Window with transparent titlebar style (uses the window background color)

Other changes

There are a lot of smaller changes and bug fixes in this release. You can see a summary of the release notes in the following sections. The complete changelog can be found on the releases page.

New

• Allow configuring the user agent when creating a window (#5317)
• Reimplemented the option to create unfocused windows (#5338)
• Added the acceptFirstMouse window option (macOS) (#5374)
• Added the tabbingIdentifier window option (macOS) (#5399)
• Enhanced the app-specific directory APIs (#5272)
• Added show and hide methods on the app module (macOS) (#3689)
• Expose set_title for MacOS tray (#5182)
• hotreload support for frontend static files (#5256)
• Add a configuration option for the bundle publisher (#5283)

Enhancements

• Validate the package name (#5262)
• Drop the WebContext on WebView drop (#5240)
• Set the correct mimetype when streaming files through asset: protocol (#5210)

Fixes

• Fix HTML template tags in custom protocol (#5247)
• Fix scope check when reading resource files on macOS (#5218)
• Fix incorrect return type on fs/exists (#5252)
• Initialize Monitor instances with the correct classes for position and size fields instead of plain object (#5313)
• Fix dialog.save return type (#5373)
• Use correct code ja-JP for japanese instead of jp-JP (#5346)
• Clear environment variables on the WiX light.exe and candle.exe commands to avoid “Windows Installer Service could not be accessed” error. Variables prefixed with TAURI are propagated. (#4819)
• Fix regression in SystemTray::with_menu_on_left_click (#5235)
• Fix regression introduce in tauri@1.1 which prevented removing tray icon when the app exits on Windows (#5245)
• Fix access to the WebviewWindow.getByLabel function in a tauri://window-created event listener (#5458)
• Fix a deadlock when modifying the menu in the on_menu_event closure. (#5257)
• Fixes __TAURI_PATTERN__ object freeze (#5307)