Servicio
Desarrollo de aplicaciones móviles
Aplicaciones que siguen funcionando cuando la red se detiene.
Para equipos cuyos usuarios no están sentados a un escritorio — personal de campo, jefes de obra, equipos de reparto, comerciales en ruta — y para aplicaciones de consumo donde el primer minuto decide si se conserva. Lo que importa aquí técnicamente es el comportamiento sin conexión y la sincronización, no las pantallas.
La decisión
Cuándo es la elección correcta.
La mayoría de las aplicaciones móviles se demuestran con el wifi de la oficina y se usan con una 4G caprichosa a la entrada de una obra. En esa distancia es donde fallan. Una aplicación que da por supuesta la conexión cargará con la culpa de perder datos que nunca recibió, y una vez que el personal de campo deja de confiar en ella vuelve al papel, que es exactamente el resultado que el proyecto debía impedir.
La sincronización es la parte difícil, y suele ser la que se acotó en una frase. Qué ocurre cuando dos personas editan el mismo registro sin conexión, cuando un teléfono vuelve tras tres días, cuando el servidor ha cambiado las reglas entretanto. Son decisiones de diseño, y si nadie las toma, las toma la aplicación por su cuenta, mal.
Fijamos el modelo de conflictos antes de construir, hacemos del trabajo sin conexión el caso normal y no el caso de error, y probamos con una conexión limitada en vez de con wifi. Las pantallas son la mitad fácil.
Lo que se obtiene
Qué cubre el encargo.
Datos con enfoque sin conexión primero
El almacenamiento local como fuente de verdad para la sesión, con una cola que sobrevive al cierre de la aplicación y una regla de conflictos elegida a propósito.
Una sincronización que se puede inspeccionar
El estado de la sincronización es visible para el usuario y para el soporte, de modo que «no se guardó» pasa a ser una pregunta con respuesta.
Nativo o multiplataforma
Kotlin y Swift donde el hardware, el procesamiento en segundo plano o el rendimiento lo exigen; una base de código compartida donde la aplicación es sobre todo pantallas y la economía es real.
Un procesamiento en segundo plano que aguanta
Sincronización y envío programados que siguen funcionando bajo las restricciones de batería de Android, probados en las capas de fabricante que los rompen.
Una autenticación que falla de forma limpia
Caducidad de tokens gestionada correctamente: una sesión caducada cierra la sesión del usuario en lugar de repetir indefinidamente una petición muerta.
Ingeniería de versiones
Compilaciones firmadas, despliegue gradual, notificación de fallos y avisos de actualización dentro de la aplicación, para poder detener una mala versión.
Stack
Con qué lo construimos.
Elegidos proyecto a proyecto. Aquí no se impone nada por defecto, y el equipo que se encargará del mantenimiento pesa tanto como el problema.
Android
Kotlin con Jetpack Compose, Room para almacenamiento local, WorkManager para sincronización en segundo plano.
iOS
Swift con SwiftUI, y la persistencia nativa de la plataforma en lugar de una capa intermedia.
Multiplataforma
React Native o Flutter donde la aplicación se sostiene en sus pantallas y una base de código reduce de verdad el trabajo a la mitad.
Backend
La misma API que usa su plataforma web, versionada para que una aplicación antigua en campo siga funcionando.
Distribución
Play Store y App Store, o distribución empresarial gestionada cuando la aplicación es interna.
Comparación
Multiplataforma o nativo.
La primera decisión real de un proyecto móvil. Hacemos las dos cosas, así que esta tabla es el razonamiento real y no un argumento a favor de nuestra preferencia.
| Aspecto | Multiplataforma | Nativo |
|---|---|---|
| Más adecuado para | Formularios, listas, sincronización: aplicaciones que son sobre todo pantallas sobre una API | Cámara, ubicación en segundo plano, Bluetooth o rendimiento sostenido |
| Coste para dos plataformas | Aproximadamente una sola compilación, más los ajustes propios de cada plataforma | Cerca de dos compilaciones, y dos bases de código que mantener después |
| Sin conexión y sincronización | Perfectamente viable; el diseño de la sincronización importa mucho más que el framework | Igual: es una decisión de modelo de datos, no de plataforma |
| Funciones de hardware y sistema operativo | Suficiente para los casos habituales; cualquier cosa poco común necesita un módulo nativo igualmente | Acceso directo, y ningún puente que depurar cuando un fabricante cambia de comportamiento |
| Procesamiento en segundo plano bajo las restricciones de batería de Android | Factible, pero las capas agresivas de los fabricantes hay que probarlas en ambos casos | Más fácil de controlar, y más fácil de diagnosticar cuando un dispositivo mata el proceso |
| Mantenimiento a largo plazo | Una sola base de código, más un framework con su propio ciclo de versiones mayores | Dos bases de código, pero cada una en la vía bien documentada de su plataforma |
Cómo se desarrolla
De la primera conversación a estar en producción.
Orientativo para un trabajo de esta naturaleza. El piloto no es opcional: nada se conmuta hasta que los usuarios dicen que aguanta.
- 1 semana
Definición del alcance
Fijamos el modelo de conflictos y el comportamiento sin conexión antes de diseñar nada. Añadir cualquiera de los dos después equivale casi a reescribirlo todo.
- 4 a 8 semanas
Construcción de los cimientos
Primero el almacenamiento local, la cola de sincronización y la ruta de trabajo principal, probados con una conexión limitada y no con el wifi de la oficina.
- 2 a 3 semanas
Piloto en campo
Usuarios reales en sus propios teléfonos, incluidos los de gama baja, mientras el proceso en papel continúa. Ahí es donde se corrigen las suposiciones sobre el trabajo sin conexión.
- 1 a 2 semanas
Publicación
Envío a tiendas o distribución gestionada, despliegue gradual, notificación de fallos y aviso de actualización dentro de la aplicación para poder detener una mala compilación.
Después de la puesta en marcha
Qué cambia.
- Los equipos de campo la siguen usando pasado el segundo mes, y esa es la única medida real para una aplicación de campo.
- «No se guardó» pasa a ser una pregunta con respuesta, porque el estado de la sincronización es visible para el usuario y para el soporte.
- Un teléfono que lleva tres días sin conexión se reconcilia sin que nadie pierda su trabajo.
- Una versión antigua que quedó en campo sigue funcionando, porque la API está versionada y no se da por actualizada.
Descrito cualitativamente a propósito. No publicamos porcentajes de mejora que no podamos vincular a un cliente concreto con su consentimiento.
Preguntas
Preguntas frecuentes.
Nativo o multiplataforma: ¿qué deberíamos elegir?
Si la aplicación es sobre todo formularios, listas y sincronización, la economía del multiplataforma suele ser la correcta. Si depende de la cámara, la ubicación en segundo plano, hardware Bluetooth o rendimiento sostenido, lo nativo compensa su sobrecoste. Recomendamos según lo que la aplicación hace realmente, no según una preferencia de la casa.
¿Funcionará sin internet?
Se prevé desde el principio donde el uso lo exige. Los registros se escriben localmente, se ponen en cola y se sincronizan cuando vuelve la conexión, y esa cola sobrevive al cierre de la aplicación o al reinicio del teléfono.
¿Publicáis vosotros en las tiendas?
Sí, incluidas las fichas de las tiendas, las capturas y las respuestas a las reseñas. Las cuentas quedan a su nombre: nunca somos titulares de la cuenta de tienda de un cliente.
¿Puede funcionar con nuestro sistema actual?
Sí. La mayoría de las aplicaciones móviles que construimos son una superficie de campo sobre un sistema que ya existe, no un producto aparte con sus propios datos.
¿Podéis retomar una aplicación que construyó otro?
Normalmente sí. Empezamos con una revisión rápida de la base de código, la cadena de publicación y las cuentas de tienda, y luego volvemos con lo que haría falta. Si la respuesta honesta es que reescribir cuesta menos que retomar, lo diremos y mostraremos el razonamiento.
¿Necesitamos realmente una aplicación, o bastaría con un sitio móvil?
Un sitio adaptable cubre mucho y cuesta bastante menos. Una aplicación justifica su coste cuando se necesita trabajo sin conexión, acceso a hardware, procesamiento en segundo plano o notificaciones push. Si nada de eso aplica, le orientaremos hacia la respuesta más barata.