Los frameworks multiplataforma resuelven muy bien la interfaz y muy mal la criptografía. Un equipo que eligió Flutter o React Native para no mantener dos aplicaciones descubre, al llegar al requerimiento de firma electrónica, que esa capa compartida se detiene justo donde empiezan los almacenes seguros del sistema operativo, los controladores de dispositivos y las bibliotecas nativas. A partir de ahí, cada plataforma vuelve a ser un mundo aparte.
La buena noticia es que ese muro se puede rodear con una decisión de arquitectura, no con más código nativo. La mala es que muchos proyectos descubren el muro tarde, cuando ya prometieron una fecha.
Dónde termina el código compartido
Tanto Dart como JavaScript pueden manipular archivos, mostrar un PDF y hablar con una API. Lo que no pueden hacer por sí solos, sin bajar a código nativo, es acceder al llavero del sistema, al almacén de claves con respaldo de hardware o a un dispositivo criptográfico conectado. Esas operaciones viven en el mundo nativo y llegan al framework a través de canales de comunicación con la plataforma o de módulos puente.
La consecuencia práctica: el momento en que el equipo decide "vamos a firmar en el dispositivo" es el momento en que empieza a escribir y mantener código específico para iOS y para Android, que es exactamente lo que buscaba evitar al elegir el framework.
La decisión que ahorra el proyecto
La salida más limpia es no implementar la operación criptográfica en la app. Que la aplicación sea un cliente rico —visor, autenticación, estados, notificaciones— y que la firma la ejecute un servicio en la nube con el certificado del titular resguardado del lado del proveedor.
Con ese diseño, la app multiplataforma vuelve a ser realmente multiplataforma: todo lo que hace es mostrar documentos, autenticar al usuario y hablar por HTTP. No hay bibliotecas nativas de criptografía, no hay diferencias de comportamiento entre fabricantes, no hay material sensible en el dispositivo. El modelo está descrito en firma electrónica en la nube para empresas, y las consideraciones generales de móvil, en firma electrónica en apps móviles nativas.
Fricciones propias de cada framework
| Punto de fricción | Flutter | React Native |
|---|---|---|
| Acceso a APIs del sistema | Canales hacia código nativo por plataforma | Módulos nativos o la arquitectura de puente vigente |
| Visor de PDF | Depende de paquetes de terceros con calidad dispar | Suele apoyarse en el visor nativo o en una vista web |
| Almacenamiento seguro | Paquetes que envuelven llavero y almacén de claves | Bibliotecas equivalentes, con diferencias de comportamiento |
| Tamaño del paquete | Base mayor por el motor de renderizado | Menor base, crece con dependencias nativas |
| Actualizaciones remotas | Limitadas para código compilado | Comunes para la capa JavaScript |
| Depuración de errores nativos | Rastros que cruzan dos mundos | Rastros que cruzan dos mundos |
Ninguna columna gana. La elección debería hacerse por el equipo disponible y por el resto del producto, no por la firma electrónica, precisamente porque la firma se resuelve del lado del servidor.
Actualizaciones remotas y material criptográfico
React Native popularizó la práctica de actualizar la capa JavaScript sin pasar por la tienda, y hay soluciones equivalentes en otros entornos. Es cómodo para corregir una pantalla, pero conviene fijar una regla dura: ninguna lógica que toque credenciales, autorizaciones o material criptográfico debería poder cambiar por una actualización remota no auditada. Ese canal es rápido justamente porque salta los controles, y saltar controles en la parte sensible del producto es una mala idea.
La misma cautela vale para las banderas de configuración remota: activar o desactivar comportamientos de seguridad desde un panel externo convierte ese panel en parte de la superficie de ataque.
Dependencias de terceros: el riesgo silencioso
Los ecosistemas de paquetes son la mayor ventaja de estos frameworks y también su punto débil. Antes de incorporar una biblioteca que toque documentos, autenticación o almacenamiento seguro, vale hacer una revisión breve pero seria:
- Actividad reciente del repositorio y respuesta a reportes de seguridad.
- Cantidad de dependencias transitivas que arrastra.
- Permisos que agrega al manifiesto sin que nadie los pida.
- Si envía telemetría a servidores del autor.
- Licencia compatible con el uso comercial previsto.
Una biblioteca de visor de PDF que manda el archivo a un servicio externo para renderizarlo es un incidente de confidencialidad esperando a ocurrir. Vale la pena verificarlo antes, no después del primer contrato firmado.
El visor: donde se nota la diferencia
En una app de firma, el visor de documentos es la pantalla más importante. El usuario tiene que leer lo que va a firmar, y una experiencia pobre no es solo incómoda: debilita la manifestación de voluntad que da valor al acto. Los requisitos mínimos son desplazamiento fluido en documentos largos, ampliación, indicador de página, carga progresiva y comportamiento predecible al rotar el dispositivo.
En frameworks multiplataforma esto suele resolverse delegando al visor nativo o a una vista web, y ambas opciones traen sus propias asperezas de integración. Es un componente que conviene prototipar temprano, con un documento real de decenas de páginas y no con un PDF de ejemplo de dos hojas.
Estados, reintentos y notificaciones
La lógica de estados es idéntica a la de una app nativa y merece la misma atención. Cada solicitud de firma necesita un identificador propio que permita reintentar sin duplicar. La app debe distinguir con claridad entre pendiente de lectura, pendiente de firma, en proceso, firmado y rechazado, y no colapsar todo en un genérico "cargando".
Las notificaciones empujadas requieren configuración nativa en ambas plataformas, sin importar el framework. Del lado del servidor, el disparador correcto es el evento del servicio de firma, como se explica en webhooks de firma electrónica. Consultar en bucle desde el celular gasta batería, gasta datos y llega tarde igual.
Qué probar antes de dar el proyecto por cerrado
- Un documento largo, de muchas páginas y con imágenes, en el equipo más modesto del parque.
- Firma con la aplicación en segundo plano y la pantalla bloqueada a mitad del proceso.
- Pérdida de red durante la operación y recuperación posterior sin duplicar la firma.
- Dispositivos de distintos fabricantes de Android, especialmente los que aplican políticas agresivas de ahorro de energía.
- Verificación del archivo resultante fuera de la app, con una validación independiente como la descrita en validación programática de firmas.
- Comportamiento cuando el certificado del usuario está próximo a vencer o ya venció.
El backend hace el trabajo pesado
Si la app delega la firma, el peso del proyecto se traslada al servidor. Ahí conviene apoyarse en la guía de integración de la API de firma electrónica y en la guía técnica para desarrolladores, que cubren autenticación, manejo de errores y trazabilidad. La app queda como un cliente más, y eso es exactamente lo que se quiere: que la parte difícil viva en un solo lugar y no replicada en dos plataformas.
Sobre certificados, la emisión es 100% en línea, toma aproximadamente 30 minutos y está disponible en archivo .p12, token USB o firma en la nube. Para un producto móvil, la nube es la que encaja. Los valores vigentes están en la página de precios.
El soporte del producto, en un solo lugar
El grupo también desarrolla Omnifox, plataforma omnicanal que reúne WhatsApp, redes sociales, correo y llamadas en una bandeja compartida. Para un equipo que distribuye una app, es donde aterrizan los reportes de usuarios que no abren un ticket formal: escriben por WhatsApp o por redes. Tenerlos centralizados, asignados y con historial permite detectar patrones —un fabricante concreto, una versión concreta— mucho antes que revisando reseñas de tienda. Más información en omnifox.io.
Preguntas frecuentes
¿Se puede firmar con certificado desde código Dart o JavaScript puro?
El acceso a los almacenes seguros del sistema y a dispositivos criptográficos ocurre en el mundo nativo. Cualquier solución que lo prometa desde la capa compartida está usando código nativo por debajo o está delegando en un servicio.
¿Flutter o React Native para una app de firma?
Si la firma se ejecuta en la nube, la elección deja de depender de este requerimiento y se decide por el equipo, el resto del producto y los tiempos. Ninguno de los dos ofrece una ventaja criptográfica real.
¿Es seguro actualizar la app por fuera de la tienda?
Para cambios de interfaz puede ser aceptable. Para lógica relacionada con credenciales, autorizaciones o firma, conviene prohibirlo por política: ese canal existe para evitar revisiones, y esa parte del producto necesita revisiones.
¿Qué pasa con los usuarios que ya tienen su certificado en token USB?
Ese formato no funciona desde un teléfono. Si esos usuarios deben firmar en movilidad, la organización necesita evaluar la migración a firma en la nube antes de comprometer el alcance de la app.
¿Cómo se prueba que el documento quedó bien firmado?
Con una validación independiente del archivo resultante, fuera de la app, que revise la cadena de certificados y el estado de revocación. Lo que se ve en pantalla no es evidencia del estado criptográfico.
Si tu equipo desarrolla en Flutter o React Native y necesita firma electrónica con validez legal en Ecuador, habla con un asesor corporativo de Firmas.com.ec. Solicita tu cotización corporativa.