window-vibrancy puts the platform's own blur behind one Rust function

One handle in, a platform effect out

The crate's own summary is a single line, Make your windows vibrant, and the mechanism underneath is direct platform calls rather than an abstraction of its own.

On Windows the dependency is windows-sys, constrained to versions greater than or equal to 0.60 and less than or equal to 0.61, with the features that matter here, Win32_Graphics_Dwm for the Desktop Window Manager backdrop APIs, Win32_Graphics_Gdi, Win32_UI_WindowsAndMessaging, Win32_Foundation, Win32_System_LibraryLoader and Win32_System_SystemInformation.

On macOS the dependency is objc2 at 0.6, with objc2-app-kit at 0.3.2 or newer, which the manifest explains is the first version with NSGlassEffectView, and the feature list includes NSVisualEffectView, NSGlassEffectView, NSView, NSBox, NSColor and NSResponder. The macOS side is Objective-C runtime bindings rather than a Windows API, and the two halves share only the window handle.

That shared piece is the raw-window-handle crate at 0.6, and it is what makes the crate usable from any windowing library rather than only from Tauri. The development dependencies are tao at 0.34 and winit at 0.30, and the repository ships examples for both, plus a Tauri example. The published metadata points the documentation at docs.rs/tauri-plugin-vibrancy and the repository at tauri-plugin-vibrancy, and the crate is authored by the Tauri Programme within The Commons Conservancy.

Five effects, and each one has its own platform rules

The function table in the README is the reference, and it is worth reading as a compatibility contract rather than a feature list.

apply_blur and clear_blur cover Windows 7, 10 and 11, with 22H1 only for the 11 case, and they carry a warning about bad performance when resizing or dragging the window on Windows 11 build 22621 and later. apply_acrylic and clear_acrylic cover Windows 10 and 11, with the same kind of warning for Windows 10 version 1903 and later and Windows 11 build 22000. apply_mica and clear_mica cover Windows 11. apply_vibrancy and clear_vibrancy cover macOS 10.10 and newer. And apply_liquid_glass with clear_liquid_glass cover macOS 26 and newer, described as the modern glass effect with a customisable radius, tint colour, opacity and an interactive option.

Two things follow from that table. Every effect comes with a clear counterpart, so the operation is reversible, and the platforms are not symmetric. Mica exists only on Windows 11, and liquid glass only on macOS 26 and newer, which means a single call site cannot be portable across both without a compile time check.

That is visible in the example, where the call is guarded by a cfg attribute for the target operating system and the expectation message says the function is only supported on one platform.

use window_vibrancy::{apply_blur, apply_vibrancy, NSVisualEffectMaterial};

#[cfg(target_os = "macos")]
apply_vibrancy(&window, NSVisualEffectMaterial::HudWindow, None, None)
    .expect("Unsupported platform! 'apply_vibrancy' is only supported on macOS");

#[cfg(target_os = "windows")]
apply_blur(&window, Some((18, 18, 18, 125)))
    .expect("Unsupported platform! 'apply_blur' is only supported on Windows");

The blur call also shows the API shape. On Windows the effect takes a tint, here an RGBA tuple, and on macOS the effect takes a material, here NSVisualEffectMaterial::HudWindow, with two further options that are passed as None in the example.

The Windows blur and acrylic paths have documented performance cliffs

The notes column of the function table contains the most practically useful information in the README, and it is not decoration.

For apply_blur and clear_blur, the note reads that there is bad performance when resizing or dragging the window on Windows 11 build 22621 and later. For apply_acrylic and clear_acrylic, the note says the same about resizing and dragging, on Windows 10 version 1903 and later and on Windows 11 build 22000.

The reason is in the nature of the two effects. Both are applied to the window's own backdrop, so the operating system has to recomposite the blurred content whenever the window's geometry changes. A window that is being dragged changes its geometry on every frame, and the effect is recalculated on every one of them. Acrylic in particular is the more expensive of the two on the versions named.

This narrows where the crate is a good fit. An application with a fixed window, or one where dragging is rare, will not notice. A window that the user resizes continuously, which is most modern applications, will. The acrylic note covers Windows 10 version 1903 and later and Windows 11 build 22000, which is a wide slice of the currently supported Windows population, so the warning is not about one exotic build.

Mica and liquid glass carry no such note in the table. On Windows 11, mica is the material designed for the system shell surfaces, and on macOS 26 the glass effect is the modern replacement for the older visual effect materials, so the absence of a warning is at least consistent with those being the cheaper paths on their own platforms.

The other thing to check before you commit is the floor. The blur path is documented as Windows 7, 10 and 11 with 22H1 only for 11, so a target that still runs an early Windows 10 build can use blur but a target on an early Windows 11 cannot.

Linux is out of scope because the compositor owns the effect

The platform specific section is a single line, and it is an absolute one. Linux is unsupported, and blur and any vibrancy effects are controlled by the compositor installed on the end user system.

That is a different kind of statement from the other platform notes. A Windows or macOS limitation in this crate is about a version or a performance characteristic, both of which are things a developer chooses to accept. On Linux the effect is not in the application at all. The compositor draws the window background, and whether anything is blurred behind it depends on the desktop environment the user has installed, whether the window is marked as transparent, and whether the compositor supports the effect for that window type.

For a Tauri application this interacts with a setting the README mentions separately, the transparent background on the html and body elements and the transparent flag on the window in the Tauri configuration. Those settings are what let the compositor see through the window, and they are the same settings that a Linux build would need, and it is the compositor's choice what to do with what shows through.

The practical consequence is that a cross platform desktop application cannot rely on this crate for a consistent look. The macOS and Windows builds get a designed material, and the Linux build gets whatever the user's compositor does with a transparent window, which may be nothing at all.

That is a reasonable division of labour for a crate that wraps native APIs, and it is also the clearest boundary in the project. There is no Linux path to implement here, because there is no single Linux implementation to implement.

The macOS 26 glass effect takes a builder, and one option needs macOS 27

The newest function in the crate is apply_liquid_glass, for macOS 26 and newer, and it takes an options builder rather than positional arguments.

use window_vibrancy::{apply_liquid_glass, LiquidGlassOptions, NSGlassEffectViewStyle};

#[cfg(target_os = "macos")]
{
    let options = LiquidGlassOptions::new(NSGlassEffectViewStyle::Clear)
        .radius(26.0)
        .opaque(false)
        // macOS 27+ only, ignored on macOS 26
        .interactive(true);

    apply_liquid_glass(&window, options)
        .expect("Unsupported platform! 'apply_liquid_glass' is only supported on macOS 26+");
}

The style comes from NSGlassEffectViewStyle, the radius is a float, and the opacity is a flag. The interactive option is the interesting one. The README explains that it enables the glass visual response to user interactions, matching NSGlassEffectView.effectIsInteractive, that it requires macOS 27 or newer, and that it is silently ignored on macOS 26 and older.

A silently ignored option is the kind of thing that costs a day, and it is worth knowing before you ship a build that depends on the interaction effect.

There is also a more advanced path for applications that manage their own web view. If you manage the primary content view yourself, for example a WKWebView, you can pass its pointer via the content_view method so the crate can reparent it into the glass view's contentView.

let webview: NonNull<std::ffi::c_void> = find_webview(&window);

let options = LiquidGlassOptions::new(NSGlassEffectViewStyle::Clear)
    .radius(26.0)
    .content_view(webview);

A complete example of that WebView integration with Tauri lives in the repository at examples/tauri/src-tauri/src/main.rs.

Tauri needs three configuration changes before the effect shows

The Tauri section of the README is short and every item in it is required for the effect to appear at all.

First, set the html and body background to transparent, which the README links to the example index.html. Second, set the windows entry in the Tauri configuration to transparent, linked to the example tauri.conf.json. Third, on macOS, set macOSPrivateApi to true, again linked to the same configuration file.

The third one deserves a note. The setting is called private API for a reason, and the README flags it as macOS only, which tells you that the transparent window path on macOS is not something the platform supports without opting into a private interface. A team that has a policy against private APIs has to weigh that against the look they are after, and the crate does not hide the requirement.

The examples in the repository cover the three ways in. There is examples/tao.rs, examples/winit.rs and a full examples/tauri/ directory, which the README points to for a more complete example of usage with Tauri.

The version constraint is the last piece of configuration in practice. The tip at the top of the README says that if you are using tauri@v1, you need to use version 0.4 of this crate. The current version is 0.8.1, so a Tauri 1 project is several releases behind on purpose, and the crate is a single dependency version bump away from a build break in a project that has not migrated yet.

Dual licensed, fast moving, and organised for changelogs

The licensing is the permissive double, Apache-2.0 OR MIT, with LICENSE-APACHE, LICENSE-MIT and a LICENSE.spdx file in the repository root. For a crate that is going to be linked into a desktop application, that choice removes the copyleft question entirely, and the spdx file is there so that tooling can read the terms without parsing the headers.

The versioning is a normal semantic version on a crate that is still moving quickly. The listed releases are v0.8.1 on 2026-09-22, v0.8.0 on 2026-07-16 and v0.7.1 on 2025-11-12, and the last push was on 2026-10-15. The package metadata states edition 2021 with a minimum Rust version of 1.77, which is a useful floor to know if you are pinning toolchains.

Two details in the repository layout say something about how the project is run. There is a .changes/ directory, which is the changelog fragment directory used by a release tool, and a CHANGELOG.md. There is also a renovate.json, so the dependency updates are automated, which matters for a crate that tracks objc2 and windows-sys closely enough that a windows-sys version bump can change what compiles.

The docs.rs metadata is worth a glance too. The default target is x86_64-pc-windows-msvc, and the extra documentation targets are x86_64-apple-darwin and x86_64-pc-windows-msvc, which means the rendered documentation on docs.rs is generated on Windows, with macOS as an additional target, and the crate is published with an Apache-2.0 OR MIT licence, the rust-version 1.77, and the include list covering src/**/*.rs, the README, the changelog and the licence files.

Editorial conclusion

window-vibrancy fits a Tauri or any Rust windowing application that wants the system blur behind its window, and it removes a lot of per platform Win32 and Objective-C plumbing. It is the wrong choice for a Linux build, where the README is explicit that the effect belongs to the user's compositor, and for a Windows application that resizes often, because the acrylic and blur paths are documented as performing badly while a window is dragged. Verify first which effect suits your target builds, since the Windows versions have specific floors, and pin the crate version to the one your Tauri generation expects.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. Releases
5. tauri-apps/window-vibrancy on GitHub