نشر تطبيق Flutter على Play Store وApp Store: دليل خطوة بخطوة

يمثل applicationId (على Android) وBundle ID (على iOS) الهوية الدائمة لتطبيقك في كل متجر؛ ولا يمكن تغيير أي منهما بعد أول عملية رفع. حدد الاثنين بشكل نهائي قبل بدء النشر — فتغييرهما لاحقًا يعني فتح قائمة جديدة تمامًا من الصفر، وفقدان تقييماتك وعدد تثبيتاتك الحاليين.

في Flutter، يوجد رقم الإصدار في حقل version: x.y.z+N داخل pubspec.yaml؛ x.y.z هو الإصدار الظاهر للمستخدم، وN هو رقم البناء (build number) الذي يقابل في آنٍ واحد كلًا من Android versionCode وiOS build number. الرفع دون زيادة N في كل تقديم جديد للمتجر يؤدي إلى الرفض.

تختلف متطلبات الأيقونة بين المتجرين: يطلب Play أيقونة عالية الدقة بمقاس 512×512 بكسل مع قناة ألفا (شفافية)، بينما يتوقع App Store ملف PNG بمقاس 1024×1024 بكسل بدون قناة ألفا. باستخدام حزمة flutter_launcher_icons يمكنك توليد كلتيهما من صورة مصدر واحدة بأمر واحد.

ينتج أمر flutter build appbundle --release الحزمة الجاهزة للمتجر في المسار build/app/outputs/bundle/release/app-release.aab. لم يعد Play Store يقبل الآن إلا صيغة .aab للرفعات الجديدة؛ فلا حاجة لإنتاج ملف .apk منفصل.

يجب على حسابات Play Console الشخصية (الفردية) التي فُتحت بعد 13 نوفمبر 2023 إكمال اختبار مغلق متواصل لمدة 14 يومًا بمشاركة 12 مختبِرًا نشطًا على الأقل قبل الحصول على وصول الإنتاج (production). لا ينطبق هذا الشرط على حسابات المؤسسات أو الحسابات الشخصية التي فُتحت قبل ذلك التاريخ؛ تحقق من الشرط الحالي في Play Console قبل التقديم لأن القاعدة تتغير من وقت لآخر.

يجب دائمًا رفع أول ملف .aab يُرفع إلى Play Console لتطبيق ما يدويًا — لا يُسمح باستخدام CLI أو التقديم الآلي لهذا الملف تحديدًا؛ أما الإصدارات اللاحقة فيمكن أن تستخدم CLI أو تكاملك الخاص. عند الانتقال إلى الإنتاج، يقلل البدء بطرح تدريجي (مثلًا 5-20% في البداية ثم الزيادة مع مراقبة Android vitals) بدلًا من الإصدار لجميع المستخدمين دفعة واحدة من المخاطر.

ينتج أمر flutter build ipa --release ملف .ipa جاهزًا للنشر ضمن المسار build/ios/ipa/. تتطلب أرشفة هذا البناء وإرساله إلى App Store Connect جهاز Mac (فعلي أو سحابي)؛ فـ Xcode لا يعمل على Windows أو Linux. إن لم يكن لديك جهاز Mac، فخدمات CI السحابية مثل Codemagic أو أجهزة macOS ضمن GitHub Actions أو MacStadium خيارات متاحة.

يمكنك رفع ملف .ipa الناتج إلى App Store Connect إما عبر مسار Xcode Organizer (Window > Organizer > Archives > Distribute App) أو عبر تطبيق Transporter المستقل؛ وكلاهما يعطي النتيجة نفسها. أما Version (الظاهر للمستخدم) وbuild number (يجب أن يكون فريدًا ومتصاعدًا مع كل رفع، ولا يمكن إعادة استخدامه ضمن نفس الإصدار) فهما حقلان منفصلان.

توفر TestFlight مستويين للاختبار: الاختبار الداخلي (حتى 100 شخص ضمن فريق App Store Connect لديك) لا يتطلب مراجعة من Apple ويكون متاحًا بمجرد انتهاء معالجة البناء. أما الاختبار الخارجي فيستهدف مختبِرين ينضمون عبر البريد الإلكتروني أو رابط عام (حتى 10,000 لكل مجموعة)؛ ويجب أن يجتاز أول بناء يُضاف إلى التطبيق مراجعة "beta review" من Apple (وعادة ما تكتمل خلال يوم واحد)، في حين قد لا تتطلب البنايات اللاحقة مراجعة كاملة.

على Play، حدود الأحرف صارمة: اسم التطبيق حتى 30 حرفًا، الوصف القصير حتى 80 حرفًا، والوصف الكامل حتى 4000 حرف. أما على App Store Connect، فيجب أن يكون اسم التطبيق فريدًا في المتجر بأكمله، وهناك أيضًا حقل عنوان فرعي (subtitle) وحقل كلمات مفتاحية يجب تعبئتهما. مقاسات لقطات الشاشة (1080×1920 للقطات هاتف Play، ومطابقة بكسل دقيقة لفئة آيفون 6.9 بوصة في App Store) تخضع لقواعد مختلفة في كل متجر.

يطلب كلا المتجرين منك الإفصاح عن سلوك جمع البيانات: نموذج Data safety في Play، وعلامات App Privacy في App Store (يُطلق عليها أحيانًا "بطاقة التغذية"). إذا كنت تستخدم SDK إعلانيًا أو تحليلات أو تقارير أعطال، يجب تحديد ذلك بدقة في كليهما؛ ولا تسمح أي من اللوحتين بالنشر دون رابط سياسة خصوصية قابل للوصول فعليًا ومحدّث.

تطلب كلتا اللوحتين أيضًا حقل دعم/تواصل: في Play، بريد دعم على مستوى الحساب وحقل موقع إلكتروني اختياري؛ وفي App Store Connect، رابط Support URL إلزامي ورابط Marketing URL اختياري. إذا لم يكن لديك موقع إلكتروني لهذه الحقول، فنحن نتناول خيارات عملية في مقال منفصل.

أكثر أسباب رفض Apple شيوعًا هي: البند 2.1(a) (الأعطال، الشاشات الفارغة، الروابط المعطلة، الميزات الناقصة غير المُصرَّح بها، أو عدم ترك حساب تجريبي عامل في ملاحظات المراجعة لميزة تتطلب تسجيل الدخول)، والبند 5.1.1 (نصوص وصف استخدام الأذونات فارغة أو غامضة)، والبند 4.3 (تطبيقات قوالب يُعاد تقديمها بتعديلات طفيفة). اختبار التطبيق من طرف إلى طرف على جهاز نظيف قبل التقديم يمنع معظم هذه الحالات الثلاث.

على Play، أكثر المشكلات شيوعًا هي عدم تطابق نموذج Data safety مع سلوك الـ SDK الفعلي، أو رابط سياسة خصوصية فارغ/غير قابل للوصول؛ وكلاهما يحمل خطر الرفض أو التعليق لاحقًا. استخدام AdMob دون التحقق عبر app-ads.txt لا يسبب رفضًا مباشرًا، لكنه قد يقيّد عرض الإعلانات ويكلفك خسارة في الإيرادات.

بالنسبة للمشاريع التي تستخدم Expo (EAS)، تكون العملية آلية إلى حد كبير: يبني الأمر npx eas-cli build --platform all --profile production للمتجرين في السحابة، ويُؤتمت الأمر npx eas-cli submit عملية التقديم (باستثناء حالة أول رفع في Play). تُحفظ أرقام الإصدار في ثلاثة حقول منفصلة داخل app.json — وهي expo.version وexpo.ios.buildNumber وexpo.android.versionCode — بدلًا من الحقل الواحد في pubspec.yaml الخاص بـ Flutter، ويجب مزامنتها يدويًا.