رفض App Review: الأسباب الأربعة التي تتكرر

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

الأسباب المتكررة قليلة ومعروفة. من يعرفها قبل الإرسال الأول يوفّر أسبوعين من الذهاب والإياب، ومن يكتشفها بعد الرفض الثالث يظن أن المشكلة في حظه.

السبب الأول: التطبيق لا يفعل ما يكفي

البند الأشهر، ويُصاغ عادةً بأن التطبيق «محدود الوظائف» أو «يشبه موقع ويب».

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

ما يعالج هذا فعلًا ليس إضافة شاشات، بل إضافة قدرة يملكها الجهاز وحده:

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

واحدة من هذه غالبًا تكفي. والخطأ الشائع أن يضيف المطوّر خمس شاشات جديدة بلا قدرة جديدة، فيُرفض مرة أخرى بالبند نفسه.

المراجع لا يقرأ نيّتك. يفتح التطبيق على جهاز لم يره من قبل، ويحكم على ما رآه في خمس دقائق.

السبب الثاني: الخصوصية لا تطابق السلوك

ليس ضعف السياسة، بل التناقض بينها وبين ما يفعله التطبيق.

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

ثلاث خطوات تحسم هذا قبل الإرسال:

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

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

السبب الثالث: المراجع لم يستطع الدخول

سبب سخيف ويستهلك دورة مراجعة كاملة.

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

ما يجب أن يكون في ملاحظات المراجعة:

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

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

هل رفض المراجعة يؤثر على النسخ اللاحقة؟

رفض المراجعة لا يترك أثرًا، وهذا سوء فهم شائع يدفع الناس إلى قرارات سيئة.

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

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

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

ما سبب رفض المراجعة الذي لا يُذكر في الرد؟

العطل عند أول تشغيل، ويأتي غالبًا بصياغة «التطبيق أُغلق أثناء المراجعة» بلا تفصيل.

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

ثلاثة أنماط تتكرر:

• قيمة مفترضة غير موجودة: قراءة إعداد لم يُكتب بعد، ثم استخدامه مباشرة.
• إذن مرفوض لم يُعالَج: المستخدم يرفض الكاميرا، والكود يفترض الموافقة.
• شبكة غائبة: المراجع قد يختبر على شبكة مقيّدة، والتطبيق ينهار بدل أن يعرض رسالة.

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

البند الذي يفاجئ من يبيع اشتراكًا

فئة رابعة تستحق ذكرها لأنها تصيب كل من يضيف مشتريات لأول مرة.

الاستعادة ليست اختيارية. أي تطبيق يبيع شيئًا غير استهلاكي أو اشتراكًا يجب أن يوفّر طريقة ظاهرة لاستعادة المشتريات، ورفض المراجعة بسببها متكرر جدًا. الزر يجب أن يكون موجودًا ومرئيًا، لا مخفيًا في إعداد فرعي.

وثلاثة تفاصيل تُنسى معه:

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

الثلاثة معًا خمس دقائق عمل، وغيابها دورة مراجعة كاملة.

قائمة ما قبل الإرسال

عشر دقائق قبل الضغط على «إرسال» توفّر أسبوعًا.

1. ثبّت النسخة على جهاز نظيف — لا جهازك، ولا محاكيًا. الأعطال عند أول تشغيل تظهر هنا فقط.
2. جرّب الشراء والاستعادة بحساب Sandbox، وتأكد أن زر الاستعادة موجود ويعمل.
3. راجع بطاقة الخصوصية مقابل قائمة مكتباتك، لا مقابل ذاكرتك.
4. اكتب ملاحظات المراجعة بحساب تجريبي وخطوات ومقطع مصور لأي ميزة تحتاج جهازين.
5. افتح كل شاشة بالعربية والإنجليزية إن كنت تدعم الاثنتين، وابحث عن نص مقطوع أو اتجاه معكوس.

الخطوة الأولى وحدها تلتقط أكثر الرفوض شيوعًا على الإطلاق: تطبيق ينهار عند أول تشغيل لأنه يعتمد على بيانات موجودة على جهاز المطوّر وحده.

وثائق آبل لـ إرشادات المراجعة هي المرجع، والبنود 2.1 و4.2 و5.1 تغطي أغلب ما سبق. اقرأها مرة كاملة قبل أول إرسال، ثم ارجع إليها عند كل رفض.

كم تستغرق المراجعة، ومتى تقلق؟

المدة المعتادة قصيرة — غالبًا أقل من يوم للنسخ العادية — وهذا يغيّر استراتيجية الإرسال أكثر مما يظن الناس.

حين تكون المراجعة سريعة، يصبح الإرسال المبكر رخيصًا. أرسل نسخة صغيرة، واعرف النتيجة اليوم، وأصلح غدًا. مقابل ذلك، من ينتظر شهرًا ليجمع عشرة تغييرات يدفع الثمن نفسه لكن بمعلومات أقل.

متى تقلق فعلًا: إن تجاوزت المراجعة أيامًا عدة دون تغيّر الحالة، فغالبًا التطبيق في مراجعة إضافية لسبب يستحق الانتظار — ميزة حساسة، أو فئة تحتاج تدقيقًا، أو مراجعة يدوية أعمق. الاستعجال هنا لا يفيد.

ولا ترسل نسخة مهمة قبل عطلة أو قبل إجازة فريق المراجعة. الأسبوع الذي يسبق موسمًا كبيرًا هو الأبطأ في السنة، ومن يخطط لإطلاق مرتبط بتاريخ يحتاج هامشًا لا يقلّ عن أسبوع.

الخلاصة

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

كلها تُفحص في عشر دقائق قبل الإرسال. وأرسل صغيرًا ومبكرًا — النسخة التي تحمل تغييرًا واحدًا تخبرك بالضبط ما الذي رُفض.