Marketing Version: ما هو، الفرق عن Build Number والإعداد

ما هو Marketing Version

Marketing Version هي سلسلة دلالية تمثل إصدار التطبيق للمستخدم النهائي. في iOS يتم تعيينها عبر المفتاح CFBundleShortVersionString، وفي Android عبر versionName.

المصطلح «Marketing Version» يُستخدم رسمياً في Xcode: في واجهة إعدادات الهدف، يُسمى الحقل «Marketing Version»، وفي Info.plist يقابل CFBundleShortVersionString. في Android، المُكافئ هو versionName، وإن كان المصطلح يُستخدم بشكل أقل.

وفقاً لوثائق Apple Developer (2025)، يجب أن تتكون Marketing Version من ثلاثة أرقام كحد أقصى مفصولة بنقاط، بدون مسافات أو أحرف خاصة. يجب ألا يتجاوز كل رقم 255.

اختر Marketing Version لتعكس أهمية التغييرات: إصدارات رئيسية للتغييرات الجوهرية، وإصدارات ثانوية للوظائف الجديدة.

الفرق عن Build Number الداخلي

Marketing Version تختلف جوهرياً عن Build Number في الغرض: الأولى تُبلغ المستخدم، والثانية تُحدد الإصدار للمتجر. يمكن زيادة Build Number دون تغيير Marketing Version.

على سبيل المثال، عند إصلاح خطأ حرج في إصدار منشور، يمكن للفريق إعادة بناء التطبيق بنفس Marketing Version (1.2.0) ولكن مع Build Number أعلى (من 15 إلى 16). سيرى المستخدم نفس الإصدار، لكن المتجر سيعرف أن الإصدار أحدث.

هذه المرونة تسمح للمطورين بإصدار إصلاحات دون إبلاغ المستخدمين بتغيير الإصدار.

أين تظهر Marketing Version

Marketing Version تظهر في عدة نقاط رئيسية لتفاعل المستخدم مع التطبيق. في متجر التطبيقات، تكون مرئية في بطاقة التطبيق، وفي وصف التحديث، وفي سجل الإصدارات.

على الجهاز، تظهر Marketing Version في إعدادات النظام (قسم «حول» أو «التطبيقات»)، وفي مربعات حوار التحديث عبر App Store أو Google Play، وداخل التطبيق نفسه في شاشة «حول».

Marketing Version الواضحة تساعد المستخدم على تقييم مدى حداثة الإصدار المثبت واتخاذ قرار التحديث.

Marketing Version على iOS

على iOS، يتم تعيين Marketing Version في Xcode عبر حقل «Marketing Version» في علامة التبويب General من إعدادات الهدف. يتم حفظ القيمة في Info.plist كـ CFBundleShortVersionString.

تنسيق الإصدار منظم بدقة من قبل Apple: يجب أن تحتوي السلسلة على رقم إلى ثلاثة أرقام مفصولة بنقاط (مثلاً، 1، 1.2 أو 1.2.3). الحد الأقصى للطول هو 18 حرفاً. يجب ألا يتجاوز كل رقم 255.

وفقاً لإرشادات مراجعة App Store من Apple (2025)، لا يسمح App Store Connect برفع إصدار إذا كانت Marketing Version تختلف عن الإصدار المنشور السابق بأكثر من قيمة رئيسية أو ثانوية واحدة — وهذا يحمي المستخدمين من التحديثات المفقودة.

استخدم agvtool لإدارة Marketing Version من سطر الأوامر — فهذا يُبسط التكامل مع CI/CD ويضمن المزامنة مع Build Number.

Marketing Version على Android

على Android، يتم تعيين Marketing Version عبر المعامل versionName في ملف build.gradle. على عكس iOS، لا يفرض Android قيوداً صارمة على تنسيق سلسلة الإصدار.

versionName يمكن أن يحتوي على أي أحرف: حروف، أرقام، شرطات ونقاط. يعرض Google Play هذه السلسلة في بطاقة التطبيق وفي قائمة التحديثات، لكنه لا يتحقق من تطابقها مع أي نمط.

ومع ذلك، يوصي Google Play بالالتزام بالتنسيق الدلالي Major.Minor.Patch للتوحيد. هذا يُسهل فهم الإصدار للمستخدمين ويُتيح التحليل الآلي للتحديثات.

حدد versionName يعكس بوضوح نوع الإصدار — رئيسي، ثانوي أو تصحيحي. هذا يساعد المستخدمين على تقييم أهمية التغييرات بسرعة.

التوليد الديناميكي لـ versionName

versionName على Android يمكن توليده ديناميكياً بناءً على علامات Git أو متغيرات CI/CD. هذا يُبسط عملية الإصدار ويزيل التناقضات بين المستودع والإصدار.

النهج النموذجي هو قراءة علامة Git (مثلاً، v2.1.0) واستخدام قيمتها كـ versionName. إذا كانت العلامة غائبة، يمكن توليد إصدار بناءً على التاريخ ورقم الالتزام.

هذا النهج يضمن أن versionName يتطابق دائماً مع حالة الكود المصدري ولا يتطلب تحديثات يدوية.

Marketing Version مقابل Build Number

Marketing Version و Build Number هما معاملان مستقلان يؤديان مهاماً مختلفة. Marketing Version تُبلغ المستخدم، بينما Build Number يُحدد الإصدار تقنياً.

الفرق الرئيسي هو التفرد. Build Number يجب أن يكون فريداً لكل إصدار. Marketing Version يمكن تكرارها: إصدارات متعددة لنفس النسخة تشترك في نفس Marketing Version ولكن بأرقام Build مختلفة.

وفقاً لسياسة Google Play (2025)، إذا قمت برفع ملفي APK بنفس Marketing Version ولكن بأرقام Build مختلفة، سيقبل Google Play كليهما كإصدارين مختلفين لنفس النسخة. نفس القاعدة تنطبق على App Store.

تذكر: Build Number للآلات، Marketing Version للبشر. أتمت الأول وخطط للثاني بعناية.

استراتيجيات الإصدار

اختيار استراتيجية يعتمد على نوع التطبيق والجمهور وعملية الإصدار. ثلاثة أنظمة رئيسية —دلالي، تاريخي وهجين— تغطي معظم السيناريوهات.

الإصدار الدلالي (SemVer) يستخدم تنسيق Major.Minor.Patch ويُحدد بدقة متى يجب زيادة كل مكون. إنه مثالي للتطبيقات ذات API العام والتكامل المعقد.

وفقاً لموقع semver.org (2023)، إصدار 2.0.0 من مواصفة SemVer يُستخدم في 89% من مشاريع التطبيقات مفتوحة المصدر ومدعوم من جميع مديري الحزم.

الإصدار التاريخي

الإصدار التاريخي (CalVer) يستخدم تاريخ الإصدار كرقم إصدار — مثلاً، 25.06 لشهر يونيو 2025. هذا النهج شائع في التطبيقات ذات التحديثات المتكررة.

CalVer لا ينقل معلومات حول أهمية التغييرات، لكنه يُظهر بوضوح حداثة الإصدار. يفهم المستخدم فوراً أن الإصدار 25.06 أحدث من 25.03.

اختر الإصدار التاريخي إذا كان تطبيقك يُحدث بشكل متكرر ويهتم المستخدمون بحداثة البيانات أكثر من حجم التغييرات.

توصيات الاختيار

لـ MVPs والشركات الناشئة، الإصدار الدلالي البسيط بدون تصحيح (Major.Minor) مناسب. للمنتجات الناضجة ذات الدعم طويل الأمد —SemVer كامل. للتطبيقات ذات الإصدارات المستمرة —CalVer.

أبداً لا تستخدم التاريخ كـ Build Number — فقد يؤدي ذلك إلى تعارضات مع إصدارات متعددة في اليوم. Build Number يجب أن يكون تسلسلياً أو مركباً، لكن دائماً متزايداً بشكل رتيب.

أخطاء شائعة في Marketing Version

خطأ نموذجي هو تخطي مكون إصدار عند الانتقال إلى خط رئيسي جديد. على سبيل المثال، بعد الإصدار 1.9.9، التالي يجب أن يكون 2.0.0 وليس 1.10.0. هذا يكسر الدلالة ويُربك المستخدمين.

مشكلة أخرى شائعة هي عدم تطابق Marketing Version في الكود وفي متجر التطبيقات. تحقق دائماً من أن versionName في build.gradle يطابق الإصدار المحدد في Google Play Console أو App Store Connect قبل إرسال الإصدار للمراجعة.

أمثلة تكوين Marketing Version

أمثلة الكود تُظهر كيفية تعيين Marketing Version على كلا النظامين وأتمتة تحديثها.

تكوين versionName في Android Gradle

في Android، يتم تعيين versionName في build.gradle. يمكن أن تكون القيمة ثابتة أو تُقرأ من متغير بيئة.

android {
    defaultConfig {
        versionCode 15
        versionName "2.1.0"
    }
}

// قراءة الإصدار من علامة Git
def getVersionNameFromGit = {
    def tag = "git describe --tags".execute().
        text.trim()
    return tag.startsWith("v") ? tag.substring(1) : tag
}

versionName يُستخرج من علامة Git، مما يضمن التوافق بين إصدار المستودع والتطبيق المبني.

إدارة Marketing Version في Xcode

في iOS، يتم تعيين Marketing Version عبر Xcode أو agvtool. الأمر أدناه يُحدد إصدار تسويقي جديد.

# تعيين Marketing Version
xcrun agvtool new-marketing-version 2.1.0

# زيادة تلقائية
xcrun agvtool next-marketing-version

agvtool يُحدث Info.plist تلقائياً ويُزامن الإصدار عبر جميع أهداف مشروع Xcode.

Fastlane لكلا النظامين

Fastlane يُتيح إدارة Marketing Version على كلا النظامين من سكريبت واحد، مما يُبسط صيانة المشاريع متعددة المنصات.

# تعيين الإصدار التسويقي
increment_version_number(
    version_number: "2.1.0"
)

# زيادة تلقائية للإصدار الثانوي
increment_version_number(
    bump_type: "minor"
)

Fastlane يعمل على كلا النظامين ومدعوم من معظم خدمات CI/CD.