مدیریت پیکربندی در توسعه موبایل: چیست، چه گزینه‌هایی دارد و چگونه تنظیم کنیم

مدیریت پیکربندی در Android: Build Variant و build.gradle

Build Variant — ترکیبی از Build Type (debug/release/staging) و Product Flavor (free/paid، demo/full). Gradle به طور خودکار برای هر ترکیب variant ایجاد می‌کند: freeDebug، freeRelease، paidDebug، paidRelease. هر variant می‌تواند کد، منابع و وابستگی‌های خود را داشته باشد — این اساس مدیریت پیکربندی در برنامه‌های موبایل در Android است.

Build Variant در مقابل Product Flavor

Build Type — تنظیمات build: آیا اشکال‌زدایی فعال است، امضا، بهینه‌سازی ProGuard. debug به طور پیش‌فرض شامل debuggable=true است، release — minifyEnabled=true.

Product Flavor — نوع برنامه: رایگان (free)، پولی (paid)، دمو (demo). flavorها می‌توانند applicationId، منابع، وابستگی‌های SDK متفاوتی داشته باشند.

// build.gradle — پیکربندی flavorهای محصول در 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')
        }
    }
}

مثال دو flavor ایجاد می‌کند: free و paid. یک applicationId جداگانه برای free تنظیم شده است — این امکان نصب هر دو برنامه روی یک دستگاه را فراهم می‌کند. BuildConfig برای هر variant تولید می‌شود: BuildConfig.FLAVOR = "free"، BuildConfig.BUILD_TYPE = "debug". برای منطق شرطی از BuildConfig در کد استفاده کنید.

settings.gradle و Gradle KTS

settings.gradle — فایل ریشه Gradle که ماژول‌های پروژه را توصیف می‌کند.

Gradle KTS — جایگزینی برای Groovy با استفاده از Kotlin DSL. KTS تکمیل خودکار در Android Studio و بررسی نوع را فراهم می‌کند. برای پروژه‌های جدید توصیه می‌شود.

مدیریت پیکربندی در iOS: Scheme و .xcconfig

مدیریت پیکربندی در iOS بر Scheme استوار است — پیکربندی Xcode که مشخص می‌کند چه چیزی و چگونه ساخته شود: Build Configuration (Debug/Release)، آزمایش‌ها، تحلیل، بایگانی. Schemeها را می‌توان برای محیط‌های مختلف (Development، Staging، Production) کپی کرد. Schemeها در پوشه xcshareddata در فایل‌های .xcscheme ذخیره می‌شوند.

فایل‌های .xcconfig

.xcconfig — فایل پیکربندی Xcode که تنظیمات build را به صورت متنی ذخیره می‌کند. برای مدیریت پیکربندی برنامه‌های موبایل، iOS از .xcconfig استفاده می‌کند: نسخه‌گذاری در Git، استفاده مجدد بین پروژه‌ها، تنظیمات دستی کمتر. در .xcconfig مقادیر SWIFT_ACTIVE_COMPILATION_CONDITIONS، PRODUCT_BUNDLE_IDENTIFIER، CODE_SIGN_IDENTITY تنظیم می‌شوند.

Info.plist — فایل متادیتای برنامه. نسخه، شناسه، مجوزها را ذخیره می‌کند. Info.plist می‌تواند برای هر Scheme متفاوت باشد — از طریق Info.plist File در Build Settings.

AndroidManifest.xml — معادل Android: مجوزها، کامپوننت‌ها، متادیتا را ذخیره می‌کند.

Scheme در مقابل Build Configuration

Scheme — سناریوی build (چه کاری انجام دهیم). Build Configuration — مجموعه تنظیمات (چگونه انجام دهیم). یک Scheme از یک Build Configuration (Debug یا Release) استفاده می‌کند. برای CI/CD: اکشن Archive را روی Release و اکشن Test را روی Debug در یک Scheme تنظیم کنید.

مدیریت پیکربندی در Flutter و React Native: pubspec.yaml، Podfile، .env

pubspec.yaml — فایل پیکربندی پروژه Flutter. شامل وابستگی‌ها، نسخه‌ها، منابع است. از متغیرهای محیطی از طریق --dart-define پشتیبانی می‌کند.

Podfile — مدیر وابستگی CocoaPods برای iOS. نسخه‌های کتابخانه و پلتفرم را مشخص می‌کند.

.env — فایلی با متغیرهای محیطی برای همه پلتفرم‌ها. Flutter و React Native از رویکرد متفاوتی برای مدیریت پیکربندی استفاده می‌کنند: dart-define در Flutter، react-native-config در React Native. مدیریت پیکربندی در پروژه‌های چندپلتفرمی بسته به stack شامل ابزارهای مختلفی می‌شود.

.env و متغیرهای محیطی

.env — فایل متنی با جفت‌های کلید=مقدار. در Git commit نمی‌شود (به .gitignore اضافه کنید). برای Flutter — flutter_dotenv، برای iOS — Config.xcconfig با #include، برای Android — BuildConfig. متغیرهای env: API_URL، SENTRY_DSN، APP_SECRET. در مدیریت پیکربندی توسعه موبایل، .env استاندارد دوفاکتو برای ذخیره اسرار خارج از مخزن است.

Podfile و pubspec.yaml

Podfile وابستگی‌های CocoaPods و پلتفرم را توصیف می‌کند (platform :ios, '15.0'). pubspec.yaml برای Flutter — dependencies و dev_dependencies. هر دو از وابستگی‌های شرطی پشتیبانی می‌کنند: pod 'Analytics', :configs => ['Release'] یا flutter pub add --flavor free. در IT Sectr، ما از .env + BuildConfig برای اسرار و Podfile برای وابستگی‌های بومی در پروژه‌های موبایل استفاده می‌کنیم.

جدول تفاوت‌های اصلی در مدیریت پیکربندی بین پلتفرم‌های موبایل را نشان می‌دهد. Android انعطاف‌پذیری بیشتری از طریق Build Variant ارائه می‌دهد. iOS ساده‌تر است اما انعطاف‌پذیری کمتری دارد. Flutter پیکربندی را در dart-define متمرکز می‌کند، اما وابستگی‌های بومی هنوز نیاز به پیکربندی Podfile/build.gradle دارند.

کامپایل شرطی در مدیریت پیکربندی

کامپایل شرطی — شامل یا خارج کردن کد در زمان کامپایل بسته به پرچم‌ها. این بخشی از مدیریت پیکربندی است: امکان جاسازی ابزارهای اشکال‌زدایی (لاگینگ، بازرس) در buildهای debug و حذف آنها از release را فراهم می‌کند. پیاده‌سازی در پلتفرم‌های مختلف متفاوت است.

کامپایل شرطی در Swift

#if DEBUG — دستور پیش‌پردازنده Swift. کد داخل بلوک فقط در پیکربندی Debug کامپایل می‌شود. پرچم‌های دیگر: #if !RELEASE، #if targetEnvironment(simulator). Active Compilation Conditions در Build Settings — پرچم‌های سفارشی خود را از طریق -D FLAG_NAME اضافه کنید. مدیریت پیکربندی build از طریق شرایط کامپایل در iOS یک روش استاندارد است.

کامپایل شرطی در Kotlin

BuildConfig.DEBUG — فیلد بولی، در build debug true است. BuildConfig به طور خودکار توسط Gradle تولید می‌شود. برای پرچم‌های سفارشی از buildConfigField در build.gradle استفاده کنید: buildConfigField "boolean"، "REPORT_CRASHES"، "true". در کد: if (BuildConfig.REPORT_CRASHES) { ... }.

کامپایل شرطی در Flutter

dart-define — پرچم‌های کامپایل Flutter: flutter run --dart-define=ENV=staging. در کد: const env = String.fromEnvironment('ENV', defaultValue: 'production'). برای buildهای شرطی برنامه‌های موبایل، از پلاگین build_runner با تولید کد استفاده کنید.