El contexto
Un grupo de prensa edita una revista de programación televisiva y la prolonga con una aplicación móvil: la parrilla de canales, las fichas de programas y los artículos de la redacción.
La aplicación ya existía. Se había construido con Cordova y Angular — es decir, un sitio web encapsulado en una carcasa nativa, un enfoque muy extendido a mediados de los años 2010. Funcionaba, estaba en producción y había llegado a su límite.
El reto
Es una situación que muchas empresas conocen sin saber cómo salir de ella: una aplicación híbrida que ha envejecido bien funcionalmente y mal técnicamente.
Los síntomas son siempre los mismos. El desplazamiento por una parrilla densa de programas no tiene la fluidez de una aplicación nativa. Cada actualización de iOS o de Android se convierte en un riesgo, porque la capa de encapsulado depende de componentes que ya no se mantienen de verdad. Y las bibliotecas del ecosistema escasean.
Ante esto, dos malas respuestas habituales:
- No hacer nada, hasta el día en que una actualización del sistema operativo rompe la aplicación y hay que rehacerla con urgencia, sin presupuesto previsto.
- Empezar de cero, con una nueva aplicación, un nuevo identificador en las tiendas y la pérdida de todo el historial — reseñas, posicionamiento, instalaciones existentes. Los usuarios tienen que volver a descargarla. Muchos no lo hacen.
El verdadero objetivo no era, por tanto, «reescribir la aplicación». Era reescribir la aplicación sin que el usuario se diera cuenta.
Lo que hicimos
La reescritura completa en Flutter, con una arquitectura en capas — un núcleo técnico (red, almacenamiento, tema), funcionalidades aisladas entre sí (parrilla TV, actualidad, búsqueda, ficha de programa, ajustes) y una capa compartida. Nada exótico: una estructura que otro desarrollador puede retomar sin manual.
La continuidad de versión. La última versión híbrida llevaba el número 3.1.8; la primera versión Flutter salió como 3.2.0. Desde la tienda y desde el usuario, es una actualización más — no una aplicación nueva. El historial, las reseñas y el parque instalado se preservan. Es el detalle que distingue una migración lograda de una migración que cuesta la base de usuarios.
La comodidad de lectura, que era la razón de ser del proyecto:
- Caché local de las parrillas, para que la aplicación abra con contenido en vez de un indicador de carga
- Caché de las peticiones de red, para no recargar lo que no ha cambiado
- Cargas progresivas al abrir las pantallas, en lugar de una pantalla vacía
Un back-end de contenidos, desarrollado en Java, compuesto por servicios separados:
- Un enriquecedor de parrillas, que completa los datos brutos de los canales con información adicional — incluidas recomendaciones procedentes de las plataformas de streaming
- Un agregador de artículos, que recoge la producción editorial de la redacción para mostrarla en la aplicación
La aplicación está publicada en la App Store y en Google Play.
El resultado
Una aplicación nativa, mantenible con las herramientas de hoy, entregada en continuidad con la que sustituye.
Si hubiera que quedarse con una sola cosa de este proyecto, sería esta: la parte difícil de una migración técnica casi nunca es técnica. Reescribir código sabemos hacerlo. Lo que exige método es hacerlo sin que sean los usuarios quienes paguen la transición — conservar el identificador, conservar la numeración, conservar las costumbres y hacer visible solo lo que mejora.