النشر على App Store و Play Store: كيف تتجنّب الرفض
معظم حالات رفض التطبيقات يمكن تفاديها. دليل عملي لاجتياز مراجعة App Store و Play Store من أول محاولة، من الخصوصية إلى المدفوعات.

تطبيقك جاهز: مكتمل، مختبَر، ومرفوع. تكتب الوصف، تضغط زر الإرسال، وتنتظر. وبعد يومين تصلك رسالة واحدة: مرفوض. لا إيرادات، لا مستخدمين، فقط رقم بند غامض من إرشادات المراجعة ولقطة شاشة عليك فك شفرتها. بالنسبة لفريق حدّد موعد إطلاق، وأبلغ به الإدارة وأصحاب المصلحة، وربما حجز ميزانية إعلانية، فالرفض ليس مجرد تأخير بسيط، بل مشكلة في المصداقية.
معظم حالات الرفض يمكن تجنّبها. فهي تنبع من حفنة من الأخطاء المتكررة التي لا علاقة لها بجودة منتجك. وبعد إطلاق تطبيقات على كل من App Store و Play Store لعملاء في الخليج ومصر والأسواق الغربية، تعلّمنا أن اجتياز المراجعة عملية يمكن هندستها، لا رمية نرد. وفيما يلي كيف ترجّح الكفة لصالحك.
لماذا تُرفض التطبيقات فعليًا
المراجِع لا يختبر ما إذا كانت فكرتك ذكية، بل يتحقق من مدى التزامك بقواعد منشورة: App Review Guidelines الخاصة بـ Apple، وسياسات برنامج المطوّرين في Google Play. والأسباب الأكثر شيوعًا لرفض app submission متوقَّعة:
- الأعطال والميزات المعطّلة. يصطدم المراجِع بخطأ، أو زر لا يعمل، أو شاشة فارغة، فيتوقف. هذا أكثر أسباب الرفض شيوعًا، وأكثرها إحراجًا، لأنه قابل للتفادي بالكامل.
- بيانات وصفية ناقصة (Metadata). غياب رابط سياسة الخصوصية، أو لقطات شاشة مؤقتة، أو وصف لا يطابق التطبيق، أو حساب تجريبي لا يعمل.
- ثغرات في الخصوصية والتعامل مع البيانات. عدم وجود شاشة موافقة، أو جمع بيانات غير مُعلَن عنه، أو بطاقة خصوصية تناقض ما يفعله التطبيق فعليًا.
- مخالفة قواعد الدفع. بيع محتوى رقمي عبر نظام دفع خاص بك بدلًا من In-App Purchase، أو توجيه المستخدم إلى موقع خارجي للدفع.
- جدار تسجيل دخول بلا مدخل. إجبار المستخدم على التسجيل قبل أن يرى المراجِع أي شيء، دون توفير بيانات اختبار.
تميل Apple إلى أن تكون أكثر صرامة واعتمادًا على المراجعة البشرية، خصوصًا في جودة التصميم والمدفوعات. أما Google Play فتعتمد أكثر على الفحوص الآلية، لكنها شدّدت كثيرًا على الخصوصية، ومستويات API المستهدفة، والسلوك المُضلِّل. عليك أن ترضي كلا الكتابَين، كلٌّ على حدة.
ثبّت الأساسيات قبل الإرسال
تعامل مع قائمة ما قبل الإرسال كجزء من التطوير، لا كأمر لاحق. فالبنود المملّة هي التي تتسبب في الرفض.
الاستقرار أولًا
شغّل النسخة نفسها التي ستُرسلها على أجهزة حقيقية، لا على المحاكي فقط. اختبر على هاتف Android متوسط الفئة وقديم نسبيًا، وعلى iPhone قديم، لأن المراجِعين لا يستخدمون دائمًا الأجهزة الرائدة. مرّ على كل مسار رئيسي: الإعداد الأولي، الميزة الأساسية، الدفع إن وُجد، وحذف الحساب. فإن أدّت نقرة واحدة إلى عطل، انتهت المراجعة عند تلك النقطة.
الخصوصية غير قابلة للتفاوض
يطلب المتجران الآن إجابة واضحة عن سؤال: "ما البيانات التي تجمعها ولماذا؟"
- انشر سياسة خصوصية حقيقية على رابط عام ثابت، واربطها في صفحة المتجر وداخل التطبيق معًا.
- املأ بطاقات الخصوصية في Apple ونموذج Data Safety في Google Play بدقة. فأي تعارض بين ما تُعلنه وما يفعله الكود سبب سريع للرفض.
- إن كنت تستخدم أدوات تحليلات، أو SDK إعلانات، أو تقارير أعطال، أو أدوات مثل Firebase، فاحسب البيانات التي تجمعها كل أداة.
- وفّر وسيلة داخل التطبيق لحذف الحساب. تشترط Google ذلك الآن لأي تطبيق يتيح إنشاء حساب، وتتوقعه Apple أيضًا.
بيانات وصفية تطابق الواقع
- يجب أن تُظهر لقطات الشاشة التطبيق الفعلي، بالدقّة الصحيحة، دون إطارات أجهزة مخالِفة للإرشادات أو عبارات "قريبًا".
- يجب أن يصف الوصف ما يفعله التطبيق فعلًا، دون حشو للكلمات المفتاحية أو ذكر منصات أخرى.
- اضبط التصنيف العمري وإقرارات المحتوى بشكل صحيح.
قاتلا المراجعة: الحسابات والمدفوعات
تتسبب فئتان في نصيب غير متناسب من حالات الرفض، وكلتاهما سهلة الوقوع في الخطأ.
الحسابات التجريبية وتسجيل الدخول. إن كان تطبيقك يتطلب تسجيل دخول، فعليك تزويد المراجِع ببيانات اعتماد تعمل في ملاحظات المراجعة (وما يقابلها في Google). يجب أن يصل هذا الحساب إلى التجربة الكاملة المدفوعة كي يرى المراجِع كل شيء. رأينا إطلاقات تأخرت أسبوعًا فقط لأن حساب اختبار انتهت صلاحيته، أو لأن رمز OTP ذهب إلى هاتف لا يملك المراجِع الوصول إليه. استخدم حسابًا تجريبيًا دائمًا وعطّل التحقق عبر الرسائل النصية له.
المدفوعات والاشتراكات. هنا يُفاجأ كثير من المؤسسين، خصوصًا أصحاب منتجات التجارة الإلكترونية و SaaS. القاعدة بسيطة لكنها صارمة: إن كنت تبيع محتوى رقميًا أو ميزات أو اشتراكات تُستهلك داخل التطبيق، فعليك غالبًا استخدام In-App Purchase من Apple ونظام Google Play Billing. ولا يمكنك التوجيه إلى صفحة دفع خاصة بك للتهرّب من العمولة. أما السلع المادية والخدمات الواقعية (طلب توصيل، عملية شراء مرتبطة بنظام POS، استشارة حقيقية) فمختلفة وتستخدم وسائل الدفع المعتادة. وتجعل أدوات مثل RevenueCat إدارة الاشتراكات داخل التطبيق عبر المتجرين أقل إيلامًا بكثير. حدّد مبكرًا أيٌّ من معاملاتك "رقمية" وأيها "مادية"، لأن تعديل ذلك بعد الرفض مكلِف.
تعامل مع الرفض دون أن تخسر الأسبوع
حتى الفرق الحذرة تُرفض أحيانًا، والاستجابة أهم من الرفض نفسه.
- اقرأ البند المذكور فعليًا. تشير Apple إلى رقم قسم محدّد، فابحث عنه بدل التخمين. وتمنحك Google فئة سياسة وسببًا في الغالب.
- أعِد إنتاج المشكلة. إن قالوا إنه تعطّل، فاكتشف على أي جهاز ونظام تشغيل. وإن قالوا بيانات وصفية، فقارن سطرًا بسطر.
- ردّ، ولا تكتفِ بإعادة الإرسال. يتيح لك Resolution Center في Apple الرد على المراجِع. وشرح واضح ومهذّب، أحيانًا مع تسجيل شاشة يُظهر عمل الميزة، قد يحلّ سوء فهم دون تغيير في الكود.
- عالِج السبب الجذري ثم أعِد الإرسال. إعادة إرسال النسخة نفسها أملًا في مراجِع مختلف تضيّع أيامًا وقد تلفت الأنظار إلى حسابك سلبًا.
- خصّص وقتًا احتياطيًا. افترض جولة واحدة على الأقل من الأخذ والرد، ولا تعِد جمهورك أبدًا بموعد إطلاق صارم يعتمد على القبول من المحاولة الأولى.
أما بخصوص App Store تحديدًا، فتوجد مراجعات عاجلة للحالات الطارئة الحقيقية، لكنها مورد محدود. لا تحرقها على خطأ تسببت فيه بنفسك.
أهم النقاط
- معظم حالات الرفض تنبع من مشكلات يمكن تفاديها: أعطال، بيانات وصفية ناقصة، تعارض في الخصوصية، ومخالفات للدفع، لا من ضعف المنتج.
- اقرأ كتابَي القواعد كلًّا على حدة. فإرشادات App Review من Apple وسياسات Google Play تتقاطعان لكنهما ليستا متطابقتين، وعليك اجتياز كليهما.
- الخصوصية باتت حاسمة: إقرارات بيانات دقيقة، وسياسة خصوصية حقيقية، وحذف حساب من داخل التطبيق، كلها مطلوبة لا اختيارية.
- وفّر حسابًا تجريبيًا دائمًا يعمل ويصل إلى التجربة الكاملة، واضبط استراتيجية الشراء داخل التطبيق قبل البناء لا بعده.
- ضع وقتًا احتياطيًا في خطة إطلاقك، وردّ على الرفض بالأدلة لا بمجرد إعادة الإرسال.
الإرسال الناجح من المحاولة الأولى نتيجة قرارات تُتخذ أثناء التطوير، من طريقة تعاملك مع البيانات إلى هيكلة المدفوعات. إن أردت إطلاقًا يجتاز المراجعة من أول مرة، أو كنت تتعافى من رفض وتحتاج إلى إصلاحه سريعًا، فإن خدماتنا تغطي رحلة البناء حتى المتجر كاملةً لنظامي iOS و Android. اطّلع على أعمالنا، ثم تواصل معنا ولنُطلق تطبيقك دون مفاجآت.
عن الكاتب
SummationWorks
SummationWorks is a software development company building web apps, mobile apps, and AI tools for startups and growing businesses across the US, UK, and GCC.
المزيد عنّامقالات ذات صلة
engineeringبناء تطبيقات ويب سريعة في 2026
كيف نطلق تطبيقات ويب جاهزة للإنتاج تُحمّل فورًا وتتوسع — التقنيات، والمفاضلات، والعادات التي تقف خلف ذلك.
engineeringتحديد معدل الطلبات والحماية من الإساءة في الـ API: دليل عملي
كيف يحافظ rate limiting والحماية من الإساءة على استقرار الـ backend: استراتيجيات throttling ودفاعات متعددة الطبقات وحدود لا تعاقب المستخدمين الحقيقيين.
engineeringالمهام الخلفية والطوابير لبناء أنظمة Backend موثوقة
كيف تجعل الـ background jobs والـ queues والـ workers الـ backend سريعًا وموثوقًا تحت الضغط عبر إعادة المحاولة والأدوات الصحيحة.