لماذا يستغرق مراجعة التطبيق وقتًا طويلاً؟

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

لقد قمت بتحميل البنية، وفحصت لقطات الشاشة، وخططت لإطلاقك. ثم لا يحدث شيء. لا يزال App Store Connect يقول في انتظار المراجعة، أو تحتفظ Play Console بتغييراتك قيد المراجعة. وفي الوقت نفسه، كل يوم من عدم اليقين يجعل تنسيق التسويق ودعم العملاء وإعلان الإصدار أكثر صعوبة.

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

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

تقول Apple إنه في المتوسط، تتم مراجعة 90% من التقديمات في أقل من 24 ساعة. هذا سياق مفيد، لكنه ليس ضمانًا لوقت إنجاز تطبيقك الفردي. بعض التقديمات تقع خارج هذه النافذة، والإحصائية لا تعطيك وقت إكمال لهذه الاستثناءات. تحذر Apple أيضًا من أن التقديمات غير المكتملة يمكن أن تؤخر المراجعة. [1]

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

أولاً، حدد مكان التأخير الفعلي

اقرأ الحالة بدقة بدلاً من ترجمة كل مؤشر أصفر إلى "Apple تراجع تطبيقي". Waiting for Review يعني أن الإرسال في الطابور؛ In Review يعني أن المراجعة بدأت. Pending Developer Release يعني أن التطبيق تم قبوله لكنه لا يزال بحاجة إلى إجراء الإصدار منك. Waiting for Export Compliance عملية مختلفة. يمكن أن يبقى عنصر مقبول غير منشور إذا تم رفض عنصر آخر في إرساله. [2]

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

يحتاج المراجعون إلى تجربة التطبيق الكامل

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

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

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

الرفض يحتاج إلى إجابة، وليس مزيدًا من الانتظار

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

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

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

معالجة البناء وTestFlight هما نقطتا تحقق منفصلتان

البناء المرفوع ليس بالضرورة جاهزًا للتقديم. مرجع حالة البناء من Apple يميز بين المعالجة، ومعلومات الامتثال المفقودة، والجاهزية للتقديم. كما يميز بين حالات TestFlight "في انتظار المراجعة" و"في مراجعة بيتا" عن التوفر للمختبرين الداخليين. قد يتطلب اختبار بيتا الخارجي مراجعة تطبيق TestFlight. [5]

إذا كانت نسختك التجريبية عالقة، فافحص حالة البناء قبل البحث عن مشكلة في طابور مراجعة App Store. بالنسبة لـ Missing Compliance، توجه Apple المطورين للإجابة على أسئلة التشفير أو تقديم الوثائق ذات الصلة. يمكن لبعض البناءات الإعلان عن إعفاء قابل للتطبيق من خلال إعداداتها، ولكن يجب عليك الإجابة بدقة بدلاً من تغيير الإعدادات فقط لتجاوز المطالبة. [6]

المعتمد لا يعني دائمًا متاحًا فورًا

يفصل سير عمل النشر من Apple بين اختيار البناء، وتحديد التوفر، والتقديم، وحل مشكلات المراجعة، والتوزيع. تقول إن التطبيق المعتمد قد يستغرق حتى 24 ساعة ليصبح متاحًا. كما تختار ما إذا كان الإصدار يدويًا أو تلقائيًا أو مرحليًا. تحقق من هذه الإعدادات قبل وصف نسخة معتمدة بأنها "لا تزال قيد المراجعة". [7]

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

Google Play لديه نافذة مراجعة مختلفة

لا تطبق توقيت عناوين Apple على Google Play. تقول Google إن المراجعات قد تستغرق بضع ساعات أو حتى سبعة أيام، وأطول في حالات استثنائية. كما تحذر نظرة عامة على النشر من أن تقديم تغيير آخر أثناء مراجعة التغييرات قد يدفع التطبيق إلى الخلف في قائمة انتظار المراجعة. لذلك قد تعمل التعديلات الصغيرة المتكررة ضد إصدار يمكن التنبؤ به. [9]

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

مثال عملي: التشخيص قبل إعادة الإرسال

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

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

متى يجب عليك الاتصال بـ Apple؟

للتأخير الطويل غير المعتاد وغير المفسر، استخدم مسار الاتصال بمراجعة Apple مع جدول زمني موجز ومعرفات التقديم. صف الحالة الحالية وأي مراسلات سابقة وما قمت بفحصه بالفعل. لا يوجد حد عالمي لعدد الأيام في التوجيه المذكور يضمن التصعيد. تجنب اختلاق واحد أو الوعد بأن رسالة دعم ستدفع تطبيقك للأمام.

المراجعة المعجلة هي طلب منفصل. تقدم Apple أمثلة مثل إصلاح خطأ حرج أو إصدار مرتبط بحدث ترتبط به مباشرة. اشرح الظرف الفعلي والتأثير؛ نفاد صبر التسويق العادي ليس الشيء نفسه. لا ينبغي تقديم طلب معجل كاختصار مضمون. [1]

خطط للإطلاق حول عدم اليقين

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

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

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

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