رفض App Store بموجب المبدأ 2.1 (اكتمال التطبيق): خطة اختبار نسخة الإصدار قبل إعادة الإرسال (2026)

يعني رفض App Store بموجب المبدأ 2.1 (اكتمال التطبيق) أن المراجِع لم يتمكن من استخدام تطبيقك كما يستخدمه العميل. ربما تعطّل التطبيق، أو عرض محتوى مؤقتًا، أو أوقف المراجِع عند شاشة تسجيل الدخول، أو أخفى عملية شراء داخل التطبيق. ونادرًا ما يكون الإصلاح سطرًا واحدًا من الشيفرة. قبل إعادة الإرسال، نفّذ خطة اختبار قصيرة على نسخة الإصدار، باستخدام تثبيت جديد وبيانات الدخول نفسها التي تقدّمها لفريق App Review. يشرح هذا المقال تلك الخطة ويعرض كيف أصلح مطورون آخرون حالة الرفض نفسها.

ما الذي يتحقق منه المبدأ 2.1 (اكتمال التطبيق) في App Store؟

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

تقسّم إرشادات مراجعة App Store من Apple المبدأ 2.1 إلى جزأين. ينص 2.1(a) على أن الطلبات "يجب أن تكون نسخًا نهائية تتضمن جميع البيانات الوصفية اللازمة وروابط تعمل بالكامل"، وأن النصوص المؤقتة والمواقع الفارغة يجب إزالتها. كما يطلب منك الاختبار على جهاز فعلي بحثًا عن الأخطاء ومشكلات الاستقرار، و"تضمين معلومات حساب تجريبي (وتشغيل خدمة الخادم الخلفي!) إذا كان تطبيقك يتضمن تسجيل دخول". وتقول Apple إنها "سترفض حزم التطبيقات والملفات الثنائية غير المكتملة التي تتعطل أو تُظهر مشكلات تقنية واضحة". أما 2.1(b) فينص على أن المشتريات داخل التطبيق يجب أن تكون "مكتملة ومحدّثة وظاهرة للمراجِع وتعمل". وإذا تعذّر العثور على عملية شراء مُعدّة داخل التطبيق، فاشرح السبب في ملاحظات المراجعة.

هذا النوع من الرفض شائع. إذ تقول صفحة الاستعداد لمراجعة App Review من Apple: "في المتوسط، يتعلق أكثر من 40% من المشكلات غير المحلولة بالمبدأ 2.1: اكتمال التطبيق، الذي يشمل الأعطال والمحتوى المؤقت والمعلومات الناقصة وغير ذلك."

لماذا لا يكشف اختبار نسخة التصحيح (debug) مشكلات المبدأ 2.1؟

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

المحاكي لديك مسجَّل الدخول مسبقًا. وقد تشير واجهة API المحلية إلى خادم تجريبي لا يتوقف أبدًا. وإعدادات التصحيح تتخطى شاشة الدفع، وأعلام الميزات (feature flags) مفعّلة افتراضيًا. أما المراجِع فلا يحصل على أي من ذلك. كما تطلب صفحة المراجعة من Apple "الاختبار الشامل على أجهزة تعمل بأحدث البرامج"، لذا قد يستخدم المراجِع إصدار iOS أحدث من هاتف الاختبار لديك.

يُعد TestFlight أقرب ما يمكنك الوصول إليه من بيئة المراجِع. ووفقًا لـنظرة عامة على TestFlight، يمكنك إضافة ما يصل إلى 100 مختبِر داخلي من فريقك في App Store Connect وما يصل إلى 10,000 مختبِر خارجي. ويمكنك اختبار النسخة لمدة تصل إلى 90 يومًا. ارفع النسخة نفسها التي تنوي إرسالها، وثبّتها من TestFlight على جهاز لم يُشغَّل عليه التطبيق من قبل، واختبر تلك النسخة.

ما الذي يجب أن تغطيه خطة اختبار نسخة الإصدار قبل إعادة الإرسال؟

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

1. تثبيت نظيف على أحدث إصدار iOS. احذف أي نسخة سابقة، وثبّت التطبيق من TestFlight وشغّله دون أي حالة محفوظة. شغّله تشغيلًا باردًا ثلاث مرات وتأكد من أن شاشات التعريف لا تتعطل.
2. ارفض كل طلب إذن مرة واحدة. ارفض الإشعارات والموقع والكاميرا والتتبع. يجب أن يصل التطبيق مع ذلك إلى شاشة قابلة للاستخدام. وتأكد أيضًا من أن ملف Info.plist يحتوي على وصف استخدام لكل مورد محمي يستخدمه التطبيق أو حزم SDK الخاصة به.
3. سجّل الدخول ببيانات الحساب التجريبي نفسها تمامًا. انسخها من App Store Connect، لا من مدير كلمات المرور لديك. يجب أن يحتوي الحساب على بيانات واقعية، وألا يتطلب تأكيد البريد الإلكتروني، وألا يستخدم مصادقة ثنائية مرتبطة بهاتفك.
4. تأكد من أن الخادم الخلفي هو خادم الإنتاج وأنه يعمل. يجب أن تشير النسخة إلى نقاط نهاية الإنتاج. ويجب ألا تمنع حدود المعدّل أو قوائم عناوين IP المسموح بها أو الحظر الجغرافي المراجِعَ من الدخول. فالمبدأ 2.1(a) يطلب منك تشغيل خدمة الخادم الخلفي.
5. تصفّح كل تبويب وكل شاشة. ابحث عن نصوص lorem ipsum، وشاشات "قريبًا"، والحالات الفارغة بلا توضيح، وصور الاختبار، والأزرار التي لا تفعل شيئًا.
6. اضغط على كل رابط. يشمل ذلك سياسة الخصوصية والدعم والشروط وأي عروض ويب. تقول Apple: "رابط إلى دعم المستخدمين يتضمن معلومات اتصال محدّثة ورابط إلى سياسة الخصوصية مطلوبان لجميع التطبيقات."
7. افتح كل عملية شراء داخل التطبيق. سجّل الدخول بحساب جديد. تحقق من أن كل منتج مُرسَل مع الإصدار يظهر بسعره، ويمكن شراؤه في بيئة sandbox، وأن خيار استعادة المشتريات (Restore Purchases) يعمل.
8. اختبر على شبكة بطيئة أو منقطعة. فعّل وضع الطيران في منتصف أحد المسارات. رسالة خطأ واضحة مقبولة، أما مؤشر تحميل لا يتوقف أو تعطّل التطبيق فغير مقبول.
9. تحقق من iPad إذا كنت تدعمه. إذا كان التطبيق يعمل على iPad، فشغّله عليه وتأكد من أن التخطيط لا يحبس المستخدم.

يتسبب الحساب التجريبي في الخطوة 3 في حالات رفض متكررة أكثر من أي خطوة أخرى. ويشرح دليلنا حول إعداد حساب تجريبي لمراجعة App Store كيفية إنشاء حساب يدوم.

كيف تربط رسالة رفض 2.1 بالإصلاح المناسب؟

لربط رفض 2.1 بإصلاحه، اقرأ الجملة التي تلي رقم المبدأ. فهي تحدد العَرَض، وكل عَرَض يشير إلى خطوة واحدة في خطة الاختبار.

لنفترض أن تطبيقًا لتتبع العادات رُفض برسالة "We were unable to review the app because it crashed on launch" (لم نتمكن من مراجعة التطبيق لأنه تعطّل عند التشغيل). وتقول ملاحظة ثانية إن المراجِع لم يتمكن من العثور على المشتريات داخل التطبيق. يربط الجدول التالي الأعراض الشائعة بالسبب والاختبار والإصلاح.

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

كيف بدت حالات رفض 2.1 لدى مطورين آخرين؟

تتبع حالات 2.1 العلنية النمط نفسه. يعمل التطبيق في بيئة المطور ويفشل عند المراجِع بسبب أمر لا يكشفه إلا تثبيت جديد أو تسجيل دخول شخص غريب.

• تعطّل بسبب غياب وصف الاستخدام. في منتديات Solar2D، أُبلغ أحد المطورين بأنه "لم نتمكن من مراجعة التطبيق لأنه تعطّل عند التشغيل" على جهاز iPhone 13 mini يعمل بنظام iOS 18.3.2، رغم أن التطبيق كان يعمل في TestFlight. ووجد عضو آخر هذا في سجل التعطل المرفق: "تعطّل هذا التطبيق لأنه حاول الوصول إلى بيانات حساسة متعلقة بالخصوصية دون وصف استخدام." وأفاد المطور: "قُبل بعد إضافة: NSUserTrackingUsageDescription."
• تسجيلات دخول اجتماعية لم يستطع المراجِع استخدامها. أفاد مطور في منتديات مطوري Apple بتكرار رفضه بموجب 2.1 لأن المراجعين "لم يتمكنوا من استخدام تسجيلات الدخول الاجتماعية". كان قد قدّم حسابات تجريبية على Apple وGoogle، لكن تسجيل الدخول عبر Apple ID تطلّب رمز تحقق يُرسَل إلى هاتف المطور. وردّ موظفو Apple بأن فريق App Review سيتواصل معه مباشرة. ولم يُنشر أي حل علني.
• مشتريات داخل التطبيق "تعذّر العثور عليها في الملف الثنائي المُرسَل". في سلسلة نقاش على مجتمع RevenueCat، رُفض مطور لأن خطة شهرية لم يُعثر عليها في الملف الثنائي، رغم أن عمليات الشراء في بيئة sandbox كانت تعمل. وقال أحد المساعدين إن رفضًا مماثلًا حُلّ بالرد بشرح تفصيلي ولقطات شاشة لكل مسار يؤدي إلى شاشة الدفع. ونصح موظفو RevenueCat بعرض كل منتج مُرسَل على شاشة الدفع الافتراضية وإبقاء ملفات اختبار StoreKit خارج مخطط Archive.

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

ماذا يجب أن تتضمن ملاحظات App Review بعد رفض 2.1؟

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

تقول صفحة المراجعة من Apple إن بيانات الحساب والإعدادات الخاصة توضع في قسم App Review Information. وإذا كانت إحدى الميزات تتطلب جهازًا أو بيئة يصعب إعدادها، فـ"كن مستعدًا لتقديم فيديو توضيحي أو الجهاز نفسه". ويضيف المبدأ 2.3.1(a) أن الميزات الجديدة يجب وصفها "بدقة" في ملاحظات المراجعة (Notes for Review)، وأن "الأوصاف العامة سيتم رفضها". وتعمل ملاحظة قصيرة ومنظمة بشكل جيد:

Demo account: review@example.com / (password)
Account is pre-verified, has no 2FA and has 30 days of sample data.

Fixes since last submission (2.1):
- Launch crash on fresh install fixed (tested build 42 on latest iOS, clean device).
- In-app purchases: Settings > Upgrade shows Monthly and Yearly.
- Backend is production and will stay live during review.

Non-obvious features:
- Widgets: long-press Home Screen > add "Streaks" widget.

إذا كانت الالتزامات القانونية أو الأمنية تمنع تقديم حساب تجريبي، فإن المبدأ 2.1(a) يسمح بوضع تجريبي مدمج، لكن بموافقة مسبقة من Apple فقط، ويجب أن يعرض هذا الوضع جميع ميزات التطبيق ووظائفه. لا تنتقل إلى وضع تجريبي دون تلك الموافقة.

كيف تعيد الإرسال أو تطعن في رفض 2.1؟

لإعادة الإرسال بعد رفض 2.1، ارفع النسخة التي اختبرتها أو اخترها، وردّ على App Review في App Store Connect بما غيّرته، وحدّث ملاحظات المراجعة، ثم أرسل من جديد. ولا تطعن إلا إذا كنت تعتقد أن المراجِع أساء فهم التطبيق.

1. تحقق من أن رقم النسخة المرتبط بالإصدار في App Store Connect يطابق نسخة TestFlight التي اختبرتها.
2. ردّ على رسالة الرفض بملخص قصير لكل إصلاح. وفي مشكلات الشراء أو التنقل، أضف تعليمات خطوة بخطوة ولقطات شاشة.
3. حدّث قسم App Review Information ببيانات الدخول والملاحظات الحالية.
4. أرسل للمراجعة. حتى أكتوبر 2026، تقول Apple إنها تراجع عادةً "50% على الأقل من الطلبات في أقل من 24 ساعة و90% في أقل من 48 ساعة".

إذا كنت تعتقد أن Apple أخطأت، فإن صفحة App Review تتيح لك الطعن أمام مجلس App Review. قدّم أسبابًا محددة توضح امتثال التطبيق، و"قدّم طعنًا واحدًا فقط لكل إرسال لم يجتز المراجعة". لكن في حالة رفض 2.1، تكون إعادة إنتاج المشكلة على جهاز نظيف أسرع عادةً من الجدال. وإذا فضّلت تسليم إعادة الإرسال لغيرك، فإن خدمة الإرسال إلى App Store لدينا تغطي التحضير للمراجعة والتعامل مع ملاحظات الرفض في كلا المتجرين مقابل $599، مع احتساب رسوم حساب المطور بشكل منفصل.

كثيرًا ما تعود مشكلات 2.1 في التحديثات اللاحقة: علم ميزة جديد، أو مفتاح API تم تغييره، أو حساب تجريبي منتهي الصلاحية. أضف خطة الاختبار هذه إلى روتين الإصدار لديك إلى جانب قائمة التحقق من الإرسال إلى App Store. وفي التحديثات، يحدّ الإصدار المرحلي من عدد المستخدمين الذين قد يصل إليهم خطأ فاتك. وللحصول على رأي ثانٍ في نسخة مرفوضة، راسل yagyeshsrbobde@gmail.com مع إرفاق رسالة الرفض.