رفض التطبيق في App Store: كيف تُصلحه إرشادًا بإرشاد (2026)

رفض التطبيق في App Store هو رسالة من App Review تستشهد بإرشاد معيّن، وتصف ما رآه المراجع، وتوقف الإصدار حتى تُصلح المشكلة أو توضّحها أو تطعن في القرار. ابدأ بتحويل هذه الرسالة إلى مشكلة يمكنك اختبارها. وتعتمد الخطوة التالية على ما إذا كان المراجع لم يتمكن من استخدام التطبيق، أو وجد تعارضًا مع السياسات، أو يحتاج إلى مزيد من المعلومات. حتى أكتوبر 2026، كان آخر تحديث لـإرشادات App Review في 16 أكتوبر 2026، لذا تحقّق من الترقيم الحالي قبل الاستشهاد بأي قسم.

ماذا تخبرك رسالة رفض App Store فعلًا؟

تذكر رسالة رفض App Store الإرشاد الذي طبّقه المراجع، وتصف السلوك المحدد الذي رآه، وتسرد الخطوات التالية. وغالبًا ما تتضمن الجهاز وإصدار iOS ولقطات شاشة.

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

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

ما الإرشادات التي يستشهد بها رفض App Store، وماذا تتطلب؟

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

أضاف تحديث 16 أكتوبر 2026 الإرشاد 2.5.19 الخاص بالميزات المخفية أو الخاملة أو غير الموثّقة، والتي كانت مشمولة سابقًا في 2.3.1. كما أضاف 2.3.14 بشأن الأصول الإبداعية، ودمج استحقاق Music Streaming Services في استحقاق StoreKit External Purchase Link ضمن 3.1.1(a). تعامل مع الجدول كنقطة انطلاق لا كإصلاح مضمون. فقد يغطي إرشاد واحد مشكلات مختلفة، والمثال الذي يقدّمه المراجع هو الحالة المحددة التي عليك حلها.

كيف تُصلح رفضًا بموجب الإرشاد 4.2 (الحد الأدنى من الوظائف)؟

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

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

كيف تردّ على App Review في App Store Connect؟

ردّ في App Store Connect: افتح الإرسال من رابط المشكلات غير المحلولة الخاص بالتطبيق، وانقر على Resolve، ثم انقر على Reply to App Review. ووفقًا لـصفحة المساعدة من Apple، يتطلب ذلك دور Account Holder أو Admin أو App Manager.

1. في Apps، اختر التطبيق.
2. في أعلى الصفحة، انقر على الرابط الذي يشير إلى وجود مشكلات غير محلولة.
3. في قسم In Progress، انقر على Resolve بجوار الإرسال.
4. انقر على Reply to App Review وأدخل نص ردّك.
5. لإرفاق لقطات شاشة أو مستندات، انقر على Attach File، ثم انقر على Reply.

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

هل تُصلح البيانات الوصفية، أم ترفع بنية جديدة، أم تطعن؟

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

تطلب إرشادات الطعن من Apple أن «توضّح نقطة بنقطة كيف يستوفي تطبيقك» الإرشاد. كما تنص على عدم الطعن بعد أن تكون قد أصلحت المشكلات وأعدت الإرسال بالفعل. والطعن المكتمل «لا يضمن» إلغاء القرار. أما بالنسبة إلى التطبيقات الموجودة بالفعل في المتجر، فتنص سياسة Bug Fix Submissions في الإرشادات على أن إصلاحات الأخطاء لن تتأخر بسبب مخالفات الإرشادات «باستثناء تلك المتعلقة بالمسائل القانونية أو مسائل السلامة».

كيف أصلح مطورون آخرون حالات رفض حقيقية في App Store؟

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

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

عطل عند التشغيل. في منتدى Solar2D، تلقّى مطور رسالة «لم نتمكن من مراجعة التطبيق لأنه تعطّل عند التشغيل» على iPhone 13 mini بنظام iOS 18.3.2. وأظهر سجل الأعطال المرفق غياب المفتاح NSUserTrackingUsageDescription. وأكد المطور: «اجتاز المراجعة بعد إضافة: NSUserTrackingUsageDescription».

تطبيق WebView بموجب 4.2. أبلغ مطور في منتديات Apple للمطورين عن الرفض العاشر لتطبيق قائم على WebView. كان المراجع قد أرسل لقطة شاشة للقائمة الجانبية اليسرى قائلًا إنها تفتقر إلى المحتوى. أصبحت الشاشات الرئيسية أصلية، لكن شاشتين أو ثلاثًا كانت لا تزال تفتح WebView. وجاء الرد المعلَّم كإجابة من App Review، وأوصى بجلسة استشارة فردية مع App Review. ولا يؤكد النقاش حصول التطبيق على الموافقة.

المقارنة: أُصلحت حالات 2.1 بإعادة إنتاج ظروف المراجع وقراءة سجل الأعطال. أما حالة 4.2 فتعثّرت لأن كل إعادة إرسال غيّرت جزءًا فقط من تطبيق كان لا يزال في معظمه موقع ويب.

كيف تمنع تكرار الرفض نفسه؟

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

• احذف التطبيق، ثم ثبّت بنية الإصدار من جديد على iPhone وiPad فعليين.
• سجّل الدخول بحساب المراجعة على شبكة لا تحتوي على خوادم تطوير أو استثناءات HTTP.
• افتح كل طلب إذن وتأكد من وجود كل وصف استخدام في Info.plist.
• تأكد من أن كل عملية شراء داخل التطبيق مُرسلة ومرئية وموضّحة في ملاحظات المراجعة.
• حدّث ملاحظات المراجعة كلما تغيّر مسار ما. لا تلصق ملاحظات من ستة إصدارات سابقة.

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