رفض أو تعليق التطبيق في Google Play: السياسات الشائعة وخطة الاستئناف

وصلتك رسالة من Google Play تقول إن تحديث تطبيقك رُفض، أو إن التطبيق أُزيل أو عُلّق. أول ما يخطر لك أن ترد فورًا أو تعيد الرفع كما هو. هذا غالبًا ما يطيل المشكلة. الرسالة تحدد سياسة بعينها، لكنها قد لا تذكر كل مخالفة في التطبيق، وتكرار الرفض أو الإزالة يترك أثرًا على الحساب كله لا على التطبيق وحده. هذا الدليل يرتب لك التشخيص: ما نوع القرار، وأين السبب الفعلي، وهل تصحح أم تستأنف، وكيف تحمي حساب منشأتك من تكرار ذلك.

يصلك القرار في البريد المسجل في الحساب، ويظهر في صندوق الرسائل داخل Play Console، وتجد تفاصيله في صفحة «حالة السياسة» (Policy status) لكل تطبيق. لا تعتمد على البريد وحده؛ الصفحة تعرض الإجراء النشط والإصدار المقصود وخيار الاستئناف حين يكون متاحًا.

استخرج من الإشعار خمس معلومات، واكتبها في ملف واحد قبل أن تناقش أي حل:

• اسم السياسة: مثل الأذونات، أو أمان البيانات، أو الإعلانات، أو المحتوى المضلل. هذه هي الصفحة التي ستقرؤها كاملة.
• رمز الإصدار (Version code): أي حزمة بالضبط راجعها الفريق؛ قد تكون نسخة في مسار اختبار لا الإصدار العام.
• موضع المخالفة: في الكود والحزمة، أم في صفحة المتجر، أم في تصريح داخل «محتوى التطبيق».
• الدليل المرفق: لقطة شاشة، أو اسم إذن، أو مقطع من الوصف. الدليل يوضح ما رآه المراجع لا ما تظنه أنت.
• المهلة: بعض الرسائل تحذيرات بموعد تصحيح قبل الإزالة، وبعضها قرار نافذ.

تذكر أن Google تنبه في صفحة إزالة التطبيق من Google Play إلى أن تتحقق من التزام التطبيق ببقية السياسات، لأن إجراءات إضافية قد تتبع إن وُجدت مخالفات أخرى. الإشعار يصف ما وجده المراجع في هذه المراجعة، لا كل ما في التطبيق.

هذا الجدول أداة التشخيص الأساسية. العمود الأوسط هو ما نجده غالبًا حين نتتبع الرسالة إلى مصدرها، والعمود الأخير يحدد من يصلح: المطور في الكود، أم مسؤول الحساب في Play Console، أم فريق التسويق في صفحة المتجر.

مثال افتراضي للتوضيح مطعم بثلاثة فروع لديه تطبيق للعملاء وتطبيق للمندوبين مبنيان بـ Flutter. رُفض تحديث تطبيق المندوب برسالتين: الموقع في الخلفية، وأمان البيانات. بتتبع السبب وجد الفريق أن التتبع يعمل حتى بعد انتهاء الوردية، وأن الشاشة التي تشرح سبب طلب الموقع غير موجودة، وأن مكتبة تقارير الأعطال تجمع معرّف الجهاز دون تصريح. الإصلاح كان ثلاثة أجزاء: شاشة إفصاح قبل طلب الإذن، وإيقاف التتبع خارج الوردية، وتحديث نموذج أمان البيانات. لو اكتفى الفريق بالرد على المراجع بأن «التتبع ضروري للتوصيل»، لبقي السبب قائمًا.

1. جمّد الرفع: لا ترفع إصدارًا جديدًا قبل تشخيص السبب. Google تطلب صراحة ألا يُعاد نشر تطبيق مرفوض أو مُزال قبل إصلاح المخالفة.
2. اقرأ السياسة كاملة: لا ملخص الرسالة فقط. كثير من السياسات فيها استثناءات وشروط (إفصاح، نموذج، مقطع) هي بالضبط ما يُطلب منك.
3. اجرد الحزمة لا الكود فقط: الأذونات النهائية في الحزمة المبنية تشمل ما أضافته المكتبات. قارنها بما يحتاجه التطبيق فعلًا، واجرد المكتبات التي تجمع بيانات.
4. أصلح في موضع المخالفة: الكود، أو صفحة المتجر، أو تصريحات محتوى التطبيق. وغالبًا أكثر من موضع معًا.
5. عطّل النسخ المخالفة في كل المسارات: تطلب Google رفع الحزمة المصححة إلى كل المسارات، ومنها الاختبار الداخلي والمغلق والمفتوح، وإيقاف الحزم غير الملتزمة؛ وإن بقيت فستفشل إعادة التقديم وقد تُزال النسخ المنشورة.
6. اختبر النسخة الموقعة نفسها: ارفعها أولًا إلى مسار اختبار، وتأكد أن حساب المراجعة يدخل، وأن شاشة الإفصاح تظهر، وأن حذف الحساب يعمل.
7. أعد التقديم بملاحظات واضحة: اكتب ما تغير وأين يجده المراجع، ثم تابع صفحة حالة السياسة حتى يُعتمد الإصدار.

إن كان الرفض بسبب مستوى API، فالمسار مختلف قليلًا: الترقية قد تكسر مكتبات قديمة أو سلوكًا في الخلفية، فتحتاج إلى دورة اختبار كاملة لا تعديل رقم فقط. هنا يتقاطع الرفض مع مشكلات الاستقرار، وقد تحتاج إلى تشخيص أعطال التطبيق عند المستخدمين بعد الترقية.

التعليق يُحسب على الحساب، وتكرار المخالفات الجسيمة قد ينتهي بإنهاء الحساب وكل الحسابات المرتبطة به. لذلك عامل الحساب كأصل تجاري لا كأداة رفع. هذه قائمة تحقق تستخدمها مرة الآن ثم قبل كل إصدار كبير:

• الحساب باسم المنشأة، ومالكه موظف دائم أو بريد مؤسسي، لا المطور ولا موظف قد يغادر. التفاصيل في فتح حساب مطور باسم الشركة.
• صلاحيات أعضاء الفريق والمطورين الخارجيين محددة بالدور، وتُسحب عند انتهاء التعاقد.
• لا تنشر من حساب واحد تطبيقات تجريبية أو لعملاء آخرين أو مشاريع جانبية؛ مخالفة أي منها تؤثر على الحساب كله.
• جرد مكتوب للمكتبات الخارجية وما تجمعه من بيانات، يُراجع عند كل تحديث لها.
• تصريح أمان البيانات وسياسة الخصوصية يُحدّثان مع كل ميزة تجمع بيانات جديدة.
• حساب مراجعة ثابت يتجاوز رمز التحقق، مسجل في «بيانات الدخول»، ولا يُحذف في تنظيف البيانات.
• موعد مستوى API المستهدف السنوي مدرج في خطة الدعم قبل حلوله بوقت كافٍ.
• إطلاق تدريجي للتحديثات الكبيرة، مع قدرة على إيقاف الإصدار فورًا.
• البريد المسجل في الحساب يقرؤه شخص مسؤول، لأن التحذيرات بمهلة تصل إليه أولًا.

سواء عالج الرفض فريقك أو المطور السابق أو شركة جديدة، اطلب نتيجة قابلة للتحقق لا وعدًا بأن «التطبيق سيُقبل». لا أحد يتحكم في قرار المراجعة؛ الذي يمكن طلبه هو تشخيص صحيح وتصحيح موثق.

ما تجهزه

• نص الرسالة كاملًا ولقطة من صفحة حالة السياسة، مع رمز الإصدار.
• صلاحية على Play Console بدور محدد، لا كلمة مرور المالك.
• الوصول إلى الكود والحزمة الأخيرة المرفوعة، أو ملفات البناء على الأقل.
• قائمة بالخدمات الخارجية في التطبيق: التحليلات، والأعطال، والإعلانات، والدفع، والرسائل.
• سجل الإجراءات السابقة على الحساب إن وُجدت، لأنها تغير حجم المخاطرة.

ما تطلبه من الشركة

• تشخيص مكتوب يربط كل بند في الرسالة بسببه وموضع إصلاحه.
• مراجعة لبقية السياسات الرئيسية، لا للبند المذكور وحده.
• قائمة بالأذونات والمكتبات قبل التعديل وبعده.
• نص ملاحظات المراجعة أو الاستئناف قبل إرساله، لتعتمده المنشأة.
• توثيق ما عُدّل في تصريحات Play Console، حتى لا يعود الخطأ مع أول ميزة جديدة.

في صفحة خدمة النشر على App Store وGoogle Play نطلب رسالة الرفض أولًا، ثم نعالج السبب في التطبيق أو في بيانات المتجر ونعيد التقديم مع توضيح للمراجع، وننشر كذلك تطبيقات طوّرها غيرنا بعد مراجعة جاهزيتها وتوفر الكود أو ملفات البناء. وإن كان الرفض عرضًا لأعطال أعمق، فالمسار إصلاح أخطاء التطبيق القائم بترتيبها حسب أثرها. أما متطلبات المستوى المستهدف السنوية فنحدّثها ضمن عقد الدعم قبل موعد Google كما في صفحة تطوير تطبيقات Android. وإن كان الرفض من App Store لا Google Play، فالمراجعة وأسبابها مختلفة، وتجدها في دليل الرد على رفض App Store.