Código específico de plataforma

La estructura

La misma del nivel 67.1, aplicada dentro del plugin:

src/  lib.rs          el constructor y la API pública  comandos.rs     comunes: llaman a la implementación  error.rs  escritorio/     una implementación  movil/          otra

Y la interfaz común es lo que hace que funcione: los comandos llaman a funciones que existen en las dos, y quien use el plugin no ve la diferencia.

Cuándo hace falta código nativo

Y aquí aparece algo que el escritorio no exigía:

Y eso amplía lo que el nivel 65.2 avisaba: escribir plugins de móvil puede exigir tocar los lenguajes nativos, no solo leer configuración.

Tauri da el mecanismo: una forma de registrar código nativo y llamarlo desde Rust, con la serialización por medio. Es más ceremonia que llamar a una función y es lo que permite que el plugin sea útil en móvil.

Lo que no existe en alguna plataforma

El caso incómodo, con tres respuestas según el caso:

Y lo que no vale: una implementación vacía que devuelve éxito sin hacer nada. Nivel 67.1, regla cuatro — y en un plugin es peor, porque quien lo use no puede saberlo.

Documentar las diferencias

Y es la parte que cierra:

• Una tabla de qué hace cada operación en cada plataforma, con lo que no está.
• Y las diferencias de comportamiento, no solo de disponibilidad: si una operación es asíncrona en una plataforma y bloqueante en otra, o si pide permiso en una y no en otra.

La segunda es la que más se olvida y la que más problemas causa, porque quien use el plugin escribe su código contra el comportamiento que ve en su máquina.