رفض التطبيق من App Store: أشهر الأسباب وكيف ترد على المراجعة
رفضت Apple تطبيقك والإطلاق مرتبط بموعد. هذا الدليل لصاحب المشروع ومدير التقنية: يبدأ من رقم الإرشاد في رسالة الرفض، ويصل بك إلى السبب المرجح، والمسار الصحيح بين الإصلاح والرد والاستئناف، وما يمنع تكرار الرفض.
رفض التطبيق من App Store يأتي دائمًا برقم إرشاد محدد من إرشادات المراجعة، وهذا الرقم هو نقطة البداية لا نص الرسالة وحده. أغلب حالات الرفض تعود إلى مجموعات قليلة: تطبيق غير مكتمل أو ينهار أو لم يستطع المراجع الدخول إليه، وبيانات متجر أو خصوصية لا تطابق التطبيق، وطريقة دفع لا تناسب نوع ما تبيعه، ووظيفة محدودة تشبه موقعًا مغلفًا، ونقص مثل حذف الحساب من داخل التطبيق. حدد الإرشاد، ثم اسأل: هل المراجع محق؟ إن كان محقًا فأصلح وأعد التقديم، وإن أساء الفهم فرد عليه بتوضيح وأدلة، وإن اختلفت معه في التفسير فقدّم استئنافًا.
وصلتك رسالة من Apple تقول إن تطبيقك لم يجتز المراجعة، والإطلاق مرتبط بحملة أو بموعد مع عملائك. أول ما يفعله كثيرون هو تعديل سريع وإعادة رفع، فيعود الرفض نفسه بعد أيام. هذا الدليل يمشي معك بترتيب التشخيص: كيف تقرأ رسالة الرفض، وما السبب المرجح وراء كل إرشاد يتكرر، ومتى يكفي الرد دون بناء جديد، وكيف تكتب الرد، وما الذي تفحصه قبل كل رفع حتى لا تتكرر القصة.
اقرأ رسالة الرفض أولًا: أربعة أشياء تبحث عنها
رسالة الرفض في App Store Connect ليست نصًا عامًا. فيها معلومات تحدد نوع المشكلة ومسار علاجها، إن قرأتها بترتيب:
- رقم الإرشاد: مثل 2.1 أو 4.2 أو 5.1.1. افتح إرشادات مراجعة App Store واقرأ نص البند كاملًا، لا العنوان فقط. البند 5.1.1 وحده يغطي سياسة الخصوصية وتسجيل الدخول وحذف الحساب وجمع البيانات، والرسالة تشير عادة إلى فقرة بعينها.
- ما الذي رآه المراجع: وصف الخطوات التي نفذها، والجهاز وإصدار النظام، وأحيانًا لقطة شاشة أو سجل انهيار مرفق. هذا الجزء يخبرك هل المشكلة في الكود، أم في البيئة التي راجع عليها، أم في فهمه لمسار التطبيق.
- مكان المشكلة: هل الملاحظة على التطبيق نفسه (سلوك، انهيار، دفع)، أم على بيانات صفحة المتجر (الوصف، اللقطات، رابط الخصوصية، التصنيف العمري)؟ الثانية تُصلح غالبًا من App Store Connect دون بناء جديد.
- هل هي رفض أم طلب معلومات: أحيانًا يطلب المراجع توضيحًا أو حساب دخول أو فيديو يشرح ميزة يصعب الوصول إليها. هذا ليس حكمًا على التطبيق، وجوابه رسالة لا إصدار جديد.
انسخ الرسالة كاملة إلى ملف المشروع قبل أي تعديل، وسجّل رقم الإصدار الذي رُفض. حين يتكرر الرفض، هذا السجل هو ما يكشف هل عدت إلى المشكلة نفسها أم ظهرت مشكلة جديدة.
جدول تشخيص رفض التطبيق من App Store: الإرشاد والسبب والعلاج
تقول Apple في صفحة App Review إن أكثر من 40% من المشكلات التي لا تُحل في المراجعة، في المتوسط، ترتبط بالإرشاد 2.1 (اكتمال التطبيق): الانهيار، والمحتوى المؤقت، والمعلومات الناقصة. لذلك ابدأ التشخيص منه، ثم انتقل إلى بقية الأسباب المتكررة في الجدول:
| الإرشاد والسبب | ما يحدث فعلًا في المشروع | العلاج | بناء جديد؟ |
|---|---|---|---|
| 2.1 انهيار أو خطأ ظاهر | التطبيق اختُبر على جهاز المطور وإصدار نظام أقدم، وانهار على الجهاز الذي راجع عليه المراجع | اقرأ سجل الانهيار المرفق، أعد إنتاجه على الجهاز والإصدار نفسيهما، ثم أصلح السبب | ✓ نعم |
| 2.1 المراجع لم يستطع الدخول | لا يوجد حساب تجريبي، أو كلمة مروره تغيرت، أو الدخول برمز يُرسل إلى جوال سعودي لا يملكه المراجع | حساب مراجعة يعمل على بيئة الإنتاج، وشرح المسار في ملاحظات المراجعة | ✗ غالبًا لا |
| 2.1 الخادم متوقف أو فارغ | المراجعة تمت على خادم تجريبي أُطفئ، أو على بيانات فارغة فبدت الشاشات معطلة | تشغيل الخدمات أثناء المراجعة، وبيانات حقيقية كافية لتظهر الوظائف | بحسب السبب |
| 2.1 محتوى مؤقت أو روابط معطلة | نصوص تجريبية، أو صفحة «قريبًا»، أو رابط دعم أو خصوصية لا يفتح | إزالة كل محتوى مؤقت، وفحص كل رابط في التطبيق وفي صفحة المتجر | بحسب مكان الخلل |
| 2.3 بيانات متجر غير دقيقة | لقطات من تصميم قديم، أو وصف يعد بميزة غير موجودة، أو لقطات لا تُظهر التطبيق أثناء الاستخدام | لقطات من الإصدار المقدم نفسه، ووصف يطابق ما يجده المستخدم | ✗ لا |
| 3.1.1 الدفع لمحتوى رقمي خارج نظام Apple | اشتراك يفتح مزايا داخل التطبيق يُدفع عبر بوابة دفع عادية | مراجعة نوع ما تبيعه: الميزات والمحتوى الرقمي عبر الشراء داخل التطبيق، والسلع والخدمات المستهلكة خارجه عبر بوابة أو Apple Pay (البند 3.1.3(e)) | ✓ غالبًا، وقد يتغير نموذج العمل |
| 4.2 وظيفة محدودة | التطبيق عرض لموقع داخل إطار، أو قائمة روابط، أو بلا قيمة تتجاوز الموقع | إضافة تجربة تطبيق فعلية: تنقل أصلي، ودخول محفوظ، وإشعارات لها وظيفة، ومزايا من الجهاز | ✓ نعم، وقد يكون مشروعًا |
| 4.3 أو 4.2.6 تطبيقات متشابهة أو من قالب | تطبيق مستقل لكل فرع أو مدينة، أو تطبيق من قالب تجاري قدّمه صاحب القالب لا صاحب المحتوى | دمج النسخ في تطبيق واحد يختار فيه المستخدم الفرع، والتقديم من حساب صاحب المحتوى | ✓ نعم |
| 4.8 خيارات الدخول | دخول بحساب Google أو غيره للحساب الأساسي دون خيار بديل يحفظ الخصوصية | إضافة خيار دخول يستوفي شروط البند، مثل Sign in with Apple | ✓ نعم |
| 5.1.1 الخصوصية وحذف الحساب | لا يوجد رابط سياسة خصوصية داخل التطبيق، أو التطبيق ينشئ حسابًا ولا يتيح حذفه من داخله، أو يطلب إذنًا دون شرح سببه | رابط سياسة في التطبيق والمتجر، ومسار حذف حساب داخل التطبيق، ونص واضح لكل إذن | ✓ غالبًا |
العمود الأخير هو ما يهمك إداريًا: إن كان العلاج في ملاحظات المراجعة أو صفحة المتجر، فقد يُحل الرفض سريعًا دون انتظار بناء واختبار جديدين. وإن كان في نموذج الدفع أو في فكرة التطبيق نفسها (4.2 و3.1.1)، فأنت أمام قرار منتج قبل أن يكون إصلاحًا برمجيًا.
حالات تتكرر في التطبيقات السعودية ولا تذكرها الأدلة العامة
بعض أسباب الرفض تظهر أكثر في تطبيقات تخدم السوق المحلي، لأن المراجع يعمل من خارج المملكة، بجهاز وأرقام ومواقع لا تشبه مستخدمك.
الدخول برمز يصل إلى جوال سعودي
تطبيق يعتمد على رقم الجوال ورمز تحقق (OTP) كوسيلة دخول وحيدة. المراجع لا يملك رقمًا سعوديًا، فيتوقف عند الشاشة الأولى ويرفض بالإرشاد 2.1. العلاج المعتاد: حساب مراجعة برقم محدد يقبل رمزًا ثابتًا معروفًا، مفعّل في الخادم لهذا الرقم وحده، مع كتابة الرقم والرمز في قسم معلومات المراجعة. لا تطفئ هذا الحساب بعد الموافقة؛ ستحتاجه في كل تحديث.
الدخول بالنفاذ الوطني فقط
تطبيقات الجهات والخدمات التي تشترط النفاذ الوطني الموحد للدخول تواجه الموقف نفسه بصورة أصعب، لأن المراجع لا يملك هوية سعودية. الإرشادات تطلب حساب دخول فعالًا أو وضع عرض تجريبي (Demo Mode) كامل الوظائف، وتنص على أن وضع العرض بدل الحساب يحتاج موافقة مسبقة من Apple حين يتعذر تقديم حساب لأسباب نظامية أو أمنية. خطط لهذا في التصميم، لا بعد أول رفض.
خدمة محصورة في مدن أو أحياء
تطبيق توصيل أو خدمات منزلية لا يقبل الطلب خارج نطاق التغطية. المراجع يفتح التطبيق من موقعه فيرى «الخدمة غير متاحة في منطقتك» في كل شاشة، فيبدو التطبيق فارغًا أو معطلًا. اشرح النطاق في ملاحظات المراجعة، وجهّز لحساب المراجعة عنوانًا داخل التغطية أو طريقة لاختيار الحي يدويًا، حتى يصل إلى مسار الطلب والدفع كاملًا.
اشتراك لمقدمي الخدمة يُدفع ببطاقة مدى
منصة حجز يدفع فيها العميل ثمن خدمة تُقدَّم على أرض الواقع، ويدفع فيها مقدم الخدمة اشتراكًا شهريًا يفتح له مزايا داخل التطبيق. دفع العميل خدمة مادية تُدفع ببوابة أو Apple Pay، أما اشتراك المزايا فقد يُعد فتحًا لوظائف رقمية يخضع لقواعد الشراء داخل التطبيق. الحسم هنا يحتاج قراءة البندين 3.1.1 و3.1.3 على نموذج عملك تحديدًا؛ تفصل مقالة الشراء داخل التطبيق أم بوابة الدفع هذا القرار.
لا تبنِ طريقًا خاصًا يظهر للمراجع ويختفي عن المستخدمين، ولا تُخفِ ميزة عن المراجعة. الإرشاد 2.3.1 يمنع الميزات المخفية أو غير الموثقة، والتلاعب بالمراجعة يعرّض الحساب نفسه للخطر، لا الإصدار وحده.
تصلح أم ترد أم تستأنف؟ اختيار المسار الصحيح
ليس كل رفض يستحق إصدارًا جديدًا. تتيح Apple أكثر من مسار، واختيار الخطأ منها يضيع أيامًا:
- نعمهل الخلل في بيانات المتجر أو ملاحظات المراجعة فقط؟
- نعمعدّل البيانات في App Store Connect وأعد التقديم دون بناء جديد
- لاأصلح السبب في الكود، واختبر على الجهاز والإصدار نفسيهما، ثم ارفع إصدارًا جديدًا مع شرح ما تغير
- نعم
- لاهل السبب سوء فهم لمسار التطبيق أو نموذج عمله؟
- نعمرد في App Store Connect بتوضيح وخطوات ولقطات أو فيديو
- لا، تختلف معه في تفسير الإرشادقدّم استئنافًا رسميًا بحجة مكتوبة، وجهّز خطة بديلة إن لم يُقبل
- نعم
ثلاث أدوات أخرى تذكرها الإرشادات في قسم ما بعد التقديم، واستخدام كل منها في غير موضعه يضرك:
- الاستئناف: عبر نموذج الاستئناف لدى Apple حين تختلف مع نتيجة المراجعة. ليس مكانًا لإعادة شرح ما لم تقرأه أنت في البند.
- طلب المراجعة المستعجلة: لحالة توقيت حرجة فعلًا، كإصلاح عطل يمنع الدفع. الإرشادات تحذر من أن إساءة استخدامه قد تؤدي إلى رفض طلباتك لاحقًا.
- إصدارات إصلاح الأخطاء: إن كان تطبيقك منشورًا ورُفض تحديث إصلاح بسبب مخالفة قديمة لا علاقة لها بالإصلاح، تنص الإرشادات على ألا تؤخَّر إصلاحات الأخطاء بسبب مخالفات إرشادية، إلا ما يتعلق بمسائل قانونية أو بالسلامة. تطلب ذلك برسالة في App Store Connect مع التزام بمعالجة المخالفة في الإصدار التالي.
وتذكر الإرشادات أيضًا أن الرفض المتكرر للمخالفة نفسها يجعل مراجعة تطبيقك تستغرق وقتًا أطول. أي أن إعادة الرفع السريعة دون علاج حقيقي لا تختصر الطريق، بل تطيله.
كيف تكتب ردًا يقرؤه المراجع ويقتنع به
المراجع يقرأ ردك وهو يراجع تطبيقات أخرى. الرد الذي ينجح قصير ومحدد ويجعل التحقق سهلًا. هذه بنية تصلح لأغلب الحالات:
1) نشكر ملاحظتك على الإرشاد [الرقم]. 2) الإصدار [الرقم] يعالجها بهذا التغيير تحديدًا: [ما تغير في جملة]. 3) للتحقق: سجّل الدخول بحساب المراجعة المرفق، ثم [الخطوات بالترتيب حتى الميزة]. 4) أرفقنا فيديو قصيرًا للمسار ولقطة للشاشة المعنية. 5) إن كانت الميزة تعتمد على نطاق جغرافي أو جهاز خاص فهذا شرحه: [الشرح].
وحين يكون الرد خلافًا على التفسير، اكتب الحجة بلغة البند نفسه: ما الذي يبيعه تطبيقك، وأين يُستهلك، ولماذا تنطبق عليه فقرة بعينها. الرد العاطفي أو التهديد بسحب التطبيق لا يغير شيئًا. واكتب الرد باللغة التي وصلتك بها رسالة المراجعة، وغالبًا هي الإنجليزية.
أخطاء شائعة بعد الرفض تطيل الطريق
- إعادة الرفع دون قراءة البند كاملًا: تعالج جملة من الرسالة وتترك فقرة أخرى من البند نفسه، فيعود الرفض.
- إصلاح العرض لا السبب: تخفي الشاشة التي انهارت بدل أن تعرف لماذا انهارت. الانهيار يعود على جهاز مستخدم حقيقي، وتقييمات المتجر تحفظه.
- حساب مراجعة ميت: كلمة مرور غُيرت، أو حساب حُذف في تنظيف قاعدة البيانات، أو خادم تجريبي أُطفئ بعد المراجعة الأولى.
- بيانات خصوصية منسوخة من تطبيق آخر: المكتبات الخارجية للتحليلات والإعلانات والإشعارات تجمع بيانات لم يذكرها أحد. جرد ما يجمعه التطبيق فعلًا قبل تعبئة صفحة الخصوصية.
- الخلاف مع المراجع في كل رفض: الاستئناف أداة للخلاف الحقيقي. استخدامه لكل ملاحظة يستهلك الوقت ولا يبني ثقة.
- معالجة الرفض بعيدًا عن المنشأة: المطور يتواصل مع Apple من حسابه ولا يشارك الرسائل، فلا تعرف المنشأة سبب التأخير ولا ما وُعد به المراجع.
الوقاية: قائمة فحص قبل كل رفع إلى App Store
أفضل علاج للرفض أن تمر كل نسخة على قائمة ثابتة قبل التقديم. هذه القائمة مبنية على ما تطلبه Apple في قسم «قبل التقديم» من الإرشادات وعلى أسباب الرفض الأكثر تكرارًا؛ انسخها إلى ملف الإصدار:
- التطبيق مختبر على أجهزة حقيقية بأحدث إصدار iOS، وعلى أقدم إصدار تدعمه، دون انهيار في المسارات الأساسية.
- مبني بالأدوات التي تشترطها Apple حاليًا للرفع؛ منذ 28 أبريل 2026 يجب البناء بـ Xcode 26 أو أحدث، ومنذ 9 سبتمبر 2026 يجب أن يستهدف iOS 13 أو أحدث، بحسب صفحة المتطلبات القادمة.
- حساب مراجعة يعمل على بيئة الإنتاج، وبياناته مكتوبة في قسم معلومات المراجعة، مع رمز ثابت إن كان الدخول برمز جوال.
- الخوادم وبوابة الدفع والخدمات الخارجية تعمل طوال فترة المراجعة، والبيانات كافية لتظهر كل وظيفة.
- ملاحظات المراجعة تشرح كل ميزة غير واضحة، والنطاق الجغرافي، وأي جهاز أو رمز QR أو إعداد خاص يحتاجه المراجع.
- لا نصوص تجريبية ولا صفحات «قريبًا»، وكل رابط في التطبيق وصفحة المتجر يعمل، بما فيها رابط الدعم ورابط سياسة الخصوصية.
- بيانات الخصوصية في صفحة المتجر تطابق ما يجمعه التطبيق ومكتباته فعلًا، ونص كل إذن يشرح سببه بوضوح.
- إن كان التطبيق ينشئ حسابات: مسار حذف الحساب من داخل التطبيق يعمل حتى النهاية، ومقالة متطلبات حذف الحساب من داخل التطبيق تفصل ما يلزم.
- إن وُجد دخول بحساب خارجي: خيار الدخول البديل الذي يطلبه البند 4.8 موجود.
- طريقة الدفع لكل ما يُباع محسومة: محتوى وميزات رقمية أم سلع وخدمات تُستهلك خارج التطبيق.
- عناصر الشراء داخل التطبيق، إن وجدت، مكتملة وظاهرة للمراجع وتعمل.
- لقطات المتجر من الإصدار المقدم، تُظهر التطبيق أثناء الاستخدام لا شاشة الدخول وحدها، والوصف لا يعد بما ليس موجودًا.
- أسئلة التصنيف العمري في معلومات التطبيق مجاب عنها وفق نظام التصنيف المحدث.
- نسخة TestFlight نفسها جُربت داخليًا قبل التقديم، وسُجل رقم الإصدار ورقم البناء.
هذه القائمة تمنع أغلب الرفض الإجرائي، لكنها لا تحل رفضًا سببه فكرة التطبيق أو نموذج دفعه. تلك تُحسم في التحليل قبل البرمجة، كما تشرح صفحة تطوير تطبيقات iPhone وiPad التي تعرض قواعد App Store المؤثرة في التصميم والتكلفة. ولخطة الاختبار الأوسع قبل الإطلاق راجع مقالة الاختبار التجريبي عبر TestFlight وGoogle Play.
ما تطلبه من المطور أو شركة التطوير بعد الرفض
سواء عالج الرفض فريقك أو المطور السابق أو شركة جديدة، اطلب هذه المخرجات كتابيًا، لأن الرفض المتكرر غالبًا عرض لغياب ملكية واضحة لعملية النشر:
- نص رسالة الرفض كاملًا وكل الردود المتبادلة مع المراجع، محفوظة في ملف المشروع لا في بريد المطور.
- تشخيص مكتوب: الإرشاد، والسبب الجذري، وهل العلاج في الكود أم في بيانات المتجر، وأثره على نموذج العمل إن وُجد.
- ما الذي تغير في الإصدار الجديد تحديدًا، ونتيجة اختباره على الجهاز وإصدار النظام اللذين راجع عليهما المراجع.
- نص ملاحظات المراجعة وبيانات حساب المراجعة، ومكان حفظها للتحديثات القادمة.
- التأكد من أن التقديم يتم من حساب Apple Developer باسم منشأتك، وأن لك صلاحية الاطلاع على الرسائل.
- قائمة فحص الإصدار التي سيُستخدم مثلها قبل كل رفع قادم.
إن كان التطبيق منشورًا من حساب المطور لا المنشأة، فالرفض فرصة لتصحيح ذلك قبل أي شيء آخر؛ مقالة حساب المطور باسم المنشأة في المتجرين تشرح لماذا يهم ذلك وكيف تبدأ.
ما تجهزه قبل أن تطلب المساعدة في رفض قائم
إن قررت الاستعانة بجهة خارجية، فهذه المواد تختصر التشخيص من جولات أسئلة إلى جلسة واحدة:
- رسالة الرفض كاملة، وأي مرفقات من المراجع مثل سجل الانهيار أو اللقطات.
- تاريخ الرفض السابق إن تكرر: الإصدارات المرفوضة، وما عُدّل بين كل مرة وأخرى.
- وصف ما يبيعه التطبيق ومن يدفع مقابل ماذا، فهذا يحسم أسئلة الدفع مباشرة.
- طريقة الدخول الحالية (رمز جوال، نفاذ وطني، بريد، حسابات خارجية) وهل يوجد حساب مراجعة.
- صلاحية اطلاع على App Store Connect، والوصول إلى الكود أو ملفات البناء.
- موعد الإطلاق المستهدف وما يرتبط به، ليُرتب العلاج بين حل سريع الآن وإصلاح أعمق لاحقًا.
في خدمة النشر على App Store وGoogle Play نقرأ سبب الرفض ونعالجه في التطبيق أو في بيانات المتجر، ونعيد التقديم مع توضيح للمراجع، ونسلّم إرشادات الرد على المراجعة وقائمة فحص تُستخدم قبل كل رفع. وإن كان الرفض سببه انهيار أو خلل في وظيفة، فهو جزء من إصلاح أخطاء التطبيق بترتيب الأخطاء حسب أثرها ومعالجة السبب لا العرض. وتفصل مقالة رفض التطبيق أو تعليقه في Google Play الجانب الآخر إن كان تطبيقك على المتجرين.
الخلاصة: شخّص بالإرشاد، ثم اختر المسار
الرفض ليس حكمًا نهائيًا على تطبيقك، لكنه أيضًا ليس شيئًا يُحل بإعادة رفع سريعة. اقرأ رقم الإرشاد ونص البند كاملًا، وحدد هل المشكلة في الكود أم في بيانات المتجر أم في فهم المراجع، ثم اختر بين الإصلاح والرد والاستئناف. الأسباب الإجرائية (حساب المراجعة، والروابط، والخصوصية، واللقطات) تُمنع بقائمة فحص ثابتة، والأسباب الجوهرية (الدفع، والوظيفة المحدودة، والتطبيقات المكررة) تُحسم في التحليل قبل البرمجة.
إن كان تطبيقك مرفوضًا الآن أو عالقًا في المراجعة، أرسل رسالة الرفض وتفاصيل التطبيق عبر طلب تطوير تطبيق قائم، ونوضح السبب المرجح وطريقة المعالجة، وهل يكفي الرد أم يلزم إصدار جديد.
أسئلة شائعة
لا قبل أن تقرأ نص الإرشاد المذكور كاملًا وتحدد السبب. إن كان الخلل في بيانات المتجر أو ملاحظات المراجعة فعدّلها وأعد التقديم دون بناء جديد. وإن كان في الكود فأصلحه واختبره على الجهاز والإصدار اللذين راجع عليهما المراجع. الرفض المتكرر للمخالفة نفسها يطيل مراجعة تطبيقك.
جهّز حساب مراجعة برقم محدد يقبل رمزًا ثابتًا مفعّلًا لهذا الحساب وحده في الخادم، واكتب الرقم والرمز في قسم معلومات المراجعة. أبقِ الحساب فعالًا بعد الموافقة، لأنك ستحتاجه في كل تحديث قادم.
نعم. يمكنك أولًا الرد على المراجع في App Store Connect بتوضيح وأدلة إن كان الرفض سوء فهم، وإن اختلفت مع تفسير الإرشاد فتقدم استئنافًا رسميًا عبر نموذج Apple. جهّز حجتك بلغة البند نفسه، وضع خطة بديلة لأن نتيجة الاستئناف غير مضمونة.
هذا غالبًا الإرشاد 4.2 عن الوظيفة المحدودة. الحل ليس تعديل الوصف، بل إضافة تجربة تطبيق فعلية: تنقل أصلي، ودخول محفوظ، وإشعارات لها وظيفة، ومزايا تستفيد من الجهاز. وقد يعني ذلك مشروع تطوير لا إصلاحًا سريعًا، فقدّره قبل أن تعد بموعد إطلاق.
تنص إرشادات Apple على ألا تؤخَّر إصلاحات الأخطاء للتطبيقات المنشورة بسبب مخالفات إرشادية، إلا ما يتعلق بمسائل قانونية أو بالسلامة. اطلب ذلك برسالة في App Store Connect، والتزم بمعالجة المخالفة في الإصدار التالي.
خدمات وصفحات مرتبطة
اقرأ أيضًا
تطبيقك مرفوض أو عالق في مراجعة Apple؟
أرسل رسالة الرفض وتفاصيل تطبيقك، ونوضح السبب المرجح وطريقة المعالجة، وهل يكفي الرد على المراجع أم يلزم إصدار جديد.