Saltar al contenido

Lanzamiento estable de Tauri 2.0

Nos enorgullece enormemente anunciar finalmente el lanzamiento estable de la nueva versión principal de Tauri. ¡Te damos la bienvenida a Tauri 2.0!

En una aplicación de Tauri, el frontend se escribe en tu stack de frontend web favorito. Esto se ejecuta dentro del WebView del sistema operativo y se comunica con el núcleo de la aplicación escrito principalmente en Rust.

un gráfico que muestra el puente IPC entre el núcleo de la aplicación y el WebView del sistema

Si marcas cualquiera de las siguientes casillas, deberías usar Tauri:

  • ¿Quieres una única base de código de interfaz de usuario para todas las plataformas?
  • ¿Quieres llegar a tantos usuarios como sea posible en su plataforma (p. ej., Windows, macOS, Linux, Android, iOS)?
  • ¿Eres un desarrollador web frontend y quieres escribir aplicaciones nativas?
  • ¿Eres un desarrollador de Rust que busca escribir aplicaciones con una interfaz de usuario atractiva con la opción de hacerlo en Rust?
  • ¿Tienes un equipo existente de desarrolladores web y quieres expandirte a los mercados de aplicaciones nativas con una baja inversión inicial?
  • ¿Tienes un equipo existente de rustáceos y quieres que todo esté escrito en Rust?

un gráfico que muestra la progresión de las estrellas de GitHub de Tauri a lo largo de los años, comenzando con 0 en 2019 y continuando su crecimiento superando las 80,000 en 2024

En GitHub, el repositorio de Tauri tiene ~4,878 Pull Requests y ~3,570 Issues cerrados y alrededor de 1000 discusiones, al momento de escribir esto. Para obtener una visión más detallada, echa un vistazo al análisis de OSSinsight del repositorio de Tauri.

Nuestro Servidor de Discord tiene actualmente ~17,700 miembros. Vemos mucho soporte individual a usuarios, preguntas sobre Tauri en sí, preguntas directas al grupo de trabajo o simplemente discusiones entre otros desarrolladores de aplicaciones Tauri.

Estamos muy contentos con la comunidad positiva y colaborativa, y agradecidos con todos los miembros de la comunidad que responden o ayudan a otros en Discord o GitHub.

Mantenemos una lista curada de proyectos, aplicaciones, plugins, guías y más relacionados con Tauri en awesome-tauri. Echa un vistazo si quieres inspirarte, ver lo que otros están construyendo e idealmente crear una PR para agregar tu proyecto.

Por supuesto, esto es solo una muestra representativa y no sabemos exactamente quién más está construyendo sobre Tauri.

En junio de 2022 lanzamos Tauri 1.0 con un gran impacto en el mercado de sistemas operativos de escritorio y en cómo se pueden construir aplicaciones multiplataforma.

A finales de 2022 lanzamos nuestra versión alfa inicial de 2.0 para obtener comentarios iniciales y probar cómo se debería definir la interacción móvil.

Después de la alfa inicial, pasamos cerca de dos años refinando y cambiando la arquitectura de Tauri de forma pública. Una vez que tuvimos el panorama general lo suficientemente claro, lanzamos la beta en febrero de este año. Al mismo tiempo, colaboramos y trabajamos con auditores de seguridad externos para verificar nuestras decisiones, cambios de arquitectura y mucho más.

Este agosto publicamos la versión release candidate de 2.0 para pulir los errores principales y obtener más comentarios del uso en producción. Al mismo tiempo, la auditoría externa se concluyó y se hizo pública.

El periodo de tiempo de la versión release candidate fue considerablemente más corto y consistió principalmente en correcciones de errores de alto impacto y mejoras en la documentación. Algunos cambios que rompen compatibilidad que tuvimos que hacer durante la fase de release candidate se acumularon hasta el final y ahora se incluyen en la versión estable. Echa un vistazo a la sección de migración si tu principal preocupación es actualizar desde una versión anterior.

En total, pasamos más de dos años trabajando en mejoras, nuevas características, correcciones de errores, documentación, reescrituras y muchísimas discusiones.

Todo esto sucedió mientras lanzábamos 8 versiones menores de la rama Tauri 1.x y aplicábamos parches de seguridad y otras correcciones de errores importantes en varias versiones de parche.

Este lanzamiento y Tauri en sí solo son posibles gracias a la enorme cantidad de contribuciones de Lucas, quien ha aportado un flujo constante de cambios de código a lo largo de los años ❤️.

el gráfico de contribuciones de Lucas, con 2744 commits, más de 896,000 adiciones y 688,000 eliminaciones.

Obviamente, Lucas no es la única persona que trabaja y contribuye en Tauri, pero sentimos que merece una mención muy especial por impulsar, iniciar y apoyar el proyecto y a su comunidad a lo largo de los años.

Hemos tenido importantes contribuciones al repositorio de Tauri en la 2.0 por parte de Amr, Fabian-Lars, Tony, Chip, Jason, YuWei, icb , Simon, Oliver Lemasle y muchos otros colaboradores (datos de origen).

Recibimos un número creciente de colaboradores ocasionales (una o muy pocas PRs). Estamos agradecidos por ellos, pero nombrar a todos haría que esta fuera una lista extremadamente larga aquí.

¡Tenemos muchísimos(!) repositorios en nuestra organización que respaldan el éxito de Tauri, y sin las contribuciones de la comunidad y del grupo de trabajo, Tauri no estaría donde está ahora. ¡Un gran agradecimiento a todos los involucrados!

Otro saludo especial y agradecimiento por su constante implicación en la comunidad va para Fabian-Lars y Simon. Si has participado en las discusiones de Discord o GitHub de Tauri, es muy probable que conozcas sus nombres o avatares.

Si alguna vez buscaste en Google o YouTube sobre Tauri, probablemente viste una de las transmisiones de Jacob. Si ese no es el caso, asegúrate de echarle un vistazo y suscribirte, ya que sus sesiones van más allá de lo educativo.

Otro lugar especial en nuestro corazón lo ocupa la Junta de Tauri, destacando a Daniel Yvetot-Thompson por sus numerosas horas, sudor, sangre y dedicación para dar a conocer Tauri y hacerlo sostenible.

Algo importante que no debemos olvidar es que obtuvimos el apoyo de un socio estable de este proyecto de código abierto.

Logo de CrabNebula

CrabNebula le otorgó a varias de las personas mencionadas anteriormente y a otras no mencionadas aquí el privilegio de trabajar en el ecosistema de Tauri no solo en su tiempo libre, sino también durante su jornada laboral. Puedes encontrar el anuncio del acuerdo de colaboración en nuestro blog y hemos estado más que felices con esta colaboración durante el último año.

Solo en 2024 dedicaron más de 2,870 horas de trabajo a este proyecto, lo que impulsó enormemente el progreso y nos permite anunciar hoy el lanzamiento estable de la 2.0.

Si aún no conocías CrabNebula, asegúrate de consultar sus productos y servicios y considera la relación simbiótica con Tauri si estás interesado no solo en mejorar tus flujos de trabajo, sino también en apoyar el ecosistema de Tauri.

Con esta versión principal mejoramos y cambiamos varios aspectos de cómo y dónde puedes construir, desarrollar y publicar tu aplicación Tauri. En las siguientes secciones ofrecemos una visión más detallada. Esto no lo cubre todo, pero debería darte una buena impresión de lo que puedes esperar de Tauri.

Una de las cosas por las que siempre vas a pasar al comenzar con un nuevo framework o herramienta es el proceso inicial de incorporación o inicio rápido.

Valoramos la experiencia del desarrollador (DX) e intentamos que este proceso inicial sea tan fluido como construir y distribuir tu aplicación final.

Para esto creamos otro proyecto, que se llama create-tauri-app o abreviado CTA. Esta herramienta permite a los desarrolladores comenzar desde cero y obtener una aplicación Tauri funcionando en pocos minutos en lugar de horas.

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

Por supuesto, debes instalar algunos requisitos previos en tu sistema de desarrollo antes de comenzar a construir tu aplicación. Para esto disponemos de guías detalladas con secciones específicas para cada sistema operativo en nuestra documentación oficial.

Toda esta experiencia de inicio se ha mejorado y ahora también genera plantillas de desarrollo móvil para iOS y Android.

Tras la incorporación inicial, desarrollarás y depurarás regularmente tu aplicación Tauri. Ya en Tauri 1.x consideramos qué mejoraría tu proceso de desarrollo y extendimos el Hot-Module Replacement (HMR) a dispositivos móviles y emuladores.

Esto significa que todos los cambios en el frontend de tu aplicación no requieren una reconstrucción completa de la aplicación, y puedes ver una vista previa en vivo de cómo se verá en el dispositivo o sistema operativo para el que estás desarrollando.

Con Tauri 2.0 construimos un sistema de plugins más avanzado. Transferimos gran parte de nuestra funcionalidad anterior a nuestros plugins oficiales (consulta plugins-workspace), para permitir a la comunidad una entrada más fácil para contribuir a Tauri. También esperamos atraer a más mantenedores para los plugins y acelerar el proceso de implementación de nuevas características.

Este cambio hacia los plugins tiene otro beneficio. Vamos a poder definir qué significa "terminado" para el núcleo de Tauri. Esperamos estabilizar la funcionalidad central y ofrecer un framework estable, donde las partes móviles sean principalmente plugins que ofrezcan acceso a funcionalidades específicas del sistema.

Ya no necesitas entender todo Tauri para mejorar o implementar características específicas. Los plugins no suelen depender de otros plugins, con algunas excepciones. Esto significa que para implementar una nueva funcionalidad de acceso al sistema de archivos solo se requiere contribuir al plugin fs en lugar de a Tauri en sí.

Dado que este lanzamiento también se dirige a plataformas móviles, el sistema de plugins también admite plugins móviles. Puedes escribir o reutilizar código nativo en Swift en iOS y Kotlin en Android y exponer funciones directamente al frontend de Tauri usando Anotaciones (@Command en Android), implementando una Subclase (TuClasePlugin: Plugin) en iOS, o invocando el código en Swift o Kotlin desde un comando de Tauri basado en Rust. Consulta la documentación sobre cómo escribir tu propio plugin.

Con el lanzamiento de Tauri 2.0, los plugins oficiales seguirán la versión principal de Tauri para que la compatibilidad con la versión principal de Tauri se pueda ver de un vistazo. Sin embargo, no todos los plugins son tan estables como el propio Tauri.

La estabilidad de cada plugin se define individualmente y se documentará (próximamente) en la documentación del plugin. La API del plugin posiblemente pueda romper compatibilidad en versiones menores, pero intentaremos mantener estos cambios al mínimo, especialmente para los plugins considerados estables.

Una parte muy esperada de este lanzamiento es el soporte para sistemas operativos móviles. La versión anterior de Tauri permitía tener una única base de código de interfaz de usuario para sistemas operativos de escritorio, pero ahora esto se extiende a iOS y Android.

Hemos investigado y experimentado con diferentes soluciones para soportar dispositivos móviles y decidimos usar el lenguaje nativo del sistema operativo (Swift y Kotlin) para construir una interfaz para el código en Rust y permitir a los desarrolladores escribir parte de su funcionalidad en estos lenguajes.

Esto significa que puedes reutilizar la lógica existente de tu aplicación en Swift o Kotlin que interactúa con el sistema y exponerla a Rust o al frontend. En este momento, esto funciona como se mencionó anteriormente a través del sistema de plugins.

Soportamos el desarrollo con un emulador o un dispositivo real y proporcionamos muchas herramientas para que el proceso sea lo más fluido posible. Actualmente no estamos completamente satisfechos con la experiencia del desarrollador, pero estamos trabajando activamente para ponerla a la par con la experiencia de escritorio.

En dispositivos móviles no todos los plugins oficiales son compatibles. Algunos por diseño no se adaptan bien a móviles y otros simplemente aún no están implementados para soportar móviles. Si deseas contribuir en esta parte, consulta la última sección de esta publicación.

La Allowlist ha muerto, larga vida a la Allowlist

Sección titulada “La Allowlist ha muerto, larga vida a la Allowlist”

Sí, ya no existe la allowlist, ya que alcanzamos los límites de este sistema bastante rápido. Lo hicimos exclusivo para las características principales de Tauri y ni siquiera cubría todas las APIs de Tauri. Nuestro nuevo sistema no solo cubre toda la superficie de la API principal de Tauri, sino que también permite a los desarrolladores de aplicaciones y plugins implementar su propio control de acceso y alcance con un enfoque unificado.

El nuevo sistema que implementamos utiliza permisos - “Interruptores para comandos de Tauri”, alcances - “Validación de parámetros para comandos de Tauri” y capacidades - “Asociación de permisos y alcances a ventanas y WebViews”, para crear un sistema de control de acceso flexible pero simple de usar.

Permite la creación de archivos de permisos o alcances con nombre y su reutilización y combinación con otros permisos o alcances con nombre. Esto hace posible construir conjuntos descriptivos más detallados que contengan varios permisos y alcances simples o complejos.

Como desarrollador de plugins, puedes abstraer varios permisos base en un permiso predeterminado. Esto puede basarse en tus suposiciones de seguridad e hipótesis de amenazas predeterminadas. Todos los permisos predeterminados de los plugins oficiales de Tauri son razonablemente seguros por defecto.

Como desarrollador de aplicaciones, puedes usar, extender o reducir los permisos de los plugins. Por supuesto, también puedes crear permisos y alcances para tu propia aplicación.

Con esta adición, el núcleo de Tauri ahora es capaz de entender si un mensaje de invocación de comando desde un WebView del frontend tiene permitido llegar a la función del comando. También es capaz de adjuntar el alcance configurado al mensaje.

La implementación del comando es responsable de interpretar y hacer cumplir el alcance. Puedes leer más sobre nuestro modelo de amenazas y enfoque de seguridad en nuestra documentación.

Los cambios principales y la arquitectura de v2 fueron auditados de forma independiente por Radically Open Security durante el período de beta y release candidate. Tómate un tiempo para leer el informe y conocer más sobre el increíble trabajo de @gronke y @pcwizz.

Toda la auditoría fue financiada por la excelente gente de NLNet a través de fondos de NGI y estamos súper agradecidos de estar en la posición privilegiada de recibir auditorías de seguridad externas totalmente financiadas para lanzamientos principales.

Los resultados de esta auditoría nos llevaron a reescribir partes de cómo se expone nuestro servidor de desarrollo, específicamente para el desarrollo móvil. Sin la ayuda y guía de los auditores, esta reescritura no habría sido posible ❤️.

Además, reforzamos la exposición de nuestra API en iFrames, corregimos la validación del alcance y el acceso a identificadores de recursos para el plugin fs y http, mejoramos la estabilidad de nuestra comunicación entre procesos y muchas otras correcciones y mejoras relacionadas con la seguridad.

Reescritura de Inter Process Communication (IPC)

Sección titulada “Reescritura de Inter Process Communication (IPC)”

Con la reescritura de nuestra capa IPC, ahora admitimos la característica tan esperada de Raw Payloads y, en general, cambiamos cómo funciona internamente.

Anteriormente todos los payloads de IPC se serializaban y deserializaban en JSON, lo que causaba una sobrecarga. Esto era notorio una vez que se transferían más de unos pocos kilobytes entre el frontend y el backend.

El nuevo sistema admite Raw Requests. Estas aceleran la transferencia de grandes volúmenes de datos del backend al frontend y viceversa, donde puedes usar bytes sin procesar directamente o usar tu propio proceso de (des)serialización (p. ej., bson, protobuf, avro y otros).

Para leer archivos directamente desde el sistema de archivos hacia el WebView, seguimos recomendando la funcionalidad convertFileSrc, ya que muy probablemente sigue siendo más rápida si no necesitas procesar los datos en el backend de Rust.

Con Tauri 2.0, la diversidad de distribución aumentó enormemente. En parte, debido al ecosistema móvil y, en parte, a las contribuciones de nuestra comunidad.

Tenemos guías oficiales sobre cómo publicar en la Apple Appstore, Google Play, Microsoft Store, CrabNebula Cloud, Flathub, Snapcraft, AUR y más formatos de distribución en nuestra documentación de distribución.

Esta sección contiene todos los cambios desde la 1.x en una lista concisa.

Mostrar la lista completa
  • Añadido soporte móvil.
  • Añadido soporte para multiwebview tras la flag de característica inestable. Consulta WindowBuilder y WebviewBuilder para más información.
  • Añadida la flag de característica de cargo rustls-tls
  • Añadida la opción shadow al crear una ventana webview, el método WebviewWindow::set_shadow en Rust y la API equivalente en JS.
  • Añadidas las estructuras tauri::Webview, tauri::WebviewBuilder, tauri::WebviewWindow, tauri::WebviewWindowBuilder en Rust y clases equivalentes en JS. Los comportamientos antiguos de tauri::Window y tauri::WindowBuilder se movieron a tauri::WebviewWindow y tauri::WebviewWindowBuilder.
  • Añadido el módulo tauri::scope::fs
  • Añadido el método tauri::App/AppHandle::default_window_icon.
  • Añadido el módulo tauri::ipc con primitivas de IPC.
  • Añadido el tipo tauri::ipc::Channel y el tipo equivalente en JS Channel para enviar datos a través de IPC.
  • Añadida la opción incognito al crear una ventana webview.
  • Añadida la opción windowEffects al crear una ventana webview y WebviewWindow::set_effects para intentar cambiar efectos en tiempo de ejecución.
  • Añadido tauri::path::PathResolver
  • Añadido el método tauri::Manager::path para acceder al nuevo PathResolver
  • Añadida la opción visibleOnAllWorkspaces al crear una ventana webview.
  • Añadidos los métodos tauri::App/AppHandle::primary_monitor y App/AppHandle::available_monitors.
  • Añadidos tauri::plugin::Builder::on_navigation y tauri::plugin::Plugin::on_navigation.
  • Añadido el método tauri::WebviewWindow::navigate
  • Añadido tauri::RunEvent::Opened en macOS e iOS para soporte de enlaces profundos.
  • Añadido soporte para asociaciones de archivos en el empaquetador.
  • Añadido tauri::App/AppHandle::cleanup_before_exit para llamar manualmente a la lógica de limpieza. Siempre debes salir de la aplicación tauri inmediatamente después de que esta función regrese y no usar ninguna API relacionada con tauri.
  • En Linux, añadido el método tauri::WebviewWindow::default_vbox para obtener una referencia al gtk::Box que contiene la barra de menú y el webview.
  • Añadida la flag de característica de cargo linux-libxdo (desactivada por defecto) para permitir el enlace a libxdo, la cual se utiliza para hacer que los elementos de menú nativos Cortar, Copiar, Pegar y Seleccionar todo funcionen en Linux.
  • En macOS, añadido el método tauri::WebviewWindow::ns_view para obtener un puntero a la vista de contenido de NSWindow.
  • Añadido tauri::Builder::register_asynchronous_uri_scheme_protocol para permitir resolver una solicitud de protocolo de esquema URI personalizado de forma asíncrona y evitar bloquear el hilo principal.
  • Incluida la posición de soltado y desplazamiento para eventos de arrastrar y soltar.
  • Añadido el método tauri::WebviewWindow::set_progress_bar
  • Añadido el método tauri::WebviewWindow::set_always_on_bottom y la opción alwaysOnTop al crear una ventana webview.
  • Añadido el método tauri::WebviewWindowBuilder::on_page_load.
  • Añadida la flag de característica de cargo common-controls-v6 (activada por defecto).
  • Añadido Window::destroy para forzar el cierre de una ventana.
  • Añadido el tipo tauri::EventId
  • Añadido tauri::WindowBuilder::on_download para manejar eventos de solicitudes de descarga.
  • Añadido tauri::WebviewWindowBuilder::parent, el cual es un envoltorio conveniente sobre la funcionalidad padre para Windows, Linux y macOS.
  • Añadido tauri::WebviewWindowBuilder::owner solo en Windows.
  • Añadidos tauri::WebviewWindowBuilder::transient_for y tauri::WebviewWindowBuilder::transient_for_raw solo en Linux.
  • Añadidos tauri::WebviewWindow::start_resize_dragging y el enum tauri::ResizeDirection.
  • Añadido el método tauri::WebviewWindowBuilder::proxy_url.
  • Añadido el enum tauri::WebviewEvent
  • Añadida la variante tauri::RunEvent::WebviewEvent.
  • Añadidos los métodos tauri::Builder::on_webview_event y tauri::Webview::on_webview_event.
  • Añadido el módulo tauri::image que incluye los tipos tauri::image::Image y tauri::image::JsImage y la macro tauri::image::include_img!.
  • Añadida la función tauri::is_dev para determinar si la aplicación se está ejecutando en modo de desarrollo o no.
  • Añadido el método tauri::Assets::setup en el trait tauri::Assets que te permite ejecutar código de inicialización para tu proveedor de recursos personalizado.
  • Añadida la estructura tauri::Rect.
  • Añadido el método tauri::WebviewWindow::set_zoom
  • Añadida la opción zoomHotkeys al crear una ventana webview.
  • Añadida la función global de JS window.isTauri para comprobar si se está ejecutando en tauri o no.
  • Añadida la flag de característica specta que agrega soporte de specta para los tipos AppHandle, State, Window, Webview y WebviewWindow.
  • Añadido el getter tauri::App/AppHandle/WebviewWindow::cursor_position para obtener la posición actual del cursor.
  • Añadido el getter tauri::App/AppHandle/WebviewWindow::monitor_from_point(x,y) para obtener el monitor a partir de un punto dado..
  • Añadido tauri::RunEvent::Reopen para manejar el clic en el icono del dock en macOS.
  • Añadido defaultWindowIcon al módulo app de JS para recuperar el icono de ventana predeterminado en JS.
  • Añadido tauri::WebviewWindow::set_title_bar_style para establecer el estilo de la barra de título en tiempo de ejecución en macOS.
  • Add APIs to enable setting window size constraints separately:
    • Añadidos tauri::WindowBuilder::inner_size_constraints y tauri::WebviewWindowBuilder::inner_size_constraints
    • Añadida la estructura tauri::WindowSizeConstraints
    • Añadidos tauri::Window::set_size_constraints y tauri::WebviewWindow::set_size_constraints
  • Uso de protocolos personalizados en la implementación de IPC para mejorar el rendimiento.
  • Mejora al centrar una ventana recién creada; ya no saltará al centro después de hacerse visible.
  • La característica de Cargo custom-protocol ya no es requerida en tu aplicación y ahora es ignorada. Para verificar si se está ejecutando en producción, usa #[cfg(not(dev))] en lugar de #[cfg(feature = "custom-protocol")].
  • Mejoradas las APIs de path en JS para devolver rutas simplificadas en Windows cuando sea posible, es decir, eliminando el prefijo UNC (\\?\).
  • Mejorado el mensaje de error que se muestra al deserializar la configuración del plugin de Tauri.
  • Se establece el ID de la aplicación GTK con el identifier definido en tauri.conf.json para garantizar la unicidad de la aplicación. Esto se puede desactivar configurando la opción enableGtkAppId como false.
  • On Windows, handle resizing undecorated windows natively which improves performance and fixes a couple of annoyances with previous JS implementation:
    • Se eliminó el parpadeo del cursor al moverlo a través de un borde.
    • Se puede redimensionar desde la parte superior incluso cuando existe un elemento data-tauri-drag-region allí.
    • Al comenzar a redimensionar, los clics no traspasan a los elementos detrás, por lo que no hay más clics accidentales.
  • Se marcan AppHandle::restart y process::restart como diverging functions
  • Ya no se desempaca ni se aplana el payload sobre la IPC para que los comandos con argumentos llamados cmd, callback, error, options o payload no rompan la IPC.
  • Corregida la llamada a set_activation_policy cuando el bucle de eventos se está ejecutando.
  • Corregido un fallo por el cual no se podía evitar el cierre de una ventana desde otro webview.
  • En Windows, se corrigió que la ventana decorada no fuera transparente inicialmente hasta ser redimensionada.
  • Resolución de enlaces simbólicos en la comprobación del alcance del sistema de archivos.
  • Corregida la implementación de la API de JS basename(path, 'ext') que eliminaba todas las apariciones de ext cuando solo debía eliminar la última.
  • Corregido el parpadeo blanco de la ventana al salir en Windows.
  • Se aplican las restricciones minWidth, minHieght, maxWidth y maxHeight por separado, lo que corrige un error antiguo por el cual estas restricciones nunca se aplicaban a menos que el ancho y el alto se restringieran juntos.
  • La creación de la ventana y el hook de configuración ahora se llaman cuando el bucle de eventos está listo.
  • Se renombró la característica default-tls a native-tls.
  • Se cambió el hook de configuración del plugin para recibir un segundo argumento de tipo PluginApi
  • Se cambió el comportamiento de la estructura tauri::Window y se movió su comportamiento antiguo al nuevo tipo tauri::WebviewWindow.
  • Se movió el módulo tauri::api::path a tauri::path
  • Se movieron todas las funciones de tauri::api::path para que sean métodos en tauri::path::PathResolver
  • Se renombró la flag de característica system-tray a tray-icon.
  • Se cambiaron los métodos tauri::App::handle y tauri::Manager::app_handle para devolver una referencia a un AppHandle en lugar de un valor poseído.
  • Se cambió tauri::Builder::register_uri_scheme_protocol para devolver una http::Response en lugar de Result<http::Response>. Para devolver una respuesta de error, crea manualmente una respuesta con un código de estado >= 400.
  • El protocolo personalizado en Windows y Android ahora usa el esquema http en lugar de https.
  • Se cambió tauri::Env.args a tauri::Env.args_os y ahora usa OsString en lugar de String
  • Se cambió la variable de entorno TAURI_AUTOMATION a TAURI_WEBVIEW_AUTOMATION
  • Se cambió tauri::Builder::invoke_system para recibir referencias en lugar de valores poseídos.
  • Se cambiaron los hooks tauri::Builder::invoke_system y tauri::Builder::on_page_load para recibir un argumento tauri::Webview en lugar de un tauri::Window.
  • Se movieron los elementos del módulo tauri::command al módulo tauri::ipc para que su nombre de importación no choque con la macro tauri::command.
  • Se cambió tauri::App::run_iteration para recibir un callback y se eliminó su valor de retorno.
  • Se cambiaron AppHandle::exit y AppHandle::restart para activar RunEvent::ExitRequested y RunEvent::Exit
  • Se renombró tauri::WebviewWindowBuilder::owner_window a tauri::WebviewWindowBuilder::owner_raw y tauri::WebviewWindowBuilder::parent_window a tauri::WebviewWindowBuilder::parent_raw.
  • Se renombró la flag de característica window-data-url a webview-data-url.
  • Se cambió tauri::WebviewWindow::close para activar un evento de cierre solicitado en lugar de forzar el cierre de la ventana. Usa tauri::WebviewWindow::destroy para forzar el cierre.
  • Se renombraron las flags de característica icon-ico e icon-png a image-ico e image-png respectivamente.
  • Se eliminó el enum tauri::Icon; usa el nuevo tipo tauri::Image en su lugar. Todas las APIs que antes aceptaban tauri::Icon han cambiado para aceptar tauri::Image en su lugar.
  • Se cambiaron la estructura tauri::Context y el trait tauri::Assets para tener un genérico R: Runtime.
  • Se renombró tauri::Context::assets_mut a tauri::Context::set_assets
  • Se cambió el tipo tauri::Context para que no tenga el genérico <A: Assets>, de modo que la implementación de assets se pueda intercambiar con Context::set_assets.
  • Se cambió tauri::Context::assets para devolver &dyn Assets en lugar del genérico &A.
  • Se renombró el enum tauri::FileDropEvent a tauri::DragDropEvent y se renombraron sus variantes. También se renombraron los eventos de JS.
  • Se renombró la variante del enum tauri::WindowEvent::FileDrop a tauri::WindowEvent::DragDrop
  • Se renombraron los eventos emitidos de arrastrar y soltar archivos a tauri://drag-enter, tauri://drag-over, tauri://drag-drop y tauri://drag-leave
  • Se renombró tauri::WebviewWindow::disable_file_drop_handler a tauri::WebviewWindow::disable_drag_drop_handler.
  • Se cambió el getter tauri::WebviewWindow::url para devolver un resultado.
  • Se cambió tauri::Env.args_os para incluir la ruta del binario; anteriormente se omitía.
  • Se renombró getAll y getCurrent a getAllWindows y getCurrentWindow en el módulo window de JS, pero probablemente quieras getAllWebviewWindows y getCurrentWebviewWindow del módulo webviewWindow.
  • Se eliminaron las características de Cargo reqwest-*
  • UpdaterEvent
  • Se eliminó el módulo tauri::api y se movió a plugins independientes en el repositorio plugins-workspace.
  • Se eliminó tauri::scope::IpcScope
  • Se eliminó el módulo tauri::scope::ipc y todos sus tipos.
  • Se eliminó tauri::scope::FsScope; usa tauri::scope::fs::Scope
  • Se eliminó tauri::scope::GlobPattern; usa tauri::scope::fs::Pattern
  • Se eliminó tauri::scope::FsScopeEvent; usa tauri::scope::fs::Event
  • Se eliminó tauri::scope::HttpScope
  • Se eliminó tauri::scope::ShellScope
  • Se eliminó tauri::scope::ShellScopeAllowedCommand
  • Se eliminó tauri::scope::ShellScopeAllowedArg
  • Se eliminó tauri::scope::ExecuteArgs
  • Se eliminó tauri::scope::ShellScopeConfig
  • Se eliminó tauri::scope::ShellScopeError
  • Se eliminó la flag de característica de cargo linux-protocol-headers, ahora habilitada por defecto.
  • Se eliminaron tauri::path::Error y tauri::path::Result y se añadieron sus variantes a tauri::Error
  • Se eliminaron los alias tauri::path::Result y tauri::plugin::Result; deberías usar tauri::Result o tu propio tipo Result.
  • Se cambió el manejador tauri::Builder::on_page_load para recibir referencias. El hook de carga de página ahora se activa para los eventos de inicio y finalización de carga; para determinar qué lo activó, consulta el campo tauri::PageLoadPayload::event.
  • Se eliminó la estructura tauri::GlobalWindowEvent y se desempacaron sus campos para pasarse directamente a tauri::Builder::on_window_event.
  • Se eliminó el tipo tauri::EventHandler.
  • Se renombró tauri::Context::default_window_icon_mut a tauri::Context::set_default_window_icon y se cambió para aceptar Option<T>.

Se reestructuró la configuración de Tauri según RFC#5:

  • Se movieron los campos package.productName, package.version y tauri.bundle.identifier al nivel superior.
  • Se eliminó el objeto package.
  • Se renombró el objeto tauri a app.
  • Se movió el objeto tauri.bundle al nivel superior.
  • Se renombró el campo build.distDir a frontendDist.
  • Se renombró el campo build.devPath a devUrl y ya no aceptará rutas, solo aceptará URLs.
  • Se movió tauri.pattern a app.security.pattern.
  • Se eliminó el objeto tauri.bundle.updater y sus campos se movieron al plugin de actualización bajo el objeto plugins.updater.
  • Se movió build.withGlobalTauri a app.withGlobalTauri.
  • Se movió el objeto tauri.bundle.dmg a bundle.macOS.dmg.
  • Se movió el objeto tauri.bundle.deb a bundle.linux.deb.
  • Se movió el objeto tauri.bundle.appimage a bundle.linux.appimage.
  • Se eliminaron todos los campos de licencia de cada objeto de configuración de paquete y en su lugar se añadieron bundle.license y bundle.licenseFile.
  • Se renombró AppUrl a FrontendDist y se refactorizaron sus variantes para ser más explícitas.
  • Se renombró tauri.window.fileDropEnabeld a app.window.dragDropEnabled

Dado que intentamos que la migración desde versiones anteriores de Tauri sea lo más fluida posible, disponemos de documentación para guiarte a través del proceso.

Si te estás migrando desde una versión 1.x, consulta esta guía de migración.

Para actualizar desde una versión beta o release candidate de 2.0, consulta esta guía de migración.

La CLI de Tauri v2 incluye un comando migrate que automatiza la mayor parte del proceso y te ayuda a completar la migración:

npm install @tauri-apps/cli@next
npm run tauri migrate

Si estás familiarizado con Tauri y ya lo has usado durante tu recorrido, tómate un tiempo para revisar las Discusiones de GitHub y los Issues de GitHub. Quizás ya hayas resuelto los problemas que otros recién llegados a Tauri están experimentando ahora mismo.

Si piensas que algunos de estos problemas que has visto son genéricos y deberían estar documentados en alguna parte, probablemente tengamos el lugar perfecto para ello en nuestra documentación oficial.

Para contribuir con mejoras o adiciones, estamos abiertos a PRs en el repositorio tauri-docs. Sin embargo, asegúrate de haber leído las directrices para contribuir.

Si estás en posición de entender y traducir la documentación actual a tu idioma nativo, agradecemos las traducciones de contenido para nuestra documentación.

Los repositorios que rodean a Tauri también están buscando colaboradores; en especial, nos encantaría contar con más mantenedores y colaboradores en el plugin-workspace.

Los plugins son ahora una parte principal del desarrollo y de la experiencia de usuario de Tauri y todo tipo de ayuda es bienvenida allí. Desde discutir nuevas ideas de plugins, colaborar con otros para escribir nuevos plugins, contribuir con PRs para corregir errores en plugins existentes o documentar soluciones alternativas y conocimientos en el readme o código del plugin.

Probablemente esperas planes sólidos para el futuro y nuevas ideas geniales por nuestra parte. Actualmente tenemos algunas en mente, pero aún no nos hemos comprometido con una hoja de ruta más allá de la 2.x.

Principalmente queremos centrarnos en mejorar esta versión principal con una mejor experiencia de desarrollador, mejor documentación y errores menos impactantes. Queremos mejorar especialmente la experiencia de desarrollo móvil y hacer que todo el flujo desde la idea hasta la aplicación publicada sea lo más fluido posible.

Cosas en nuestro radar para el futuro que sentimos que deberíamos al menos mencionar:

  • Proporcionar o empaquetar Chromium Embedded Framework (CEF) para Linux como una alternativa a WebKit2GTK
  • Servo como WebView de Tauri (Prueba de concepto en Wry)

Si quieres colaborar en estas ideas, por favor háznoslo saber y lo descifraremos juntos.


© 2026 Colaboradores de Tauri. CC-BY / MIT