Recursos, iconos y binarios externos

Recursos: lo que la aplicación lee y no escribe

"resources": ["plantillas/*", "datos/idiomas.json"]

Las rutas son relativas a src-tauri, admiten comodines, y también aceptan una forma de objeto cuando hace falta cambiar el destino:

"resources": { "../compartido/esquema.sql": "sql/esquema.sql" }

Dónde acaban. En cada plataforma, en un sitio distinto: dentro del paquete de aplicación en macOS, junto al ejecutable en Windows, y en un directorio del sistema en Linux. Por eso la ruta no se escribe: se pregunta.

// La única forma correcta de encontrar un recurso.let ruta = app    .path()    .resolve("plantillas/base.html", tauri::path::BaseDirectory::Resource)?;let contenido = std::fs::read_to_string(ruta)?;

Escribir ./plantillas/base.html funciona en desarrollo —porque el directorio de trabajo es el del proyecto— y falla en cuanto la aplicación está instalada. Es uno de los fallos que el nivel 10 clasifica como «solo en producción», y este es su origen más común.

Iconos: una imagen, un subcomando

La lista de iconos parece tediosa porque lo es: cada plataforma quiere sus tamaños y sus formatos. La respuesta del framework es no mantenerlos a mano:

# Una imagen cuadrada, grande, con transparencia. El CLI genera el resto.bun run tauri icon ./logo.png

Eso produce el juego completo —los PNG de varios tamaños, el formato de macOS, el de Windows, y los del proyecto de móvil si existe— en el directorio de iconos. La regla práctica: la fuente de verdad es tu imagen original, y todo lo demás es generado. Regenerar cuando cambie el logo, no editar el resultado.

Dos avisos que ahorran una versión mal publicada:

• La imagen de partida tiene que ser cuadrada y grande, del orden de mil píxeles de lado. El subcomando escala hacia abajo, no hacia arriba.
• macOS aplica su propia máscara de esquinas redondeadas, así que un icono que ya venga con esquinas redondeadas dibujadas sale con doble redondeo. Se entrega cuadrado y el sistema lo recorta.

Binarios externos: la regla de nombres

Es el mecanismo de los sidecars, y tiene una peculiaridad que desconcierta la primera vez.

"externalBin": ["binarios/conversor"]

Con esa declaración, el empaquetador no busca binarios/conversor: busca binarios/conversor-<triple-de-destino>, donde el triple es el identificador de la plataforma y la arquitectura para las que se compila.

binarios/conversor-aarch64-apple-darwinbinarios/conversor-x86_64-pc-windows-msvc.exebinarios/conversor-x86_64-unknown-linux-gnu

La razón es evidente en cuanto se ve: un binario compilado no es portátil, así que el empaquetado tiene que elegir el correcto para la máquina de destino. Y la consecuencia práctica también: necesitas una copia por plataforma que soportes, obtenida o compilada por separado. Averiguar el triple de tu máquina se hace con rustc -vV, y el nivel 46 tiene el procedimiento completo.

Dos cosas más, que en la fase XII cuestan caro si se ignoran:

• El binario externo se firma también. El sistema operativo mira todo lo que va dentro del paquete, no solo tu ejecutable. Un sidecar sin firmar rompe la notarización de macOS.
• Ejecutar un sidecar necesita permiso. Empaquetarlo no lo hace invocable: hace falta declararlo en las capabilities, con su ámbito. Fase V.

Recurso frente a dato del usuario

Es la distinción que más se confunde y la que rompe actualizaciones:

La confusión típica: empaquetar una base de datos como recurso y escribir en ella. Funciona en desarrollo, funciona la primera vez tras instalar en Linux, y falla en macOS por permisos —o peor, funciona hasta que una actualización la sustituye por la versión vacía y el usuario pierde su trabajo—.