Lo que MENOS me gusta de Flutter son "Las Actualizaciones" + Consejos

Lo que me molesta mucho sobre el ecosistema de Flutter es Android, las benditas actualizaciones.
 

Tengo la compulsión de mantener todo actualizado y corro comandos varias veces por semana. Mantengo SDKs, paquetes y Android Studio al día. El detalle es que de un día para otro un proyecto que funcionaba deja de hacerlo.

flutter upgrade

entre otros.

Por ejemplo, en Windows un proyecto de la academia me corría perfecto, pero en MacOS no. Antes era al revés: en Mac funcionaba y en Windows no. Y todo esto solo por diferencias de versiones y actualizaciones.

Errores, versiones, dependencias y +

• Estos problemas suelen venir acompañados de errores muy verbosos. Por ejemplo, en Windows tuve un conflicto con un paquete (WYSIWYG editor), que luego actualizaron. También me ha pasado con el SDK de Android: versiones 35 y 36 causando advertencias y fallos.
• Muchas veces no se entiende qué está pasando. Termino rastreando archivos, revisando dependencias internas del proyecto, como archivos gradle principalmente, versionamientos con el android SDK o el Flutter SDK o el pubspec.yaml o .lock.
• Sin contar que internamente van actualizando el proyecto en Android con otras sintaxis o directamente tipado de los archivos, un ejemplo de esto ultimo es el build.gradle.kts cuya extensión para Kotlin, kts en versiones más antiguas, no venia incluida.

Es muy molesto porque no son proyectos “antiguos”, sino relativamente recientes. Pero las actualizaciones los vuelven incompatibles. Y aquí aparece el dilema:

• O intentas actualizar manualmente, rezando para no olvidar nada.
• O creas un proyecto nuevo en Flutter y empiezas a copiar/pegar todo, con el riesgo de dejar algo fuera (como me pasó una vez con el AndroidManifest).
• Por eso pienso que debería existir un comando que actualice proyectos automáticamente. Hacerlo a mano es fastidioso y consume demasiado tiempo.

Entonces en conclusion, el problema de Flutter no es la codificación o el lenguaje de programación, el veneno lo lleva internamente el mismo proyecto, al no actualizarse automáticamente a medida que se van lanzando nuevas actualizaciones sobre las technologies relacionadas.

La forma inteligente de actualizar Flutter sin romper tu aplicación

Uno de los puntos más críticos al trabajar con Flutter radica en la gestión de sus actualizaciones. Aunque es un framework robusto, la evolución de sus versiones suele acarrear problemas de compatibilidad que pueden romper un proyecto existente. Este fenómeno no es exclusivo de Flutter; frameworks de backend como Laravel también enfrentan desafíos similares debido a su rápida evolución, provocando desajustes en aplicaciones que quedan desactualizadas.

Para comprender la raíz de este problema en Flutter, es fundamental analizar su arquitectura interna. Flutter permite desarrollar un único código base en Dart y exportarlo de forma nativa a múltiples plataformas: Android, iOS, Web y entornos de escritorio (Windows, Linux y macOS). Por esta razón, la estructura de un proyecto incluye carpetas dedicadas a cada sistema operativo (/android, /ios, /web, etc.). Estas carpetas no son meros contenedores; albergan los entornos nativos necesarios para la compilación final.

La Dependencia de Entornos Nativos

Debido a esta arquitectura, Flutter depende obligatoriamente de las herramientas específicas de cada plataforma para compilar el código nativo:

• Android: Requiere Android Studio, su SDK, Command Line Tools y Gradle.
• iOS: Requiere Xcode y las herramientas de desarrollo de Apple.
• Windows: Requiere módulos específicos de Visual Studio (C++).

El verdadero conflicto surge porque estas plataformas nativas evolucionan de forma independiente a Flutter. Tomando como ejemplo a Android, el sistema operativo actualiza constantemente sus niveles de SDK, versiones de Java y herramientas de compilación. Cuando se actualiza el SDK de Flutter mediante el comando flutter upgrade, es muy probable que se rompa la sincronización con el entorno nativo subyacente.

El Rol Crítico de Gradle en Android

En el ecosistema de Android, la configuración y el éxito de la compilación dependen principalmente de tres archivos gestionados por Gradle. Cuando un proyecto tiene varios meses o años de antigüedad, las versiones de estos archivos entran en conflicto con las directrices del nuevo SDK de Flutter:

1. build.gradle (Raíz del proyecto Android): Define los repositorios y las versiones globales de los plugins de Gradle.
2. build.gradle (Directorio /app): Especifica las versiones de compileSdkVersion, minSdkVersion y targetSdkVersion.
3. gradle-wrapper.properties: Determina la versión exacta del motor de Gradle que descargará el sistema para compilar.

Históricamente, resolver estos conflictos requería un proceso de ensayo y error tedioso: buscar compatibilidades de versiones en repositorios oficiales, limpiar la caché del proyecto mediante flutter clean o ejecutar comandos nativos como gradlew clean. Además, los cambios sintácticos introducidos en las herramientas de compilación —como la transición de archivos de configuración tradicionales basados en Groovy hacia el formato moderno KTS (Kotlin Script)— elevan la complejidad del mantenimiento manual.

Antiguo:

android/build.gradle

allprojects {
    repositories {
        google()
        mavenCentral()
    }
}

rootProject.buildDir = '../build'

Moderno:

android/build.gradle.kts

allprojects {
    repositories {
        google()
        mavenCentral()
    }
}

val newBuildDir: Directory = rootProject.layout.buildDirectory.dir("../../build").get()
rootProject.layout.buildDirectory.value(newBuildDir)

Estrategias de Solución y Mitigación

Para resolver estas desincronizaciones sin comprometer la estabilidad del desarrollo, se pueden aplicar tres enfoques estratégicos:

A. Diagnóstico asistido por Inteligencia Artificial

Actualmente, el uso de modelos de lenguaje facilita la resolución de errores de compilación verbosos. Al proporcionar el log completo del error generado por Gradle a la IA, esta suele identificar con precisión la incompatibilidad exacta y sugerir los rangos de versiones correctos para los archivos de configuración.

B. Regeneración Selectiva de la Carpeta Nativa (Enfoque Recomendado)

A menos que se esté implementando código nativo a medida, la carpeta /android no suele modificarse manualmente, salvo por configuraciones en el archivo AndroidManifest.xml (permisos de internet, llaves de AdMob, servicios de notificaciones, etc.). Por lo tanto, una solución eficiente consiste en sustituir la estructura nativa obsoleta por una limpia:

• Asegurar los cambios actuales realizando un git commit o copia de seguridad.
• Renombrar la carpeta /android conflictiva (por ejemplo, a /android_old) para conservarla como referencia.
• Generar un nuevo proyecto de Flutter en un directorio temporal utilizando el mismo nombre de paquete (Package Name) para heredar la carpeta /android actualizada y compatible con el nuevo SDK.
• Copiar esta carpeta limpia al proyecto original y migrar únicamente las líneas de configuración específicas (como los permisos del AndroidManifest.xml) desde la carpeta antigua.

C. Migración Completa a un Proyecto Espejo

Si la sustitución de carpetas genera conflictos de dependencias persistentes, la solución definitiva consiste en crear un proyecto completamente nuevo desde cero. Posteriormente, se realiza la migración manual del directorio de código fuente principal (/lib) y las declaraciones de dependencias dentro del archivo pubspec.yaml, garantizando así un entorno de compilación totalmente depurado.

El Infierno de Actualizar Flutter: El Costo Oculto de Mantener Aplicaciones en Android

Anteriormente, te hablaba de una de las características que menos me gustan de Flutter: la enorme complejidad que implica actualizar y mantener un proyecto con el paso del tiempo. A raíz de una experiencia reciente con Google Play, quiero traer este tema a colación para ofrecer un contexto global a quienes están comenzando a desarrollar aplicaciones con este framework.

No se trata de criticar la tecnología por el simple hecho de hacerlo, sino de analizar situaciones reales que debemos afrontar debido a la flexibilidad y la arquitectura del propio ecosistema de Flutter.

1. La Presión de Google Play y las Actualizaciones Obligatorias

En el desarrollo web con tecnologías como Laravel, Node o Python, actualizar la versión del framework suele ser una decisión opcional. Si un servidor ejecuta una aplicación en un rango de versiones estable, el proyecto puede funcionar durante años sin necesidad de tocar el código base.

En Flutter, enfocado principalmente en el desarrollo móvil para Android e iOS, la actualización es prácticamente obligatoria. Google Play impone fechas límite estrictas sobre el nivel de API objetivo (Target SDK) y las versiones mínimas de las bibliotecas internas (como la API de facturación para compras in-app).

El problema del margen de tiempo: Google suele enviar notificaciones con plazos reducidos —a menudo durante periodos festivos o de vacaciones— advirtiendo que, si la aplicación no se actualiza antes de una fecha determinada, será despublicada de la tienda.

2. La Estrategia de Mantenimiento: El Proyecto Paralelo

Intentar resolver los errores de compilación directamente sobre un proyecto antiguo puede convertirse en un proceso frustrante debido a la incompatibilidad entre el SDK de Flutter, las versiones de Gradle, Kotlin y las dependencias nativas del sistema operativo.

Para evitar conflictos masivos de configuración, la metodología más eficiente consiste en regenerar la estructura nativa mediante un proyecto auxiliar como te comentaba antes:

1. Creación del proyecto base: Generar un proyecto totalmente nuevo en Flutter con el mismo nombre y configuración general.
2. Respaldar la estructura nativa: Renombrar la carpeta android del proyecto original a modo de copia de seguridad.
3. Sustitución de la carpeta nativa: Copiar la carpeta android limpia generada por el nuevo proyecto hacia el proyecto principal.
4. Reorganización de referencias: Reaplicar manualmente las configuraciones específicas de producción (permisos en el AndroidManifest.xml, firmas de compilación, claves de API y configuraciones de Gradle).

Este procedimiento garantiza que la estructura de Gradle (incluyendo la transición de scripts .gradle a Kotlin DSL .kts) y las variables de entorno de Java/JDK utilicen los estándares vigentes del framework.

3. Incompatibilidad de Dependencias en Pub.dev

Incluso tras estabilizar el entorno nativo de Android, surge el segundo gran obstáculo: la gestión de paquetes externos mediante pubspec.yaml. El ritmo acelerado de cambios en la plataforma móvil provoca que múltiples paquetes comunitarios queden desactualizados o dejen de ser compatibles con las últimas versiones de Android.

• Falta de indicadores de obsolescencia: La plataforma oficial pub.dev muestra métricas como descargas o puntuación, pero no advierte de forma explícita si un paquete es incompatible con las versiones recientes de Android o iOS.
• Refactorización de código: Si un paquete queda abandonado, el desarrollador se ve obligado a buscar una alternativa equivalente y reescribir la lógica asociada en el proyecto.
• Conflictos de versionado estricto: Definir versiones fijas y absolutas para las dependencias puede postergar los errores, pero provocará un fallo masivo en cadena al momento de realizar una actualización mayor del sistema.

Conclusión

La versatilidad de Flutter para compilar en múltiples plataformas es su mayor virtud, pero también su mayor exigencia técnica en términos de mantenimiento. Mantener una aplicación móvil al día exige una monitorización constante de las políticas de las tiendas, una gestión cuidadosa de las dependencias nativas y una estrategia clara para la migración de código.