Gestión de configuraciones en desarrollo móvil: qué es, qué opciones hay y cómo configurarla

Gestión de configuraciones en Android: Build Variant y build.gradle

Build Variant — una combinación de Build Type (debug/release/staging) y Product Flavor (free/paid, demo/full). Gradle crea automáticamente un variant para cada combinación: freeDebug, freeRelease, paidDebug, paidRelease. Cada variant puede tener su propio código, recursos y dependencias — esta es la base de la gestión de configuraciones en aplicaciones móviles en Android.

Build Variant vs Product Flavor

Build Type — configuraciones de compilación: si la depuración está habilitada, firma, optimización ProGuard. debug por defecto contiene debuggable=true, release — minifyEnabled=true.

Product Flavor — variante de la aplicación: gratuita (free), de pago (paid), demo. Los flavours pueden tener diferentes applicationId, recursos y dependencias de SDK.

// build.gradle — configuración de flavours de producto en Android
android {
    productFlavors {
        free {
            applicationId "com.example.app.free"
            versionName "1.0-free"
        }
        paid {
            applicationId "com.example.app.paid"
            versionName "1.0-paid"
        }
    }
    buildTypes {
        release {
            minifyEnabled true
            proguardFiles getDefaultProguardFile('proguard-android.txt')
        }
    }
}

El ejemplo crea dos flavours: free y paid. Se establece un applicationId separado para free — esto permite instalar ambas aplicaciones en un mismo dispositivo. BuildConfig se genera para cada variant: BuildConfig.FLAVOR = "free", BuildConfig.BUILD_TYPE = "debug". Utilice BuildConfig en el código para lógica condicional.

settings.gradle y Gradle KTS

settings.gradle — el archivo raíz de Gradle que describe los módulos del proyecto.

Gradle KTS — una alternativa a Groovy usando Kotlin DSL. KTS proporciona autocompletado en Android Studio y verificación de tipos. Recomendado para proyectos nuevos.

Gestión de configuraciones en iOS: Scheme y .xcconfig

La gestión de configuraciones en iOS se basa en Scheme — una configuración de Xcode que define qué y cómo compilar: Build Configuration (Debug/Release), pruebas, análisis, archivado. Los esquemas se pueden duplicar para diferentes entornos (Development, Staging, Production). Los esquemas se almacenan en archivos .xcscheme en la carpeta xcshareddata.

Archivos .xcconfig

.xcconfig — un archivo de configuración de Xcode que almacena la configuración de compilación en formato de texto. Para la gestión de configuraciones en aplicaciones móviles, iOS utiliza .xcconfig: versionado en Git, reutilización entre proyectos, menos configuraciones manuales. En .xcconfig se definen SWIFT_ACTIVE_COMPILATION_CONDITIONS, PRODUCT_BUNDLE_IDENTIFIER, CODE_SIGN_IDENTITY.

Info.plist — el archivo de metadatos de la aplicación. Almacena la versión, el identificador, los permisos. Info.plist puede ser diferente para cada Scheme — a través de Info.plist File en Build Settings.

AndroidManifest.xml — el equivalente en Android: almacena permisos, componentes, metadatos.

Scheme vs Build Configuration

Scheme — el escenario de compilación (qué hacer). Build Configuration — el conjunto de configuraciones (cómo hacerlo). Un Scheme utiliza una Build Configuration (Debug o Release). Para CI/CD: configure la acción Archive en Release y la acción Test en Debug en un mismo Scheme.

Gestión de configuraciones en Flutter y React Native: pubspec.yaml, Podfile, .env

pubspec.yaml — el archivo de configuración del proyecto Flutter. Contiene dependencias, versiones, recursos. Admite variables de entorno a través de --dart-define.

Podfile — el gestor de dependencias CocoaPods para iOS. Define las versiones de las librerías y la plataforma.

.env — un archivo con variables de entorno para todas las plataformas. Flutter y React Native utilizan un enfoque diferente para la gestión de configuraciones: dart-define en Flutter, react-native-config en React Native. La gestión de configuraciones en proyectos multiplataforma involucra diferentes herramientas según el stack.

.env y Variables de Entorno

.env — un archivo de texto con pares clave=valor. No se sube a Git (añadir a .gitignore). Para Flutter — flutter_dotenv, para iOS — Config.xcconfig con #include, para Android — BuildConfig. Variables de entorno: API_URL, SENTRY_DSN, APP_SECRET. En la gestión de configuraciones en desarrollo móvil, .env es el estándar de facto para almacenar secretos fuera del repositorio.

Podfile y pubspec.yaml

Podfile describe las dependencias de CocoaPods y la plataforma (platform :ios, '15.0'). pubspec.yaml para Flutter — dependencies y dev_dependencies. Ambos admiten dependencias condicionales: pod 'Analytics', :configs => ['Release'] o flutter pub add --flavor free. En IT Sectr, utilizamos .env + BuildConfig para secretos y Podfile para dependencias nativas en proyectos móviles.

La tabla muestra las diferencias clave en la gestión de configuraciones entre plataformas móviles. Android ofrece más flexibilidad a través de Build Variant. iOS es más simple pero menos flexible. Flutter centraliza la configuración en dart-define, pero las dependencias nativas aún requieren configurar Podfile/build.gradle.

Compilación condicional en la gestión de configuraciones

Compilación condicional — inclusión o exclusión de código en tiempo de compilación según banderas. Esto es parte de la gestión de configuraciones: permite integrar herramientas de depuración (registro, inspector) en compilaciones debug y eliminarlas de release. La implementación difiere entre plataformas.

Compilación condicional en Swift

#if DEBUG — directiva de preprocesador de Swift. El código dentro del bloque se compila solo en la configuración Debug. Otras banderas: #if !RELEASE, #if targetEnvironment(simulator). Active Compilation Conditions en Build Settings — añada banderas personalizadas mediante -D FLAG_NAME. La gestión de configuraciones de compilación mediante condiciones de compilación es una práctica estándar en iOS.

Compilación condicional en Kotlin

BuildConfig.DEBUG — campo booleano, true en compilación debug. BuildConfig lo genera Gradle automáticamente. Para banderas personalizadas use buildConfigField en build.gradle: buildConfigField "boolean", "REPORT_CRASHES", "true". En código: if (BuildConfig.REPORT_CRASHES) { ... }.

Compilación condicional en Flutter

dart-define — banderas de compilación de Flutter: flutter run --dart-define=ENV=staging. En código: const env = String.fromEnvironment('ENV', defaultValue: 'production'). Para compilaciones condicionales de aplicaciones móviles, use el plugin build_runner con generación de código.