Разработка на Tauri

Tauri — фреймворк, на котором мы делаем десктопные приложения для Windows, macOS и Linux из одной кодовой базы. Логика приложения работает на Rust, интерфейс пишется привычными веб-инструментами (React, Vue или Svelte на Vite), а окно рисует встроенный в операционную систему WebView, без собственной копии Chromium. Установщик минимального приложения на Tauri весит несколько мегабайт. Аналог на Electron тянет с собой целый браузерный движок на сотню мегабайт и больше. Памяти Tauri-приложение потребляет примерно как нативная программа.

Что мы создаём

Мы делаем софт, которому место на компьютере пользователя, а не во вкладке браузера. Это внутренние инструменты для операционных отделов: они работают с локальными файлами, сканерами, принтерами и устройствами на последовательном порту и не падают, когда пропадает сеть. Клиентские приложения для SaaS-продуктов с иконкой в трее, глобальными горячими клавишами, системными уведомлениями и deep links. Офлайн-приложения с локальной базой SQLite, которые синхронизируются с сервером, как только появляется связь. Утилиты для разработчиков и администраторов с удобным интерфейсом поверх консольных инструментов. Отдельно переводим на Tauri существующие приложения на Electron, когда их размер, расход памяти или процесс обновления стали проблемой: веб-фронтенд остаётся, слой на Node.js переписываем на Rust.

Наш подход

Начинаем с границы между интерфейсом и ядром на Rust. Каждый вызов из веб-слоя идёт через типизированные команды Tauri, а TypeScript-обёртки генерируем из сигнатур Rust с помощью tauri-specta. Если поле переименовали, сломается сборка, а не сессия клиента. Тяжёлая работа — разбор файлов, шифрование, обработка изображений, сетевая синхронизация — остаётся в Rust, в асинхронных задачах Tokio, поэтому интерфейс не подвисает.

Безопасность строим на модели capabilities из Tauri 2. Каждое окно получает только нужные ему разрешения: окну настроек незачем доступ к файловой системе, а удалённый контент вообще не видит нативных API. Content Security Policy задаём явно, секреты храним в системной связке ключей, а не в localStorage.

Релизы автоматизированы. CI собирает установщики на раннерах Windows, macOS и Linux (MSI или NSIS, DMG, AppImage, deb и rpm), подписывает их сертификатами клиента, проводит нотаризацию для macOS и публикует подписанные манифесты для встроенного апдейтера Tauri. Перед выпуском тот же пайплайн гоняет clippy, юнит-тесты Rust, тесты фронтенда и сквозные проверки через WebDriver. Tauri 2 собирает приложения и под iOS и Android: это пригодится, если десктопному инструменту нужен мобильный компаньон на том же ядре.

Почему мы

Для проекта на Tauri нужны сразу два навыка: продакшен-Rust и современный веб-фронтенд. Наша команда работает с обоими каждый день, поэтому одни и те же инженеры проектируют слой команд, пишут сервисы на Rust и собирают интерфейс. Мы закрываем то, на чём обычно буксуют десктопные проекты: подпись кода и нотаризацию, раскатку автообновлений, различия между WebView2, WebKit и WebKitGTK, поведение установщика на корпоративных машинах с урезанными правами. Рутину вроде тестов и шаблонного кода инженеры отдают AI-агентам, и каждое изменение проходит ревью до слияния.

Tauri и Electron: коротко о различиях

	Tauri 2	Electron
Рендеринг	Системный WebView (WebView2, WebKit, WebKitGTK)	Встроенный Chromium
Логика приложения	Rust	Node.js
Размер установщика	Несколько МБ для минимального приложения	Обычно от 100 МБ
Расход памяти	Близко к нативному приложению	Браузерный движок на каждое приложение
Одинаковый рендеринг на всех ОС	Нет, нужно тестировать каждый WebView	Да
Мобильные платформы	iOS и Android с версии 2.0	Нет
Доступ к нативным API	Разрешения на уровне окна, по умолчанию запрещено	Полный доступ Node.js, если не ограничить

Когда выбирать эту технологию

Tauri подходит, когда нужно настоящее десктопное приложение с доступом к файлам, офлайн-режимом, треем и интеграцией с ОС, и при этом важны компактный установщик, скромный расход памяти и фронтенд, который поддержит ваша веб-команда. Это хорошая замена разросшемуся приложению на Electron. Если продукт делается под одну платформу и должен совпадать с её интерфейсом до пикселя, лучше взять нативный инструментарий (SwiftUI, WinUI). Если всё нужное пользователю помещается в браузер, веб-приложение с офлайн-поддержкой обойдётся дешевле в разработке и доставке. И учтите: системные WebView рендерят по-разному, поэтому тестирование интерфейса на трёх платформах входит в каждый релиз.