Build Config في التطبيقات المحمولة — ما هو، الإعداد ومبدأ العمل

ما هو Build Config في التطوير المحمول

Build Config هو مجموعة من الإعدادات التي تحدد عملية الترجمة والبناء والتغليف لتطبيق محمول. تشمل تهيئة البناء اختيار المنصة المستهدفة، الحد الأدنى لإصدار SDK، أعلام التحسين، مفاتيح التوقيع ومتغيرات البيئة.

نادراً ما تحتوي المشاريع المحمولة الحديثة على تهيئة بناء واحدة. عادة ما يكون لديها عدة: debug (للتطوير مع التصحيح)، release (للإنتاج مع التحسين)، staging (للاختبار مع بيانات حقيقية) ونكهات مختلفة (تجريبي، كامل، مؤسسي).

وفقاً لاستطلاع Gradle Build Tool Survey (2025)، متوسط مشروع Android يستخدم 3.2 تهيئة بناء مختلفة، بينما مشروع iOS يستخدم 2.8. كل تهيئة يمكن أن يكون لها أعلام الترجمة الخاصة بها، شهادات التوقيع وعناوين URL للخوادم.

المهمة الرئيسية لـ Build Config هي أتمتة التبديل بين هذه التهيئات. بدلاً من تغيير عنوان URL للخادم أو علم التصحيح يدوياً، يختار المطور Build Variant المطلوب في IDE، ويقوم نظام البناء باستبدال المعلمات المقابلة.

الإعداد الصحيح لـ Build Config يؤثر بشكل حاسم على أمن التطبيق: builds التصحيح تتضمن سجلات مفصلة، مفحص قاعدة البيانات ونقاط نهاية تصحيح يجب استبعادها فعلياً من الملف الثنائي release. Gradle يحل هذا من خلال Build Types: debug يمكن أن يحتوي على علم debuggable true، release — minifyEnabled true مع ProGuard. iOS يحقق نفس الشيء من خلال Swift Active Compilation Conditions، حيث أن الكود داخل #if DEBUG لا يتم ترجمته في تهيئة release.

Build Config في Android: Gradle و BuildConfig

Android يستخدم نظام البناء Gradle مع مفهومين رئيسيين: Build Types و Product Flavors. مجموعهما يشكل Build Variants — كل متغير له تهيئة بناء كاملة خاصة به.

Build Types: Debug و Release

Build Type هو تهيئة تحدد كيف يتم بناء التطبيق. افتراضياً، ينشئ Gradle نوعين: debug (مع التصحيح، دون تشويش) و release (مع ProGuard/R8، موقع للنشر). يمكن للمطور إضافة أنواعه الخاصة: staging, benchmark, qa.

// build.gradle.kts
android {
    buildTypes {
        debug {
            isDebuggable = true
            buildConfigField("String", "API_URL", "\"http://dev.api.com\"")
        }
        release {
            isMinifyEnabled = true
            proguardFiles(
                getDefaultProguardFile("proguard-android-optimize.txt"),
                "proguard-rules.pro"
            )
            buildConfigField("String", "API_URL", "\"https://prod.api.com\"")
        }
    }
}

Product Flavors: إصدارات التطبيق

Product Flavors تسمح بإنشاء إصدارات مختلفة من نفس التطبيق من قاعدة كود واحدة. مثلاً: نسخة مجانية مع إعلانات، نسخة مدفوعة بدون إعلانات ونسخة مؤسسية مع ميزات إضافية. كل نكهة يمكن أن يكون لها applicationId خاص بها، موارد وتبعيات SDK.

android {
    productFlavors {
        register("demo") {
            applicationId = "com.example.app.demo"
            versionNameSuffix = "-demo"
        }
        register("full") {
            applicationId = "com.example.app"
            versionNameSuffix = ""
        }
    }
}

صنف BuildConfig: الوصول من الكود

لكل Build Variant، ينشئ Gradel صنف BuildConfig بحقول التهيئة. يضيف المطور حقولاً مخصصة عبر buildConfigField، بينما الحقول القياسية (DEBUG, APPLICATION_ID, BUILD_TYPE, VERSION_CODE, FLAVOR) تُنشأ تلقائياً.

// استخدام BuildConfig في الكود
class NetworkModule {
    fun createApiClient(): ApiClient {
        return if (BuildConfig.DEBUG) {
            ApiClient(
                baseUrl = BuildConfig.API_URL,
                interceptor = HttpLoggingInterceptor()
            )
        } else {
            ApiClient(baseUrl = BuildConfig.API_URL)
        }
    }
}

BuildConfig أيضاً يسمح بتمكين أو تعطيل الوظائف في وقت البناء. مثلاً، يمكن إضافة حقل FEATURE_CHAT_ENABLED وتفعيل الدردشة فقط في النسخة الكاملة من التطبيق، دون فحوصات وقت التشغيل وعوامل شرطية في الكود.

لتصحيح طلبات الشبكة، BuildConfig مع حقل DEBUG يسمح بإرفاق HttpLoggingInterceptor في OkHttp تلقائياً فقط لبناءات debug. هذا يضمن عدم تسجيل أي طلب HTTP في الإنتاج، حتى لو نسي المطور إزالة التسجيل قبل بناء الإصدار release.

Build Config في iOS: Xcode و Build Settings

في نظام iOS البيئي، Build Config يُدار من خلال Xcode Build Settings — جدول معلمات حيث كل معلمة يمكن أن يكون لها قيم مختلفة لتهيئات مختلفة (Debug, Release, Staging).

تهيئات Xcode Build

افتراضياً، ينشئ Xcode تهيئتين: Debug (للتطوير، دون تحسينات) و Release (للإنتاج، مع تحسين -Os). يمكن للمطور إضافة تهيئاته الخاصة من خلال قائمة Project > Info > Configurations.

لكل تهيئة، يتم إعداد Build Settings: أعلام المترجم (OTHER_SWIFT_FLAGS, GCC_PREPROCESSOR_DEFINITIONS)، كود التوقيع (CODE_SIGN_IDENTITY)، ملفات التزويد والصلاحيات. Xcode يكتب هذه الإعدادات في ملف project.pbxproj.

xcconfig: ملفات تهيئة خارجية

لإدارة مريحة لـ Build Settings، مطورو iOS يستخدمون ملفات .xcconfig — ملفات نصية مع معلمات بتنسيق KEY = VALUE. هذه مشابهة لـ .env في Xcode: القيم تُربط بالمشروع وتتجاوز الإعدادات في project.pbxproj.

// Debug.xcconfig
BUNDLE_ID_SUFFIX = .debug
API_BASE_URL = http://localhost:8080
SWIFT_ACTIVE_COMPILATION_CONDITIONS = DEBUG
CODE_SIGN_IDENTITY = Apple Development

// Release.xcconfig
BUNDLE_ID_SUFFIX =
API_BASE_URL = https://api.production.com
SWIFT_ACTIVE_COMPILATION_CONDITIONS =
CODE_SIGN_IDENTITY = Apple Distribution

Info.plist: تهيئة وقت التشغيل

جزء من معلمات Build Config يصل إلى Info.plist — ملف بيان تطبيق iOS. من خلال Info.plist يتم إعداد مخططات URL، الأذونات (الكاميرا، الميكروفون)، أوضاع الخلفية وتهيئة تسجيل الدخول عبر خدمات الطرف الثالث.

قيم xcconfig يمكن استبدالها في Info.plist باستخدام الصياغة $(VARIABLE_NAME). مثلاً، $(API_BASE_URL) في Info.plist سيتوسع وفقاً لتهيئة البناء النشطة. هذا يمركز إدارة معلمات البيئة لجميع منصات Apple.

Build Config في خطوط أنابيب CI/CD

في المشاريع الحديثة، Build Config يتكامل مع أنظمة التكامل المستمر: GitLab CI, GitHub Actions, Bitrise, CircleCI. كل خط أنابيب يمكنه تجاوز معلمات Build Config من خلال متغيرات البيئة لنظام CI/CD.

Gradle Build Config في CI

لـ Android، خط أنابيب CI يشغل Gradle مع Build Variant المحدد: ./gradlew assembleFullRelease. معلمات التوقيع تُمرر عبر متغيرات CI: STORE_PASSWORD, KEY_ALIAS. Gradle يقرأها من بيئة التشغيل ويستبدلها في build.gradle.kts.

// build.gradle.kts — القراءة من متغيرات CI
android {
    signingConfigs {
        register("release") {
            storeFile = file(System.getenv("KEYSTORE_PATH") ?: "debug.keystore")
            storePassword = System.getenv("STORE_PASSWORD") ?: ""
            keyAlias = System.getenv("KEY_ALIAS") ?: "key"
            keyPassword = System.getenv("KEY_PASSWORD") ?: ""
        }
    }
}

Xcode Build Config في CI

لـ iOS، CI يستخدم xcodebuild مع أعلام التهيئة: -configuration Release. شهادات التوقيع تُسلم عبر أسرار CI، والملفات عبر Apple Developer Portal API أو Fastlane match.

أداة Fastlane تؤتمت إدارة Build Config: توليد xcconfig، تحديث الإصدارات في Info.plist، توقيع IPA المبنية ورفعها إلى App Store Connect. Fastlane gym (بناء) و match (توقيع) هما المعيار لخطوط أنابيب CI في iOS.

وفقاً لتقرير Bitrise Build Report (2025)، المشاريع التي تحتوي على Build Config مهيأ في CI تقلل وقت الإعداد اليدوي للبناء بنسبة 73% وتقلل أخطاء التوقيع بنسبة 89%. Build Config المؤتمت هو عنصر إلزامي لخط أنابيب جاهز للإنتاج.

جانب مهم آخر هو معايرة الإصدار من خلال Build Config. Gradle يسمح بقراءة versionCode و versionName من متغيرات CI واستبدالها في build.gradle.kts ديناميكياً، مما يلغي عدم تزامن الإصدارات بين المطورين. في iOS، مهمة مماثلة تُحل من خلال agvtool (Apple Generic Versioning Tool)، الذي يمكنه زيادة رقم البناء بناءً على علامات git أو رقم البناء في CI.