Descubrimiento y modelo de amenazas
Modelo de amenazas (custodia, gestión de claves, alcance de las tarjetas de pago), inventario de funciones que traslada la web al móvil, revisión del enfoque de KYC y mapeo del tratamiento de datos RGPD + CCPA.
Caso de éxito · FinTech · Cripto · Móvil
Caso de éxito de app de monedero cripto: cómo entregamos una app móvil complementaria en producción para una plataforma cripto de custodia: clientes nativos para iOS y Android sobre una única base de código en Flutter, desbloqueo biométrico, transferencias P2P, un puente integrado entre dinero fiat y criptomonedas y un enfoque preparado para auditoría que resiste el escrutinio del RGPD y la CCPA en Estados Unidos y la Unión Europea.
El cliente gestionaba una plataforma cripto de custodia con un frontend web operativo y un backend que ya procesaba dinero real. Lo que faltaba era una experiencia móvil, y el conjunto de compradores de cripto en Estados Unidos y la Unión Europea es casi por completo mobile-first. El desafío no era construir un monedero desde cero: las claves, la custodia y la casación de órdenes ya existían. El desafío era trasladar una lógica financiera compleja de la web al móvil sin perder la precisión que había ganado el producto web, ofreciendo al mismo tiempo una experiencia de usuario que oculte hasta el último gramo de complejidad cripto tras una interfaz a la altura de una app bancaria. Elegimos Flutter para los clientes móviles, mantuvimos el backend Laravel existente como sistema de registro y construimos en paralelo seis flujos centrales: registro con KYC, gestión de activos, transferencias P2P, puente entre dinero fiat y criptomonedas, cambio integrado en la app y un historial de transacciones que resiste el escrutinio de cualquier auditor.
Un resumen de lo que aportó el desarrollo de la app complementaria de monedero cripto en web, móvil y sistemas de back office durante su primer ciclo de producción.

El cliente ya tenía una plataforma web operativa y un backend que la sustentaba; lo que no tenía era una experiencia móvil que respetara cómo se comportan realmente los usuarios de cripto. Los compradores de cripto de Estados Unidos y la Unión Europea viven en el teléfono: consultan los saldos en los trayectos, reaccionan a la volatilidad desde el sofá y rara vez se sientan ante el navegador de un ordenador. Se probó pronto un parche de web móvil y se descartó: la latencia, las integraciones con el menú de compartir y los flujos de desbloqueo biométrico salían perdiendo frente a un desarrollo nativo.
Elegimos Flutter para los clientes móviles. Una única base de código Dart entrega iOS y Android con un renderizado coherente al píxel, la recarga en caliente acelera el ciclo entre diseño e ingeniería y la vía de escape de los canales de plataforma mantiene accesibles las API nativas de StoreKit, Google Pay y biometría cuando hace falta. El backend Laravel que ya servía a la plataforma web sirvió a los clientes móviles sin reescribirlo; lo único que se añadió fue un contrato REST tipado.
| Criterio | Flutter (elegido) | React Native | iOS + Android nativos |
|---|---|---|---|
| Bases de código que entregar | Una base de código Dart | Una base de código JS + módulos nativos | Dos bases de código independientes |
| Motor de renderizado | Skia: coherente al píxel en ambas plataformas | Widgets nativos conectados mediante JS | El conjunto de widgets nativos de cada plataforma |
| Rendimiento de los gráficos cripto | 60 fps en un dispositivo Android de gama media de $200 | Limitado por el puente en redibujados intensivos | Nativo: el techo depende de la pericia del equipo |
| Plazo de salida al mercado en ambas tiendas | ~5 meses para un MVP con varias funciones | ~5–6 meses: similar | 7–10 meses: el doble de equipo |
| StoreKit / Google Play Billing | Disponible mediante canales de plataforma | Disponible mediante módulos nativos | API nativas de primer nivel |
| Desbloqueo biométrico | Plugin local_auth: maduro | react-native-biometrics | LocalAuthentication / BiometricPrompt |
| Economía del equipo | Dos desarrolladores de Flutter publican en ambas tiendas | Dos desarrolladores de RN: similar | Dos equipos dedicados: costoso |
Referencias: Flutter, Apple StoreKit, Google Play Billing.

El cliente de iOS envuelve el binario de Flutter en un host fino en Swift que gestiona el desbloqueo biométrico mediante LocalAuthentication, las compras integradas mediante StoreKit y los enlaces profundos desde Safari, Mail y mensajes compartidos. El flujo de desbloqueo prioriza la biometría: Face ID o Touch ID al iniciar, con un PIN de seis dígitos de respaldo que a su vez limita agresivamente los intentos. Un solo fallo no cierra la sesión del usuario, pero cinco en diez minutos borran las claves de sesión en memoria y obligan a una reautenticación completa.
El panel de activos es la pantalla de inicio de la app de iOS: tarjetas de saldo por divisa, el valor total de la cartera arriba y un toque para ir al detalle de cada activo con un gráfico de precios y una vista de historial de transacciones. Los tipos de cambio en vivo se transmiten por un WebSocket de larga duración al backend de Laravel, con un sondeo HTTP de respaldo en las redes que bloquean WebSockets (algo real en el Wi-Fi de hoteles y congresos tanto de EE. UU. como de la UE). Los campos de importe de las transferencias se validan contra el saldo real del usuario, el mínimo de la red y la precisión decimal del activo antes de que el botón «enviar» llegue a activarse: no se puede enviar sin querer 0.000000001 BTC por un desliz del teclado. Es el mismo nivel de detalle que aplicamos en cada proyecto de desarrollo de aplicaciones móviles en el que hay dinero en juego.

El cliente de Android es el mismo binario de Flutter con un host fino en Kotlin que gestiona BiometricPrompt, Google Play Billing y el intent de compartir de Android. El comportamiento del optimizador de batería en las familias de dispositivos Samsung, Xiaomi, OnePlus y Pixel se ajustó por fabricante durante el QA: la temporización de la reconexión del WebSocket y la política de notificaciones en primer plano difieren lo bastante como para que la versión que «funciona en un Pixel» no funcionara realmente en un Xiaomi hasta completar la matriz por fabricante.
Las transferencias entre pares son el corazón social de la app. Un usuario puede enviar fondos a otro por nombre de usuario, por un código QR escaneado desde una impresión en papel o desde la pantalla de otro teléfono o por un enlace profundo compartido a través de cualquier aplicación de mensajería. El flujo imita a propósito el de una app bancaria: introducir el importe, elegir al destinatario, confirmar con biometría y seguir el estado en tiempo real desde «enviado» hasta «confirmado en la cadena». Un pequeño cambio integrado permite convertir entre los activos admitidos al tipo medio de mercado en vivo, con una divulgación transparente de la comisión en la pantalla de confirmación: sin sorpresas ni diferenciales ocultos. El mismo equipo de ingeniería lleva iOS y Android en paralelo como parte de nuestra práctica de ingeniería iOS y Android.

Una app complementaria de monedero cripto es un producto con muchas amenazas incluso cuando nunca custodia fondos directamente. La función del monedero es ser la superficie visible de un backend de custodia (saldos, transferencias, depósitos, retiradas) sin exponer nunca las claves privadas al dispositivo móvil. Las claves privadas viven en el backend, en almacenes de claves (key vaults) aislados por hardware; la app móvil recibe tokens de portador de corta duración que autorizan operaciones concretas, y toda operación que mueve dinero exige una confirmación biométrica nueva, sin importar cuándo se autenticó el usuario por última vez.
Los depósitos y retiradas vinculados a tarjeta pasan por una pasarela de pago que se ocupa del alcance PCI: la app móvil nunca ve un número de cuenta principal, solo una representación tokenizada de la tarjeta guardada del usuario. Los documentos de KYC recogidos en el alta se almacenan en un almacén de blobs cifrado con acceso registrado para auditoría, y el calendario de retención de datos está alineado con las obligaciones del RGPD para los usuarios de la Unión Europea y con las de la CCPA / CPRA para los usuarios de California y del resto de Estados Unidos.
Enfoque de cumplimiento: alineado con el RGPD · preparado para ISO 27001 · SOC 2 Type II en curso · apto para HIPAA · CCPA contemplada.
Un desarrollo en cinco fases que llevó la app complementaria de monedero cripto desde la especificación del producto hasta la publicación en ambas tiendas en Estados Unidos y la Unión Europea.
Modelo de amenazas (custodia, gestión de claves, alcance de las tarjetas de pago), inventario de funciones que traslada la web al móvil, revisión del enfoque de KYC y mapeo del tratamiento de datos RGPD + CCPA.
Estructura del proyecto en Flutter, contrato REST tipado frente al backend Laravel existente, transmisión de tipos de cambio por WebSocket y flujos de desbloqueo biométrico y PIN de respaldo.
Seis flujos centrales en paralelo: registro con KYC, panel de activos, transferencias P2P, puente entre dinero fiat y criptomonedas, cambio integrado en la app e historial de transacciones.
Matriz del optimizador de batería de Android por fabricante, reautenticación biométrica en cada acción que mueve dinero, aislamiento del alcance PCI de la pasarela de pago y QA del tratamiento de claves en memoria.
Envío a App Store y Google Play en las tiendas de EE. UU. y la UE, despliegue de la monitorización de usuarios reales, traspaso al soporte y documentación de cumplimiento RGPD + CCPA.
El cambio integrado en la app es el más pequeño de los seis flujos centrales, pero el que más aprecio genera entre los usuarios día a día. Un usuario que mira un saldo de Bitcoin puede cambiar una parte a Ethereum o a una stablecoin sin salir de la app, al tipo medio de mercado en vivo, con una divulgación transparente de la comisión que detalla el diferencial y la estimación del gas antes de que el usuario confirme. El flujo se ejecuta contra el mismo servicio de casación de órdenes de Laravel que usa la plataforma web, lo que significa que la liquidez es compartida y las cotizaciones son coherentes entre web y móvil. El derecho al cambio (y a límites de transacción más altos, retiradas en fiat y ciertos activos) depende del nivel de KYC completado por el usuario, que la app móvil lee del backend al iniciar cada sesión. Un usuario que completa el KYC en la plataforma web ve reflejada la subida de nivel en el móvil en un minuto, y un usuario que inicia el KYC en el móvil lo completa mediante un flujo de carga de documentos que usa la cámara nativa con OCR en el dispositivo para validar en el cliente antes de que el documento salga del dispositivo. Todo el subsistema se construyó pensando en la extensibilidad: añadir un nuevo activo, una nueva divisa fiat, una nueva pasarela de pago o un nuevo nivel de KYC es un cambio de configuración en el servicio de derechos, no un lanzamiento de código.
La app complementaria de monedero cripto se lanzó en Apple App Store y Google Play, con tiendas activas en Estados Unidos y en la Unión Europea. La versión en inglés atiende a usuarios de California, Nueva York, Texas, Florida y Washington en EE. UU., y a usuarios de Países Bajos, Alemania, Francia, Irlanda y Suecia en la UE, sin una base de código distinta por región. Los flujos de consentimiento se adaptan a la región en la capa del cliente: los usuarios de la UE y el EEE reciben una pantalla de consentimiento granular al estilo del RGPD con interruptores independientes para cualquier analítica de producto opcional; los usuarios de California reciben en el mismo flujo un aviso al estilo de la CCPA, «No vender ni compartir mi información personal». Las prácticas de tratamiento de datos están alineadas con el RGPD para los usuarios europeos y con el mosaico de leyes estatales de privacidad de EE. UU.: CCPA / CPRA (California), VCDPA (Virginia), CPA (Colorado), CTDPA (Connecticut), UCPA (Utah), TDPSA (Texas) y la CPA de Oregón. Las divulgaciones específicas de cripto sobre volatilidad, custodia y alcance de la declaración fiscal se muestran en el alta y no quedan enterradas tras un enlace a los términos del servicio.
El backend ya estaba en producción para el producto web, por lo que el lanzamiento móvil reutilizó la flota existente en centros de datos de la UE y EE. UU. (nodos en Países Bajos, Alemania, Francia, Suecia e Irlanda para la cobertura de la UE; US East y US West para Norteamérica), con el enrutamiento de tráfico por región heredado de la plataforma web. Tanto la clasificación por edades de App Store como la clasificación de contenido de Google Play se calibraron para la categoría de apps financieras, y la política de privacidad dentro de la app se redactó para documentar la arquitectura descrita, citando directamente las obligaciones del RGPD y las obligaciones de la CCPA de California. El equipo de ingeniería responsable del desarrollo trabaja en CET y sigue una jornada CET con solapamiento con la costa este de EE. UU. (9:00–13:00 ET) para las reuniones diarias, la coordinación de las revisiones de las tiendas y la respuesta a incidencias: la franja horaria que permite a un equipo de producto de EE. UU. y a uno de ingeniería de la UE compartir cuatro horas de solapamiento en directo cada día.
La hoja de ruta activa de desarrollo de software a medida del monedero incluye un flujo de emparejamiento con monederos de hardware para usuarios con autocustodia, un subsistema de alertas de precio por notificación push, una función de «perfiles» múltiples para usuarios que separan monederos personales y de trading y un cliente de escritorio construido sobre Flutter para escritorio que comparta la lógica de negocio con la base de código móvil. Se prevén niveles de KYC más profundos para usuarios institucionales de EE. UU. y la UE, con el subsistema de derechos ya estructurado para el control de acceso a funciones por niveles. Los planes de infraestructura incluyen una mayor automatización del backend y un banco de pruebas interno de verificación continua del plano de custodia dentro de la hoja de ruta de cloud y DevOps.
Si planea un monedero cripto, una app móvil complementaria de custodia o cualquier desarrollo móvil FinTech en el que el enfoque biométrico y la preparación para auditoría deban convivir con una experiencia a la altura de una app bancaria para audiencias de EE. UU. y la UE, hemos entregado este stack de principio a fin y podemos acortar de forma notable el plazo de desarrollo. El desarrollo de referencia está documentado en la referencia del caso, y el equipo de ingeniería que lo desarrolló forma parte de YuSMP Group. Trabajamos a precio cerrado en MVP bien acotados y con equipos de desarrollo dedicados para la entrega continua, con jornada CET y una franja garantizada de solapamiento con la costa este de EE. UU. (9:00–13:00 ET) para reuniones diarias, demos y respuesta a incidencias.
Un MVP de app complementaria de monedero cripto con clientes para iOS y Android en Flutter, desbloqueo biométrico, panel de saldos, transferencias P2P y envíos a las tiendas suele costar $120k–$280k. Añadir un puente entre dinero fiat y criptomonedas con pasarela de tarjetas, cambio integrado en la app, KYC de varios niveles, emparejamiento con monederos de hardware y un tratamiento de datos preparado para auditoría lleva un producto completo a $320k–$680k. Los principales factores de coste son el trabajo de la matriz de Android por fabricante, el aislamiento del alcance PCI de la pasarela de pago y la coordinación de la revisión de las apps financieras de App Store y Google Play en torno a las divulgaciones de custodia.
Flutter entrega iOS y Android desde una única base de código Dart con renderizado coherente al píxel mediante Skia, algo importante cuando los gráficos cripto deben dibujarse a 60 fps en un dispositivo Android de gama media de $200. La vía de escape de los canales de plataforma mantiene accesibles las API nativas de StoreKit, Google Play Billing y biometría cuando hace falta. React Native es una alternativa razonable con una economía de equipo similar; un desarrollo totalmente nativo para iOS y Android suele duplicar el equipo y aproximadamente el plazo. Para una app complementaria de monedero en la que el backend ya existe, Flutter es la opción de menor riesgo.
La app móvil nunca ve las claves privadas. Las claves viven en el backend, en almacenes de claves (key vaults) aislados por hardware con acceso registrado para auditoría, y el cliente móvil solo recibe tokens de portador de corta duración que autorizan operaciones concretas. Toda acción que mueve dinero exige una confirmación biométrica nueva, sin importar cuándo se autenticó el usuario por última vez, y una racha de fallos biométricos borra el estado de sesión en memoria. Un atacante decidido con acceso total al dispositivo aún puede obtener mediante ingeniería social una confirmación biométrica, pero el modelo de custodia sitúa la vulneración de mayor valor en el backend y no en el teléfono.
Apple exige que las apps cripto cumplan la categoría de servicios financieros, informen en el producto del riesgo de custodia y de volatilidad y usen StoreKit para cualquier compra integrada de valor no cripto. Google Play exige divulgaciones equivalentes, que se declare de forma destacada la finalidad financiera de la app y que se supere una revisión adicional de permisos. Ambas tiendas exigen un KYC funcional para las entradas de dinero fiat, una divulgación transparente de cualquier recogida de datos y, para las apps que atienden a usuarios de la UE y California, un mecanismo de consentimiento granular que satisfaga el RGPD y la CCPA / CPRA en el mismo flujo.
Un MVP centrado en clientes Flutter, desbloqueo biométrico, panel de activos, transferencias P2P y el envío a ambas tiendas suele tardar 16–22 semanas. Añadir un puente entre dinero fiat y criptomonedas con pasarela de tarjetas, cambio integrado en la app, KYC de varios niveles y una matriz del optimizador de batería de Android por fabricante suma 6–10 semanas. La fase de refuerzo preparada para auditoría (aislamiento del alcance PCI de la pasarela de pago, QA de la reautenticación biométrica y modelado de amenazas del plano de custodia) se subestima con frecuencia y debería presupuestarse con 4–6 semanas de trabajo dedicado.
Casos relacionados

Lanzamiento completo de un token ERC-20: contrato en Solidity, auditoría de seguridad, listados en exchanges y pago con MetaMask.
Ver el caso →
Centro unificado de ecosistema cripto que agrega varios tokens: datos de mercado en vivo, gráficos y punto de entrada de compra directa.
Ver el caso →
Producto multiplataforma de firma electrónica con enfoque preparado para auditoría, lanzamiento en EE. UU. y la UE y alineación con RGPD + CCPA.
Ver el caso →Cuéntenos algunos detalles y un consultor sénior le responderá en un día hábil.