خبرة عملية في تجهيز نسخة مستقلّة لكل متجر، والأخطاء التي تُرفض بسببها التطبيقات فعلياً.
نشر التطبيق على متجر واحد مسألة معروفة. نشره على ثلاثة متاجر في آن واحد مسألة مختلفة تماماً، لأن كل متجر يفرض حزمة خدماته الخاصة للإعلانات والمدفوعات، ولأن ما يقبله متجر قد يرفضه آخر لسبب لا علاقة له بجودة التطبيق.
ما يلي خلاصة تجربة نشر عدّة تطبيقات على Google Play وHuawei AppGallery وAmazon Appstore.
القاعدة الأولى: ثلاثة مشاريع لا مشروع واحد
الإغراء الطبيعي أن تبني مشروعاً واحداً بثلاث نكهات (flavors). عملياً، فصل المشاريع أهدأ للأعصاب على المدى الطويل: كل متجر يفرض مكتبات مختلفة، وقواعد ProGuard مختلفة، وأحياناً إصدارات SDK مختلفة، وتجميعها في مشروع واحد يجعل كل تحديث في أحدها مخاطرة على الآخرين.
اجعل المشترك بينها هو المنطق (طبقة اللعبة أو الميزة نفسها) وافصل ما يخصّ المتجر: الإعلانات، المدفوعات، الخدمات.
Google Play: المواعيد النهائية هي ما يوقعك
أكثر ما يُسقط المطوّرين هنا ليس رفض المراجعة بل المتطلّبات الزمنية:
- مستوى API المستهدف: يرفع Play الحدّ الأدنى سنوياً. تحديث
targetSdkليس اختيارياً؛ بعد الموعد النهائي تتوقّف قدرتك على رفع تحديثات. - إصدار مكتبة الفوترة: تُلزمك Google بالترقية إلى إصدارات Play Billing الحديثة دورياً، وتتغيّر توقيعات الدوالّ بين الإصدارات الكبرى فتنكسر الشيفرة القديمة.
- إذن AD_ID: إن كان إصدار قديم منشور يحمل الإذن ونسختك الجديدة لا تحمله، قد يعترض Play. راجع كل الإصدارات النشطة لا الأخير فقط.
- نموذج أمان البيانات: يجب أن يطابق ما يفعله تطبيقك فعلاً. التصريح غير الدقيق سبب شائع للتعليق.
Huawei AppGallery: دمج HMS شرط لا اقتراح
الرفض الأشهر هنا رسالته: «HMS not integrated». يحدث حين ترفع نسخة تعتمد على خدمات Google، لأن أجهزة هواوي الحديثة لا تحتوي عليها أصلاً.
ما تحتاجه فعلياً:
- استبدال إعلانات Google بـ HMS Ads، ومدفوعات Play بـ HMS IAP.
- وضع ملف
agconnect-services.jsonفي المسار الصحيح داخل الوحدة. - إضافة بيانات HMS الوصفية في
AndroidManifest.xml. - توسيع قواعد ProGuard لحماية أصناف HMS من التشويش عند البناء بوضع الإصدار — هذا سبب صامت لأعطال تظهر في النسخة النهائية فقط.
ملاحظة عملية أخرى: إن كان تطبيقك يعتمد على WebView، فبعض إصدارات المحرّك على أجهزة هواوي أقلّ تسامحاً مع خصائص CSS الحديثة. اختبر على جهاز حقيقي لا على محاكٍ فقط.
Amazon Appstore: أبسط، بشرط تبديل الطبقتين
أمازون عادةً أهدأ المتاجر الثلاثة مراجعةً، لكنه يفرض نظام مدفوعاته الخاص (Amazon IAP)، ولا يسمح بشبكات إعلانات معيّنة. عملياً يعني ذلك استبدال طبقة الإعلانات بشبكة مدعومة وطبقة المدفوعات بواجهة أمازون، مع إبقاء بقية التطبيق كما هو.
ميزة إضافية: يعمل التطبيق على أجهزة Fire اللوحية، وهي سوق صغيرة لكن منافستها أقلّ بكثير.
ما يستحقّ التوحيد بين النسخ الثلاث
- طبقة تجريد للإعلانات والمدفوعات: واجهة واحدة في الشيفرة، وثلاث تنفيذات خلفها. هذا وحده يوفّر أياماً في كل تحديث.
- مفتاح اختبار مركزي: متغيّر واحد يبدّل بين معرّفات الإعلانات التجريبية والحقيقية. نسيان إعادته سبب شائع لحظر الحساب.
- سياسة خصوصية واحدة منشورة على الويب: المتاجر الثلاثة تطلبها برابط عامّ يعمل.
- مواد النشر: اللقطات والوصف والأيقونة بمقاسات كل متجر، محفوظة في مجلّد واحد منظّم.
ترتيب عملي للنشر
ابدأ بـ Google Play لأنه الأكثر صرامة؛ إن مرّ تطبيقك منه فقد حللت معظم مشاكل الامتثال. ثم انتقل إلى AppGallery حيث يتركّز العمل في تبديل الخدمات، وأخيراً Amazon الذي يحتاج غالباً أقلّ تعديل.
وتوقّع دورة مراجعة تتراوح بين ساعات وبضعة أيام حسب المتجر والموسم — لا تجدول إطلاقاً يعتمد على موافقة في يوم محدّد.
كُتب هذا المقال ضمن مدوّنة Store of Apps. لأي ملاحظة أو تصحيح راسلنا على contact@storeofapps.com.