طلب مراجعة مستعجلة في App Store: الطريقة الصحيحة

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

تطبيقاتي، Solys وTradaZen وNolera، مبنية بـ Expo. عندما يكون الخطأ في كود JavaScript، أرسل الإصلاح كتحديث عن بُعد، من دون المرور بـ App Review. لذلك لا أحتاج المراجعة المستعجلة إلا لبناء أصلي (native)، وهذا أيضًا أول سؤال عليك طرحه قبل أن تطلبها. يتّبع هذا الدليل صفحة مساعدة Apple حول المراجعة المستعجلة، التي راجعتها في 6 نوفمبر 2026.

ما تذكره Apple، وما لا يُقبل

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

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

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

الخطوات الثلاث

1. أرسل النسخة في App Store Connect. لا يمكن تسريع إلا إرسال تم بالفعل. إذا كانت بعض الوظائف تتطلب تسجيل الدخول، أضف حساب تجربة في قسم App Review Information.
2. املأ حقل Notes عند الإرسال. في حالة خطأ حرج، صف الخطأ الذي أصلحته وكيف يُعاد إنتاجه في النسخة الحالية. في حالة حدث، اذكر اسمه وتاريخه وما يربط تطبيقك به.
3. أرسل نموذج Request an Expedited App Review، الذي تصل إليه من صفحة مساعدة Apple بعد تسجيل الدخول إلى حساب المطوّر. تختار فيه التطبيق والمنصة المعنيين، ثم ترسل.

تدرس Apple الطلب وترد عليك، ثم تتابع الإرسال في App Store Connect. إذا قُبل الطلب، تنتقل النسخة إلى حالة In Review أبكر مما كانت ستصل إليه في الطابور. وإذا رُفض، تستمر المراجعة بشكل طبيعي: لا تخسر شيئًا.

زر Reply to App Review في App Store Connect لا يُستخدم لطلب مراجعة مستعجلة. صفحة التواصل مع App Review تخصّصه للمراسلات حول إرسال قيد المراجعة، أما الطلب المستعجل والطعن فلكل منهما نموذجه الخاص.

ماذا تكتب: نموذجان

فريق App Review يقرأ بالإنجليزية. هذان النصان اللذان أحتفظ بهما جاهزين، لتعدّلهما في Notes، وفي النموذج إن كان فيه حقل حر. يتكوّنان من خمسة أسطر لأن المراجِع يجب أن يفهم سبب الاستعجال من دون فتح التطبيق.

خطأ حرج في النسخة المنشورة:

Version 2.0.3, currently live, crashes at launch for users who enabled notifications on iOS 26.1. Steps to reproduce: install 2.0.3, allow notifications, force quit, relaunch. The app closes immediately. Version 2.0.4 fixes the crash (notification permission is now read after the first screen loads). No other change in this build.

إصدار مرتبط بحدث:

This version adds the official schedule and live results for the Nantes Trail Festival on June 5, 2027. Our app is the event's official companion app (see the link to the organizer's page in the App Review Information section). Attendees need the update before the start on June 5 at 8:00 AM CEST.

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

قبل الطلب، تأكد أنك تحتاجه

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

هل يمكن تمرير الإصلاح من دون مراجعة؟ مع Expo، يستبدل التحديث عن بُعد كود JavaScript في التطبيقات المثبّتة من دون بناء جديد. هذا هو الطريق الذي أستخدمه لإصلاحاتي. لكنه لا يشمل الكود الأصلي ولا الأذونات ولا الاعتماديات الأصلية: لهذه تحتاج بناءً ومراجعة. ويجب أن يبقى محتواه ضمن ما وافقت عليه Apple، كما يذكّر تقديم EAS Update: التحديث عن بُعد لا يغيّر الغرض من التطبيق. يشرح دليل النشر التدريجي لتحديث iOS ما يمر عبر كل طريق.

هل الانتظار غير طبيعي؟ تقول Apple إنها تراجع عادةً 50 % على الأقل من الإرسالات في أقل من 24 ساعة و90 % في أقل من 48 ساعة. إذا كانت نسختك في انتظار المراجعة منذ يوم، فأنت ضمن المدة المعتادة لمراجعة App Store. وتذكّر صفحة متابعة الإرسال أيضًا بما يطيل المراجعة: أول تطبيق بلا سجل سابق، مستندات تحتاج تحققًا، موضوع خاضع للتنظيم.

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

والأهم، لا تسحب نسختك لتعيد إرسالها. النسخة المسحوبة تخرج من الطابور وتبدأ من الصفر. إذا طرحت عليك Apple سؤالًا أثناء المراجعة، أجب في App Store Connect بدل إعادة الإرسال، كما يشرح دليل الرد على App Review في Resolution Center.

إذا رفضت Apple التسريع

تحتفظ بمكانك في الطابور: رفض التسريع لا يغيّر شيئًا في المراجعة الجارية. ولكي لا تتكرر الحالة:

• جدوِل إصداراتك. بالنسبة للأحداث، تنصح Apple باختيار النشر المجدول في App Store Connect: تُراجَع النسخة مسبقًا وتصدر في التاريخ الذي تريده. يُضبط خيار نشر النسخة في صفحة النسخة، ضمن قسم App Store Version Release.
• أرسل مبكرًا. نسخة جاهزة قبل الحدث بأسبوع تترك وقتًا لمراجعة عادية، بل ولإصلاح رفض محتمل.
• احتفظ بقناة بلا مراجعة لكود JavaScript. مع Expo، هذا ما يحوّل الخطأ الحرج إلى إصلاح يستغرق دقائق.

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

الأسئلة الشائعة

كم تستغرق المراجعة المستعجلة في App Store؟

لا تعطي Apple أي مدة. تقول إنها تدرس كل طلب وتسرّع المراجعة حسب قدرتها وحجم الطلبات في ذلك الوقت. الطلب المقبول ينقل النسخة إلى In Review قبل دورها، من دون وعد بساعة محددة.

هل يمكن طلب مراجعة مستعجلة لأول تطبيق؟

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

كم مرة يمكن طلب مراجعة مستعجلة؟

لا تنشر Apple عددًا محددًا. تطلب حصر الطلبات في حالات الاستعجال الحقيقية. في رأيي، كل طلب بلا سبب حقيقي يجعل الطلب التالي أقل مصداقية: احتفظ به لخطأ يؤثر على مستخدميك.

هل يجب سحب الإرسال قبل طلب التسريع؟

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

أين أجد نموذج المراجعة المستعجلة؟

على موقع Apple للمطوّرين، بعد تسجيل الدخول إلى حسابك: صفحة المساعدة الخاصة بالمراجعة المستعجلة تقودك إليه عبر رابط Request an Expedited App Review. تختار فيه التطبيق والمنصة المعنيين.

هل تضمن المراجعة المستعجلة قبول التطبيق؟

لا. هي تغيّر فقط موقعك في الطابور. يجب أن تلتزم النسخة بـ App Review Guidelines مثل أي نسخة أخرى، ويبقى الرفض واردًا.

هل يمكن إصلاح خطأ من دون المرور بـ App Review؟

مع Expo أو React Native، يستبدل التحديث عن بُعد كود JavaScript من دون بناء جديد أو مراجعة. أما الكود الأصلي والأذونات والاعتماديات الأصلية فتتطلب دائمًا بناءً يُرسَل إلى Apple.