Apps que se quedan en la pantalla de inicio.
Apps iOS nativas, Android y multiplataforma: offline-first, instrumentadas y pulidas al nivel que hace que la gente vuelva tras la primera semana.
Las descargas de la primera semana son fáciles. La retención en la semana cincuenta y dos es ingeniería.
La mayoría de las apps se abandonan en unos días, no porque la idea fuera mala, sino porque la app iba lenta en un Android de tres años, perdía datos en zona sin cobertura o acosaba con notificaciones que nadie quería. La retención no es un problema de marketing; es un estándar de ingeniería.
Nuestras apps mueven empresas: neveras desbloqueadas al escanear a las 3 de la madrugada, turnos fichados por NFC en decenas de sedes, comidas pagadas en dos toques. La sincronización offline-first, los pagos nativos y la analítica son cimientos en cada build, porque eso es lo que exige sobrevivir en una pantalla de inicio.
Entregado en las dos stores.
Sea cual sea la estrategia de plataforma, el estándar es idéntico: rápido, usable sin conexión, instrumentado.
iOS nativo
Apps Swift que se sienten evidentes en la plataforma: widgets, App Clips y el pulido que notan los usuarios de Apple.
Android nativo
Apps Kotlin ajustadas para el espectro real de dispositivos, incluida la gama media que usa la mayor parte del mundo.
Multiplataforma
Flutter y React Native cuando un único código sirve mejor al negocio: una decisión de ingeniería, no una moda.
Sincronización offline-first
Datos local-first con sincronización sin conflictos, para que la app funcione en un sótano, en un avión y en zona sin cobertura.
Pagos, NFC y push
Compras in-app, wallets, NFC tap-to-act y una estrategia de notificaciones que respeta al usuario lo suficiente para seguir activada.
Lanzamiento en las stores y después
Envíos a prueba de revisiones, despliegues progresivos, seguimiento de fallos y compatibilidad con el SO de por vida.
El pulido es un proceso, no un sprint final.
Una calidad que sobrevive tanto a la revisión de la store como a la reseña furiosa de tres estrellas.
01Prototipar en dispositivo
Recorridos clicables en hardware real desde la semana dos, porque una app se juzga en la mano, no en Figma.
02Construir offline-first
Sincronización, caché y estados de fallo diseñados desde el principio. La conectividad se trata como un extra, no como una hipótesis.
03Probar en dispositivos reales
Un muro de Androids baratos y iPhones viejos: los teléfonos de sus usuarios, no el de su fundador.
04Lanzar e iterar
Despliegues progresivos, umbrales de tasa sin fallos e iteración guiada por la analítica. La app mejora en cada release.
Ya lo hemos entregado.
La app móvil en el corazón de un comercio conectado valorado en $10M+: explorar, escanear, desbloquear, pagar.
FeelEat — Happy Fridge
Explorar los menús del día, escanear para desbloquear una nevera inteligente, pagar en la app y ver exactamente qué contiene cada plato: nutrición, alérgenos y orígenes incluidos.
Elegidas por el problema, no por el currículum.
Nativo donde importa, compartido donde compensa: cada decisión defendida sobre el mérito de ingeniería.
Un solo equipo. Cero traspasos.
Las disciplinas que más a menudo se combinan con las apps móviles: misma arquitectura, mismos ingenieros, sin peaje de integración.
Preguntas, respondidas.
Lo que los compradores de apps móviles nos preguntan más. Para lo demás: envíe un brief y un ingeniero senior responde en un día hábil.
Resúmelo en un brief. Un ingeniero sénior —no un comercial— responde en un día laborable.
Q.01¿Nativo o multiplataforma, qué elegir?
Depende de lo que haga la app, y lo defenderemos con pruebas. Una integración profunda con la plataforma, la cámara o el trabajo en segundo plano favorecen lo nativo; las apps de contenido y comercio suelen salir más rápido y más barato en Flutter o React Native, sin compromiso visible para el usuario.
Q.02¿Cuánto se tarda en estar en la App Store?
Una v1 acotada suele tardar 10-16 semanas, revisión de la store incluida. Enviamos pronto con un despliegue progresivo: el día del lanzamiento es un botón que pulsar, no una plegaria a la cola de revisión.
Q.03¿Gestionan la aprobación en App Store y Play Store?
De principio a fin: fichas, declaraciones de privacidad, notas de revisión y la inevitable danza del reenvío. Hemos entregado suficientes apps para saber qué señalan los revisores antes de que lo señalen.
Q.04¿Qué pasa después del lanzamiento?
Soporte de por vida: compatibilidad con las versiones del SO, parches de seguridad y seguimiento de fallos por parte del equipo que la construyó. Las apps se pudren sin mantenimiento; las nuestras siguen cosechando cinco estrellas años después.
Q.05¿Pueden retomar una app móvil construida por otra agencia?
Con frecuencia. Empezamos con una auditoría de código de una semana que produce una hoja de ruta de remediación, y después retomamos el código por fases. Motivos comunes de cambio: arquitectura inestable, staffing offshore oculto o velocidad estancada.
Q.06¿React Native o Flutter, si vamos a multiplataforma?
React Native si su equipo ya conoce React/TypeScript y quiere compartir lógica con una app web: el ecosistema y la cantera de contratación son más amplios. Flutter si quiere una UI idéntica al píxel en todas las plataformas y no le importa Dart. Ambos están listos para producción; lo que decide son sus competencias existentes y la posibilidad de compartir código web, no la moda.
Q.07¿Cómo gestionan las compras integradas y las suscripciones?
Usamos RevenueCat por encima de StoreKit y Google Play Billing para que la validación de recibos, los derechos de acceso y el estado de suscripción multiplataforma se gestionen en un único lugar, en lugar de dos integraciones nativas frágiles. También obtiene la analítica de suscripciones que Apple y Google no proporcionan, y la restauración de compras —motivo de rechazo habitual— se vuelve fiable.
Q.08¿Cómo lanzan actualizaciones sin pasar por las stores cada vez?
Los parches de la capa JavaScript en React Native pueden salir OTA mediante CodePush/EAS Update, dentro de los límites de las reglas de Apple y Google: sin ciclo de revisión para los cambios elegibles. El código nativo sigue exigiendo una release en la store. También construimos un mecanismo de feature flags remotos y de actualización forzada, para hacer dark-launch de funcionalidades y exigir una subida de versión cuando una ruptura de API lo imponga.
¿Una app que sus usuarios
deberían adorar?
Díganos el trabajo que la app debe realizar, y para quién. Un ingeniero móvil senior responde en un día hábil con un consejo de plataforma y un alcance honesto.