Guideline 2.3.3: رفض Apple لصور الشاشة وكيف تعيدها

رفض «Guideline 2.3.3 - Performance - Accurate Metadata» معناه أن Apple ترى أن صور الشاشة لا تُظهر التطبيق وهو يؤدي عمله. القاعدة محددة بالأرقام: لكل نوع جهاز، يجب أن يُظهر أكثر من نصف الصور الشاشة الحقيقية للتطبيق أثناء الاستخدام. الرفض يخص صفحة المتجر، لا ملف التطبيق نفسه: تستبدل الصور وتعيد إرسال الـ build نفسه.

حدث لي هذا في 27 أكتوبر 2026 مع Vigie، تطبيقي لمتابعة ASO. كانت صوري تعرض بطاقات واجهة أعدت رسمها حول شخصية كرتونية، بلا هاتف. رفضتها Apple. يعرض هذا الدليل الرسالة التي وصلتني، وما تقصده Apple بعبارة «app in use»، وما يُقبل وما لا يُقبل، ثم قائمة التحقق التي أطبقها منذ ذلك الحين. القواعد المذكورة مأخوذة من صفحات Apple الرسمية، وقد راجعتها في 3 نوفمبر 2026.

رسالة Apple كما هي

تبدأ الرسالة بعنوان القاعدة، ثم تذكر مقاس الجهاز المعني. في حالة Vigie، كانت الجملة التي حملت الرفض هي هذه:

The 6.7-inch iPhone screenshots do not show the actual app in use.

رسائل رفض 2.3.3 أخرى تفصّل ما ينتظره المراجع. هذه الرسالة نُشرت في منتديات Apple في أكتوبر 2024 من مطوّر كانت خانات iPad عنده تعرض إطار iPhone. هذا هو المقطع الذي يسرد المتطلبات، كما هو:

Some or all of the provided screenshots do not sufficiently show
the app in use. Screenshots should highlight the app's core concept
to help users understand the app's functionality and value.

- Marketing or promotional materials that do not reflect the UI
  of the app are not appropriate for screenshots.
- The majority of the screenshots should highlight the app's main
  features and functionality.
- Confirm that the app looks and behaves identically in all
  languages and on all supported devices.
- Make sure that the screenshots show the app in use on the
  correct device, unless they are included to demonstrate that
  the app can be used on multiple Apple platforms. For example,
  iPhone screenshots should be taken on iPhone, not on iPad.

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

ما تقصده Apple بعبارة «app in use»

نص guideline 2.3.3 قصير: «Screenshots should show the app in use, and not merely the title art, login page, or splash screen.» يجب أن تُظهر الصور التطبيق أثناء الاستخدام، لا مجرد الشعار أو شاشة تسجيل الدخول أو شاشة الإقلاع. والنص نفسه يسمح بإضافة نصوص وصور فوقها.

صفحة مساعدة App Review عن 2.3.3 توضح طريقة الحكم. تقيّم Apple مجموعة الصور لكل نوع جهاز، ولا توافق إلا إذا أظهر أكثر من نصفها التطبيق أثناء الاستخدام. وكل لغة تُقيَّم وحدها. وتسرد الصفحة أيضًا ما يجب تجنبه:

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

باختصار، «أثناء الاستخدام» تعني: الواجهة الحقيقية للـ build الخاص بك، بمحتوى فعلي، وهي تؤدي الغرض الذي يُحمَّل التطبيق من أجله. عنوان قصير فوق شاشة حقيقية يبقى صورة تطبيق أثناء الاستخدام.

كم صورة يجب أن تُظهر التطبيق

تعطي Apple مثالين: مع ثلاث صور، يجب أن تُظهر اثنتان التطبيق. ومع أربع، ثلاث. والباقي يُستنتج من القاعدة نفسها: أكثر من النصف.

الصور المرسلة	الحد الأدنى أثناء الاستخدام	الصور التسويقية الممكنة
1	1	0
2	2	0
3	2	1
4	3	1
5	3	2
6	4	2
8	5	3
10	6	4

الحساب يتم لكل نوع جهاز ولكل لغة. صورة واحدة لكل جهاز تكفي إذا كانت تُظهر التطبيق أثناء الاستخدام. وفق مواصفات صور الشاشة، تشترط Apple صورة واحدة على الأقل لجهاز iPhone ذي Dynamic Island بالشاشة المتوسطة، وتقبل حتى 10 صور لكل مقاس. إذا كانت واجهتك متطابقة في كل المقاسات وكل اللغات، فأعلى دقة مطلوبة تكفي: App Store Connect يصغّرها للمقاسات الأصغر. الأبعاد الدقيقة موجودة في مقاسات صور الشاشة في App Store.

ما يُقبل وما لا يُقبل

الصورة	الحكم	العامل الحاسم
شاشة حقيقية للتطبيق مع عنوان قصير فوقها	تُقبل	النص المضاف مسموح به في 2.3.3
شاشة حقيقية داخل إطار iPhone	تُقبل	الواجهة الحقيقية، على الجهاز الصحيح
الشعار أو شاشة الإقلاع أو تسجيل الدخول وحدها	تُرفض	مذكورة حرفيًا في القاعدة
صورة تسويقية بلا واجهة	مقبولة إن كانت أقلية	فقط إذا كانت الأغلبية تُظهر التطبيق
بطاقات واجهة معاد رسمها، بدون التطبيق	تُرفض	رفضي في 27 أكتوبر 2026
شاشة مصممة غير موجودة في الـ build	تُرفض	واجهة لا تطابق الحقيقية
هاتف فارغ أو زخرفة بلا واجهة خلفها	تُرفض	مذكورة ضمن ما يجب تجنبه
صورة iPhone في خانات iPad	تُرفض	جهاز خاطئ، وفق رسالة الرفض في المنتدى
صورة تمتد على صورتين	تُقبل	مسموح، ما دام التطبيق ظاهرًا
شريط حالة من منصة أخرى	تُرفض، بموجب 2.3.10	تحيل Apple إلى guideline 2.3.10

لا تفرض Apple إطار هاتف. صورة للتطبيق بملء الشاشة تكفي. لكن للإطار ميزة: يجعل واضحًا من النظرة الأولى أن الصورة هي التطبيق.

حالتي: رفض Vigie في 27 أكتوبر 2026

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

كتب المراجع أن صور iPhone مقاس 6.7 بوصة لا تُظهر التطبيق أثناء الاستخدام. لم أعترض: كان محقًا. أعدت المجموعة كلها بقاعدة بسيطة:

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

لم يتطلب هذا الرفض أي build جديد. استبدلت الصور وأعدت إرسال الإصدار نفسه في المساء ذاته. ثم غيّرت الـ build لاحقًا لتصحيح عنوان داخل التطبيق، لا علاقة له بالصور. وكان Vigie 1.1 متاحًا للبيع في 29 أكتوبر بهذه المجموعة.

البطاقة المعاد رسمها، حتى لو كانت مطابقة، ليست التطبيق. المراجع يريد أن يرى الشاشة التي سيحملها المستخدم بين يديه.

التصحيح دون build جديد

1. اقرأ الرسالة كاملة. تذكر مقاس الجهاز المعني، وأحيانًا اللغة. يجب تغيير كل المجموعات المعنية، لا الأولى فقط.
2. أعد التقاط الصور من الـ build المرسل. على المحاكي أو على جهاز، بمحتوى حقيقي. أكثر من النصف أثناء الاستخدام، لكل جهاز ولكل لغة.
3. استبدل الصور في App Store Connect. وفق صفحة المساعدة عن إدارة المواد المرئية، يمكن ذلك عندما يكون التطبيق في إحدى هذه الحالات: Prepare for Submission أو Invalid Binary أو Rejected أو Metadata Rejected أو Developer Rejected.
4. أعد الإرسال حسب الحالة الظاهرة. في حالة Metadata Rejected، يقول جدول الحالات: اقرأ الرسالة، صحح البيانات الوصفية، ثم رد على رسالة App Review. إذا ظهرت للطلب حالة Unresolved Issues، فاتبع إجراء Apple: في Apps، اختر View App Review Issues & Messages، ثم Resolve، ثم Edit على العنصر المرفوض، ثم Add for Review، وأخيرًا Resubmit to App Review.
5. لا تلمس الصور بعد الإرسال. وفق جدول الحالات نفسه، في حالة Waiting for Review لا يمكنك رفع صور ولا تعديلها.

كل عنصر مرفوض لا يُعدَّل إلا مرة واحدة قبل إعادة الإرسال: راجع مجموعتك الجديدة قبل النقر. هذا هو الرد الذي كنت سأكتبه للمراجع، بالإنجليزية:

Hello App Review team,

Thank you for your feedback regarding Guideline 2.3.3.

We replaced the [6.9-inch iPhone] screenshots in all localizations.
Each screenshot now shows the actual app interface, captured from
the submitted build: [main screen], [key feature], [result screen].

The build is unchanged.

Best regards,
[Your name]

نبرة الرد الجيد وشكله مشروحان بالتفصيل في الرد على App Review.

قائمة التحقق قبل إرسال صورك

• أكثر من نصف صور كل نوع جهاز تُظهر الشاشة الحقيقية، بمحتوى فعلي.
• القاعدة نفسها مطبقة في كل لغة، لا في الإنجليزية فقط.
• لا توجد صورة تعرض الشعار أو شاشة الإقلاع أو تسجيل الدخول وحدها.
• الواجهة المعروضة موجودة في الـ build المرسل، بشكل مطابق.
• العناوين والزخرفة تترك الواجهة مقروءة.
• صور iPhone ملتقطة على iPhone، وصور iPad على iPad.
• لا أثر لأي منصة أخرى، حتى في شريط الحالة.
• إذا كان لتطبيقك وضع داكن، فلتعرضه صورة واحدة: صفحة مساعدة Apple تنصح بذلك.
• الملفات بصيغة JPEG أو PNG، بلا شفافية.

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

صور شاشة تُقبل من أول مرة

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

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

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

ماذا يعني «Guideline 2.3.3 - Performance - Accurate Metadata»؟

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

هل أحتاج إلى build جديد بعد رفض 2.3.3؟

لا. الرفض يخص صفحة App Store. تستبدل الصور في App Store Connect، ثم تعيد إرسال الإصدار نفسه مع الرد على رسالة App Review.

كم صورة يجب أن تُظهر التطبيق أثناء الاستخدام؟

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

هل يمكن وضع نص تسويقي على صور App Store؟

نعم. تسمح guideline 2.3.3 بالنصوص والصور المضافة فوق الصور. لكن يجب ألا تخفي الواجهة، ويجب أن تبقى أغلب الصور مُظهرة للتطبيق أثناء الاستخدام.

هل يلزم إطار iPhone حول الصور؟

لا، Apple لا تشترطه: صورة للتطبيق بملء الشاشة تُقبل. الإطار يساعد القارئ على فهم أن الصورة هي التطبيق. ويجب أن يكون إطار الجهاز الصحيح: لا تضع أبدًا إطار iPhone على صورة مخصصة لـ iPad.

هل يمكن تعديل الصور بينما ينتظر التطبيق المراجعة؟

لا. في حالة Waiting for Review، لا يسمح App Store Connect برفع صور ولا بتعديلها. لتغييرها، اسحب الطلب من المراجعة أو انتظر القرار.