La renovación tecnológica de la aplicación móvil Mi Carpeta Ciudadana, no solo responde a un desafío técnico de gran magnitud, sino que ha permitido definir un modelo de desarrollo transversal, aplicable a otros proyectos y tecnologías actuales, alineado con los objetivos de eficiencia, calidad y evolución continua que marca el horizonte de la Administración 2030.
A finales de 2024, App Factory había alcanzado un grado de madurez técnica y organizativa propio de una auténtica factoría de aplicaciones. Contaba con un sistema de diseño consolidado, un amplio conjunto de librerías y componentes comunes, y un proceso completamente automatizado de integración y despliegue continuo. Este ecosistema cubría prácticamente todas las necesidades transversales de las aplicaciones móviles de la AGE, desde el arranque y la monitorización hasta la autenticación, la configuración remota o la accesibilidad, apoyándose además en una librería de componentes gráficos que garantizaba coherencia visual en todos los desarrollos.
En este contexto, Flutter se había consolidado como la tecnología de referencia para los nuevos proyectos, permitiendo unificar el desarrollo y el mantenimiento en una única base de código multiplataforma. Sin embargo, existía una excepción relevante: Mi Carpeta Ciudadana.
Publicada en el último trimestre de 2022, Mi Carpeta Ciudadana, se había convertido en una de las aplicaciones móviles más ambiciosas desarrolladas por la Administración Pública. Con alrededor de 6 millones de usuarios, acceso a cerca de un centenar de servicios y varios cientos de pantallas, la aplicación había crecido de forma sostenida con el objetivo explícito de convertirse en el punto de entrada principal para la consulta de datos y expedientes tanto de ciudadanos como de empresas.
En el momento de su concepción y buscando la máxima estabilidad tecnológica, se optó por un desarrollo nativo empleando las arquitecturas más consolidadas entonces: Clean Architecture con Kotlin en Android y VIPER con Swift en iOS. Esta decisión fue razonable y prudente en 2022, cuando Flutter aún era un framework relativamente reciente y su evolución futura no estaba garantizada.
Tres años después, este planteamiento tenía un efecto colateral claro: mientras el resto de la App Factory evolucionaba de forma homogénea sobre Flutter, Mi Carpeta Ciudadana obligaba a mantener dos líneas adicionales de desarrollo nativo, tanto para la propia aplicación como para los componentes y librerías compartidos. Esta situación incrementaba de forma significativa los costes, los plazos y los riesgos asociados a cualquier evolución transversal.
A comienzos de 2025, además, se preveía un año especialmente exigente: la evolución de Cl@ve hacia Cl@ve Móvil, la incorporación de certificados de curva elíptica, mejoras relevantes en accesibilidad y la necesidad de reutilizar componentes de seguridad en otras aplicaciones. Afrontar estos cambios de manera simultánea en tres plataformas distintas multiplicaba la complejidad, especialmente en una aplicación que seguía incorporando nuevas funcionalidades de forma continua.
La decisión de unificar todos los desarrollos sobre Flutter para completar la estandarización de la factoría era lógica e inevitable. El problema no era el objetivo, sino el camino para alcanzarlo. El tamaño y la complejidad de Mi Carpeta Ciudadana hacían que cualquier planteamiento clásico de migración resultase, sencillamente, inasumible.
El análisis inicial confirmó que ninguna de las aproximaciones clásicas permitía abordar la migración en un plazo asumible. Una migración progresiva por módulos habría prolongado durante años la coexistencia de tecnologías, incrementando costes y complejidad. La reconstrucción vista a vista, incluso apoyándose en el paradigma declarativo de Flutter, implicaba desarrollar y validar cientos de pantallas con miles de combinaciones posibles de estados, datos y requisitos de accesibilidad. El uso de plantillas parecía la única opción viable pero la variabilidad de las vistas era tan elevada que tampoco parecía que pudiese ser un factor decisivo.
Ante tanta incertidumbre, a principios de 2025 se optó por desarrollar una prueba de concepto. Esto permitió simplificar el núcleo de la aplicación, identificar sinergias y aplicar aceleradores de desarrollo. Con ello se obtuvo una base funcional viable sobre la que continuar. Sin embargo, el verdadero cuello de botella no estaba en la capacidad de Flutter para construir interfaces, sino en la magnitud del esfuerzo humano necesario para diseñar, verificar y mantener la calidad visual, funcional y de accesibilidad de una aplicación de este tamaño. La variabilidad de las vistas, en muchos casos dependiente de los propios datos del usuario, multiplicaba el esfuerzo de pruebas hasta niveles comparables al propio desarrollo.
Una vez que se había logrado estandarizar y homogeneizar el núcleo de la aplicación, es decir, la estructura, sólo quedaba por encontrar un mecanismo para estandarizar también la fachada: la interfaz de usuario. Fue en este punto cuando el análisis detallado de la aplicación reveló un patrón clave. Pese al elevado número de pantallas, la estructura subyacente de las vistas era muy homogénea. Lo que variaba no era tanto la forma como el contenido y el orden de los elementos.
De esta observación surgió la pregunta decisiva: ¿y si, en lugar de construir manualmente cada vista, se describiera su contenido y, a partir de esta descripción, se generase automáticamente la interfaz? ¿Y si se eliminara la variabilidad introducida por el factor humano en la construcción de la interfaz?
La respuesta fue la introducción de una nueva capa de abstracción sobre el paradigma declarativo de Flutter: el desarrollo de vistas basadas en guiones o scripts. Este enfoque, tan sencillo como potente, fue el detonante que permitió abordar la renovación completa de Mi Carpeta Ciudadana en un plazo sorprendentemente reducido.
La solución se apoyó en la arquitectura Flutter BLoC, ya implantada en el arquetipo de App Factory. Esta arquitectura estructura las capas en tres niveles: datos en el nivel inferior, estado global de la App en el nivel intermedio y presentación en el nivel superficial.
El cambio se introdujo exclusivamente en la última capa, en la presentación. Esta capa encargada de la gestión de las vistas se divide a su vez en dos capas: controlador de estado y vista. En lugar de que el controlador construyera directamente la vista, se incorporó un módulo intermedio encargado de generar un guion de la vista. Este guion no contiene referencias al modelo de dominio ni lógica alguna: describe únicamente, de forma secuencial, los elementos que deben mostrarse y los valores literales que deben emplearse. Una vez construido el guion, se delega la construcción de la vista a un módulo transversal de renderizado de las vistas que actúa de forma autónoma.
Para modelar estos guiones, se diseñó un metalenguaje sencillo, implementado íntegramente en Dart puro y sin dependencias externas. De este modo, el código de una vista de detalle deja de definirse como un árbol complejo de widgets para convertirse en una secuencia lineal de elementos: títulos de sección, componentes clave-valor, alertas, enlaces o acciones, descritos de forma declarativa y ordenada.
Tal como se ha indicado, una vez construido el guion, este se entrega junto con la plantilla correspondiente al módulo común de renderizado que actúa de forma transversal en toda la aplicación. Este módulo recorre el guion e instancia, para cada elemento descrito en el guion, el componente gráfico adecuado de la librería de componentes inyectando los valores ya resueltos (valores literales). El resultado es una vista completamente construida que se devuelve al controlador como un único componente visual.
Aunque pueda parecer contraintuitivo introducir un paso intermedio adicional, en la práctica este enfoque se convirtió en un potente acelerador. La homogeneidad visual deja de depender del criterio individual de cada desarrollador y pasa a estar garantizada por diseño. Resulta imposible introducir errores de espaciado, tipografía o estilos, ya que el desarrollador se limita a indicar qué elementos deben mostrarse, en qué orden y con qué valores.
La legibilidad del código mejora de forma notable. Los guiones son fáciles de leer, revisar y contrastar con el diseño funcional. La verificación visual se simplifica drásticamente y las pruebas de calidad se vuelven mucho más eficientes: al reutilizarse los mismos componentes instanciados desde un único punto, basta con validar un subconjunto reducido de vistas para obtener una cobertura prácticamente completa.
La accesibilidad pasa a gestionarse de forma transversal desde la librería de componentes. En lugar de revisar cientos de pantallas, solo es necesario asegurar que los componentes base implementan correctamente los requisitos, pudiendo incluso forzar campos obligatorios de accesibilidad desde el propio metalenguaje.
Este nuevo paradigma, no solo permitió abordar la migración completa de Mi Carpeta Ciudadana en un plazo asumible, sino que adelantó al desarrollo nativo. La reconstrucción funcional se completó en un tiempo equivalente a menos de dos evolutivos del desarrollo nativo, tras los cuales solo fue necesario un periodo adicional de evolutivos que se destinó a completar el ciclo completo de pruebas y auditorías de seguridad, necesarios para asegurar el mantenimiento de la calidad en la nueva aplicación.
Un simple cambio de perspectiva ha permitido disponer de una Carpeta Ciudadana completamente renovada, más homogénea, más accesible y mejor preparada para seguir evolucionando. Pero, sobre todo, se dispone de un nuevo modelo de desarrollo que transforma una tarea antes inabordable en un proceso sistemático, fiable y escalable.
Otro aspecto clave de esta solución, es su carácter transversal y su orientación a largo plazo. Al haberse desarrollado íntegramente en Dart puro, sin dependencias de librerías externas ni acoplamiento directo al SDK de Flutter, el modelo no queda ligado a una tecnología concreta ni a un único entorno de ejecución. En un contexto de rápida evolución tecnológica, esta decisión proporciona una elevada portabilidad y reduce el riesgo a medio y largo plazo. La separación entre la descripción de las vistas y su representación facilita una eventual migración hacia nuevos frameworks o entornos, así como la reutilización del modelo en otros proyectos o tecnologías.
La adopción de un sistema de generación de vistas basado en guiones no responde a la introducción de una nueva tecnología, sino a un cambio consciente de enfoque en la forma de diseñar y mantener servicios digitales de gran escala. Al trasladar la complejidad desde la construcción manual de interfaces al diseño del propio sistema, se reduce la variabilidad, se refuerza la calidad y se mejora de forma significativa la capacidad de evolución.
Con el horizonte de la Administración 2030, este tipo de soluciones apuntan a una dirección clara: menos complejidad interna, mayor automatización y sistemas diseñados para perdurar. Una Administración que construye plataformas robustas y reutilizables no solo optimiza el uso de los recursos públicos, sino que refuerza la calidad y la confianza de los servicios digitales ofrecidos a la ciudadanía.
