Tauri

Tauri v1.0 was released without adequate maturity, with functionality suitable only for very limited application scopes. The majority of real-world application types cannot be built reliably.

Tauri apps cannot obtain Windows package identity, which blocks access to many Windows-specific APIs including the notifications API, severely limiting functionality on Windows.

Bug fixes depend entirely on external teams (WebKit, Microsoft Edge, Apple, Linux distributions). Tauri has no control over fix timing or prioritization, creating unpredictable resolution timelines for critical issues.

Tauri only supports .exe and .msi bundles on Windows, not the .appx and .msix formats required for proper Microsoft Store integration. Applications currently using .appx would need to be removed from the Store and rebuilt with .exe format, creating a significant migration barrier.

Tauri lacks proper support for in-app purchases or any meaningful documentation on how to implement IAPs, making it unsuitable for applications that rely on this monetization model.

Tauri's design uses an asynchronous request-response model between JavaScript frontend and Rust backend (serialized as JSON), which is fundamentally misaligned with traditional desktop UI patterns that rely on event-driven/observer models. This introduces latency, complicates debugging, and regresses from proper desktop app design principles.

Migration from Tauri 1.0 to 2.0 was a nightmare with woefully inadequate documentation, blocking developers mid-stream and forcing them to make difficult technology decisions.

Tauri provides a limited file system API compared to standard JavaScript APIs and requires explicit path whitelisting at build time via enumeration. Dynamic runtime access to unforeseen directories requires recompilation and redistribution, severely limiting flexibility for business applications with user-configured paths.

Official flavor variants like Pure JS and Svelte JS do not work without modifications despite being officially supported, forcing developers to debug and fix setup issues before starting development.

Tauri's WebKit implementation on Mac and Linux fails to recognize cookies marked as 'Secure', breaking authentication and session management for apps relying on remote resources.

The Tauri team has acknowledged that the mobile developer experience is underdeveloped and has identified it as a key priority post-release, indicating current limitations in mobile app development.

Using SvelteKit with Tauri forces developers to use only client-side rendering and abandon typical server-side features, requiring significant architectural changes to data-fetching strategies and application structure.

Tauri's architecture emphasizes Window objects rather than Application-level concepts, which conflicts with macOS's strong emphasis on application lifecycle management, requiring developers to work around framework limitations.

Tauri forces backend developers to learn HTML, CSS, and JavaScript, and vice versa. There are no native UI components—the entire interface relies on web technologies. This creates a barrier for teams specialized in desktop or backend development and requires hiring full-stack developers or extensive training.

Tauri apps require linking complex libraries like udev and libinput that are not meant for application use, creating obscure build failures and making compilation difficult on non-standard host systems.

The previous search indexing system was tightly coupled to content rendering, causing search results to become out of sync with the actual website content. The search experience was unpredictable—described as 'a roll of the dice'—forcing users to resort to ChatGPT for answers.

Tauri's comprehensive build options demand fluency in JSON, Rust scripts, and the Tauri CLI. Setting up test, staging, and production environments requires significant training effort and external support, particularly challenging for small teams or rapid prototyping phases.

Tauri lacks built-in support for auto-launching applications on system startup, requiring developers to fork the framework and implement custom solutions.

Tauri cannot properly create macOS universal binaries from separate arm64 and x64 builds, and performs redundant codesigning on macOS builds. While not hard blockers, these issues are annoying enough to delay migration decisions.

Tauri's long-term success depends on the growth of official and community plugin repositories; insufficient plugin availability limits access to native functionality developers need.

While Electron provides true cross-platform consistency by bundling Chromium, alternatives like Tauri rely on system WebViews that vary significantly across OS versions (particularly problematic on Linux), creating debugging challenges. Tauri's approach yields much smaller binaries (10-20MB vs 50-90MB).

Tauri apps consume significantly more resources than native applications (10x worse in some metrics), still requiring manual closure to avoid system sluggishness, limiting its lightweight promise.

The responsibilities and relationships between Builder, App, Window, and Runtime objects, along with their proxy and handler types, lack clarity in the codebase, making it difficult for developers to understand how to properly use the API.