الإجابة المختصرة: أغلب حالات رفض التطبيق من آبل لا علاقة لها بجودة الكود، بل بأشياء يمكن تجهيزها قبل الرفع بساعة واحدة: حساب تجريبي ناقص، وتطبيق ينهار عند أول فتح، وغياب خيار حذف الحساب، وأذونات بلا سبب مكتوب، ودفع يلتف على نظام آبل، ولقطات لا تطابق ما في التطبيق. الرفض في المراجعة الأولى شائع جدًا، وليس حكمًا على مشروعك — لكن كل دورة رفض تكلّفك أيامًا، وهي أيام تُدفع من موعد إطلاقك.
المراجعة عند آبل يقوم بها بشر يفتحون تطبيقك ويستخدمونه فعلًا. وهذا يعني أن ما يرونه في الدقائق الخمس الأولى يحدد النتيجة. المفارقة أن أغلب أسباب الرفض تُكتشف في تلك الدقائق نفسها لو جرّبها أحد من فريقك على جهاز نظيف قبل الرفع.
قبل الأسباب: كيف تُقرأ رسالة الرفض؟
رسالة الرفض تصل داخل لوحة المطوّر، وتحتوي غالبًا رقم بند من إرشادات المراجعة (مثل 2.1 أو 4.2 أو 5.1.1). هذا الرقم أهم من نص الرسالة، لأنه يحدد بدقة أي قاعدة خُرقت.
ومعها غالبًا لقطة شاشة من الجهاز الذي اختُبر عليه التطبيق. افتح اللقطة أولًا: كثير من حالات «الرفض الغامض» تتضح فورًا حين ترى ما رآه المراجع.
السبب 1: التطبيق ينهار أو لا يكتمل
هذا أكثر أسباب الرفض شيوعًا على الإطلاق. التطبيق يُفتح فينهار، أو تظهر شاشة تحميل لا تنتهي، أو زر لا يؤدي إلى شيء.
والسبب المعتاد ليس خللًا في الكود بل بيئة مختلفة: المراجع يفتح التطبيق على شبكة بطيئة، وبحساب جديد بلا بيانات، وعلى نسخة نظام أحدث مما اختبرتَ عليه.
كيف تتفاداه: ثبّت نسخة الإصدار على جهاز لم يُستخدم في التطوير، وافتحها بحساب جديد تمامًا، وجرّبها على شبكة ضعيفة. أغلب الانهيارات التي يجدها المراجعون تظهر في هذه الحالة الثلاثية بالذات.
السبب 2: حساب تجريبي ناقص أو لا يعمل
إن كان تطبيقك يتطلب تسجيل دخول، فالمراجع يحتاج حسابًا جاهزًا. وهذا الحساب يجب أن يكون:
فعّالًا وقت المراجعة — لا حساب انتهت صلاحيته أو حُذف أثناء تنظيف قاعدة البيانات. كامل الصلاحيات — يرى المراجع ما يراه المستخدم الحقيقي، لا نسخة فارغة. بلا رمز تحقق يصل لجوالك أنت — وهذه مصيدة متكررة: التطبيق يرسل رمزًا برسالة نصية إلى رقم لا يملكه المراجع، فيتوقف عند الشاشة الأولى.
العلاج: جهّز حسابًا ثابتًا للمراجعة، وإن كان الدخول برمز تحقق فاجعل رقمًا تجريبيًا محددًا يقبل رمزًا ثابتًا، واكتب ذلك صراحة في ملاحظات المراجعة.
السبب 3: التطبيق مجرد غلاف لموقع
بند 4.2 يرفض التطبيقات التي لا تقدّم شيئًا يتجاوز ما يقدّمه الموقع في المتصفح. وإن كان تطبيقك يفتح صفحات موقعك داخل نافذة فقط، فاحتمال الرفض مرتفع.
هذا القرار يُتخذ قبل البرمجة لا بعدها، وهو جوهر المفاضلة التي شرحناها في الفرق بين الموقع والتطبيق.
ما الذي يرفع التطبيق فوق العتبة؟ إشعارات مفيدة، وعمل جزئي دون اتصال، واستخدام كاميرا أو موقع أو محفظة، وحالة محفوظة على الجهاز. واحدة أو اثنتان تكفيان — لكن غيابها كلها يعني غلافًا.
السبب 4: لا توجد طريقة لحذف الحساب
كل تطبيق يسمح بإنشاء حساب يجب أن يسمح بحذفه من داخل التطبيق. لا رسالة إلى الدعم، ولا نموذج في الموقع، ولا «راسلنا وسنحذفه».
هذا السبب يوقع كثيرًا من التطبيقات العربية لأنه أُضيف بعد بناء أنظمة كثيرة، فبقيت شاشة الإعدادات كما كانت.
العلاج: زر واضح في الإعدادات، ومسار يشرح ما سيُحذف وما سيبقى (طلبات سابقة مثلًا لأسباب محاسبية)، وتأكيد قبل التنفيذ.
السبب 5: أذونات بلا سبب مكتوب
عند طلب الكاميرا أو الموقع أو جهات الاتصال، يعرض النظام نصًا تكتبه أنت. النص الفارغ أو العام («يحتاج التطبيق إلى الكاميرا») سبب رفض مباشر.
النص الصحيح يقول ماذا ولماذا: «لتصوير المستند وإرفاقه بطلبك» أفضل بكثير من «للوصول إلى الكاميرا».
وأسوأ من النص السيئ: طلب إذن لا يستعمله التطبيق. إن كنت تطلب الموقع ولا تستخدمه، احذف الطلب — وجوده وحده يستدعي سؤالًا من المراجع.
السبب 6: الدفع يلتف على نظام آبل
هنا يُرفض كثير من التطبيقات التجارية. القاعدة باختصار: المحتوى الرقمي داخل التطبيق يُشترى عبر نظام آبل، وعمولته معروفة. أما السلع والخدمات المادية — طلب طعام، حجز عامل، شراء منتج يُشحن — فتُدفع بأي بوابة دفع عادية.
الخلط بين الحالتين مكلف. اشتراك شهري يفتح ميزات داخل التطبيق يقع في الحالة الأولى، حتى لو كان تطبيقك خدميًا في الأساس. وقد فصّلنا الحسبة كاملة في المشتريات داخل التطبيق وعمولة المتاجر.
ولا تضع رابطًا يوجّه المستخدم للدفع في موقعك تفاديًا للعمولة؛ هذه محاولة معروفة وسبب رفض متكرر.
السبب 7: بطاقة الخصوصية لا تطابق الواقع
تطلب آبل إعلانًا بما يجمعه تطبيقك من بيانات وكيف يُستخدم. والرفض يأتي حين يجمع التطبيق أكثر مما أعلنت.
المصدر الشائع للخطأ: مكتبات خارجية تجمع معرّفات أو بيانات استخدام دون أن ينتبه الفريق. أدوات التحليلات والإعلانات والانهيارات كلها تدخل في هذا الحساب.
العلاج: اجرد المكتبات الخارجية واحدة واحدة قبل الرفع، واسأل عن كل واحدة: ماذا ترسل، وإلى أين؟
السبب 8: اللقطات والوصف لا تطابق التطبيق
اللقطات التي ترفعها هي أول ما يقارنه المراجع بما يراه. وأي وعد في الوصف بميزة غير موجودة يُقرأ كتضليل.
الأخطاء المتكررة: لقطات من نسخة أقدم، وشاشات مصمَّمة بالفوتوشوب لا تشبه الواجهة الحقيقية، ووصف يذكر ميزة «قادمة قريبًا»، وذكر منصات أخرى في الوصف.
السبب 9: محتوى مؤقت وروابط مكسورة
نص بديل باقٍ في شاشة، وصورة عيّنة، ورابط «سياسة الخصوصية» يفتح صفحة 404 — كلها أسباب رفض مباشرة رغم بساطتها.
رابط سياسة الخصوصية تحديدًا يجب أن يعمل وقت المراجعة، وأن يفتح صفحة حقيقية تخص تطبيقك.
جدول: السبب والدليل والإصلاح
| سبب الرفض | كيف تكتشفه قبل الرفع | الإصلاح | |—|—|—| | انهيار عند الفتح | جهاز نظيف + حساب جديد + شبكة ضعيفة | إصلاح المسار الأول لا الشاشات الداخلية | | حساب تجريبي معطّل | جرّب الدخول بالحساب الذي كتبته في الملاحظات | حساب ثابت + رمز تحقق تجريبي | | غلاف لموقع | اسأل: ما الذي يفعله ولا يفعله المتصفح؟ | إشعارات، عمل دون اتصال، كاميرا/موقع | | لا حذف للحساب | افتح الإعدادات وابحث عن الزر | مسار حذف كامل داخل التطبيق | | أذونات بلا مبرر | اقرأ نصوص الأذونات كما يراها المستخدم | نص يقول ماذا ولماذا + حذف غير المستعمل | | دفع خارج النظام | صنّف: رقمي أم مادي؟ | نظام آبل للرقمي، بوابة عادية للمادي | | خصوصية غير مطابقة | اجرد المكتبات الخارجية | تحديث الإعلان ليطابق الواقع | | لقطات مضلّلة | قارن كل لقطة بالشاشة الحقيقية | لقطات من نسخة الإصدار نفسها | | محتوى مؤقت | ابحث عن نصوص العيّنة في الكود | تنظيف قبل الرفع + فحص كل رابط |
كم يستغرق الرد؟ وماذا تفعل بعد الرفض؟
المراجعة عادة سريعة — أيام قليلة على الأكثر، وغالبًا أقل. والرفض لا يعيدك إلى الصفر: تصلح ما طُلب وترفع نسخة جديدة، أو ترد داخل لوحة المراجعة إن كنت ترى أن المراجع أخطأ في الفهم.
والرد المكتوب جيدًا ينفع فعلًا. إن كان الرفض بسبب سوء فهم لميزة، اشرحها بخطوات مرقّمة مع لقطة، واذكر أين توجد بالضبط. كثير من الحالات تُحلّ بالرد بلا رفع نسخة جديدة.
ما لا ينفع: الجدال في صواب القاعدة نفسها، أو إعادة الرفع بلا تغيير أملًا في مراجع آخر.
احسب دورة الرفض في جدولك. كل دورة تعني أيامًا إضافية، ولهذا نضع في تقديراتنا الزمنية هامشًا للمراجعة — وهو جزء من الحساب الذي شرحناه في كم يستغرق تصميم تطبيق.
قائمة فحص قبل الضغط على «إرسال للمراجعة»
نفّذها كاملة؛ لا تستغرق أكثر من ساعة:
افتح التطبيق على جهاز لم يُستخدم في التطوير. بحساب جديد وشبكة بطيئة. سجّل الدخول بالحساب التجريبي المكتوب في الملاحظات. حرفيًا، لا بحسابك. افتح الإعدادات وابحث عن زر حذف الحساب. إن لم تجده فأنت مرفوض سلفًا. اقرأ نصوص الأذونات. هل تشرح السبب؟ هل هناك إذن لا تستعمله؟ صنّف كل عملية شراء: رقمية أم مادية؟ افتح كل رابط في التطبيق ووصف المتجر. خصوصًا سياسة الخصوصية. قارن كل لقطة بالشاشة الحقيقية. هل تطابقها اليوم؟ ابحث في الكود عن نصوص العيّنة. «تجربة»، «نص مؤقت»، بريد افتراضي.
أسئلة شائعة
هل الرفض يؤثر على حسابي أو على مراجعات لاحقة؟
لا. الرفض حدث عادي في دورة النشر، ولا يُسجَّل ضدك. ما يضرّ فعلًا هو التحايل المتكرر على القواعد.
هل يمكن تسريع المراجعة؟
تتيح آبل طلب مراجعة عاجلة لحالات محددة كإصلاح خلل حرج يمسّ المستخدمين. استخدمه بحذر: الطلبات غير المبرَّرة تُرفض.
هل قواعد جوجل بلاي أسهل؟
مختلفة لا أسهل. المراجعة هناك أكثر آلية، لكن سياسات البيانات والفئات الحساسة صارمة، والإيقاف بعد النشر أشيع. فصّلناها في نشر تطبيق على جوجل بلاي.
تطبيقي داخلي لموظفي الشركة، هل تنطبق القواعد نفسها؟
إن كان التوزيع عبر المتجر العام فنعم. أما التوزيع الداخلي للمؤسسات فله مسار مختلف بشروطه.
هل أحتاج حساب مطوّر باسم الشركة؟
إن كان التطبيق تجاريًا باسم علامتك فنعم، وهو ما يتطلب توثيقًا للمنشأة. شرحنا خطواته في حساب مطور آبل وجوجل.
كيف تُكتب ملاحظات المراجعة؟
خانة الملاحظات في لوحة الرفع هي فرصتك الوحيدة للحديث مع المراجع قبل أن يحكم. وأغلب الفرق تتركها فارغة أو تكتب فيها جملة عامة.
ما يستحق أن يُكتب فيها:
بيانات الحساب التجريبي كاملة — اسم المستخدم وكلمة المرور، ورمز التحقق إن كان ثابتًا، ورقم الجوال التجريبي إن كان الدخول به.
مسار مختصر لتجربة الميزة الأساسية. خطوات مرقّمة: افتح، اضغط هنا، اختر هذا، ستظهر النتيجة. المراجع لا يعرف تطبيقك، وقد يفوّت ميزتك الأهم إن كانت خلف شاشتين.
تفسير أي إذن غير بديهي. إن كنت تطلب الموقع في تطبيق لا يبدو أنه يحتاجه، اشرح لماذا قبل أن يُسأل عنه.
حالة الميزات المرتبطة بحساب أو اشتراك. إن كانت ميزة تظهر للمشتركين فقط، أعطِ المراجع حسابًا مشتركًا فعلًا لا حسابًا عاديًا.
وما لا يُكتب: وعود بميزات قادمة، وشرح تسويقي للمنتج، وطلبات خاصة. الملاحظات وثيقة تشغيلية لا رسالة بيع.
جرّب عبر TestFlight أولًا
قبل الرفع للمراجعة العامة، وزّع النسخة على فريقك عبر برنامج الاختبار من آبل. الفائدة ليست في اكتشاف الأخطاء فقط، بل في أن النسخة تمرّ بمراجعة مبسّطة قبل التوزيع الخارجي، فتظهر بعض المشكلات مبكرًا.
والأهم: التثبيت من رابط اختبار يشبه تجربة المستخدم الحقيقي — تنزيل، وفتح أول مرة، وتسجيل دخول جديد — وهي بالضبط المرحلة التي تنكشف فيها أعطال الفتح الأول.
حالات تحتاج انتباهًا مضاعفًا
بعض فئات التطبيقات تخضع لتدقيق أشد، وتُرفض لأسباب لا تخطر على بال فريق لم يمرّ بها:
الاشتراكات المتجدّدة. يجب أن تُعرض المدة والسعر والتجديد التلقائي بوضوح قبل الشراء، وأن يجد المستخدم طريقًا لإدارة اشتراكه. الغموض هنا سبب رفض متكرر.
المحتوى الذي ينشئه المستخدمون. أي تطبيق يسمح بالنشر أو التعليق أو المحادثة مطالب بآلية إبلاغ وحظر وحذف سريع. غيابها يوقف تطبيقات المجتمعات والمحادثة.
تطبيقات الأطفال. قيود إضافية على الإعلانات وجمع البيانات والروابط الخارجية.
الصحة والمال. تُطلب مستندات تثبت أن الجهة مرخّصة لما تقدّمه، وقد يُسأل عن مصدر المعلومة الطبية أو عن الجهة المالية الشريكة. وقد مررنا بهذا في بناء أنظمة طبية، وهو ما يجعل التخطيط للامتثال جزءًا من التصميم لا خطوة أخيرة.
التطبيقات التي تعرض محتوى من طرف ثالث. يُسأل عن حقك في عرضه.
والتحديثات تُراجَع أيضًا
خطأ شائع: الظن أن المراجعة تحدث مرة واحدة. كل تحديث يمرّ بمراجعة، وقد يُرفض تحديث لتطبيق يعمل منذ سنوات — إما لأن القواعد تغيّرت، أو لأن التحديث أضاف ما يخالفها.
والأخطر: أن تُرفض في وقت حرج (حملة إعلانية، موسم، إصلاح عاجل). ولهذا نبقي في خططنا هامشًا زمنيًا قبل أي موعد مرتبط بتسويق.
نصيحة عملية: لا ترفع تحديثًا كبيرًا قبل عطلة أو موسم ذروة مباشرة. ارفعه قبلها بوقت كافٍ ليتسع لدورة رفض واحدة.
الخلاصة العملية: الرفض غالبًا إجرائي لا تقني. تسعة أسباب من عشرة يمكن إغلاقها بساعة تحضير قبل الرفع — حساب تجريبي يعمل، وزر حذف حساب، ونصوص أذونات صادقة، ولقطات مطابقة، وروابط تفتح. ومن يعرف هذه القائمة قبل أن يبني، يبني تطبيقًا يمرّ من أول مرة. وإن أردت مراجعة تطبيقك قبل الرفع، فهذا جزء أصيل من عملنا في تصميم تطبيقات آيفون.