قائمة التحقق لإرسال التطبيق إلى App Store ‏(2026): من بناء Xcode 26 حتى Submit for Review

قائمة التحقق لإرسال التطبيق إلى App Store هي قائمة بالأمور التي يجب أن تكون جاهزة معاً قبل الإرسال: بناء يعمل، وصفحة متجر دقيقة، وإجابات خصوصية صادقة، وسياق كافٍ يمكّن المراجع من استخدام تطبيقك. البناء الناجح وحده لا يكفي. تتبع الأقسام الستة أدناه الترتيب الذي يطلبها به App Store Connect، ويبدأ كل قسم بإجابة مختصرة يمكنك العمل بها مباشرة.

ما الذي يحتاجه إرسال التطبيق إلى App Store قبل الضغط على Submit؟

يحتاج الإرسال إلى App Store إلى بناء تمت معالجته ومرفق بالإصدار، والبيانات الوصفية المطلوبة للإصدار، ولقطات الشاشة، وسياسة الخصوصية، وبيانات التواصل الخاصة بـ App Review، وبيانات اعتماد تجريبية تعمل إذا كان في التطبيق تسجيل دخول. وتضيف قائمة "Before You Submit" الخاصة بـ Apple في إرشادات مراجعة App Store بندين آخرين: "فعّل الخدمات الخلفية بحيث تكون تعمل ومتاحة أثناء المراجعة"، واشرح الميزات غير الواضحة في ملاحظات المراجعة.

ما إعدادات الحساب وسجل التطبيق التي يجب أن تكون جاهزة؟

تحتاج إلى عضوية Apple Developer نشطة، وسجل تطبيق يطابق معرّف الحزمة (bundle ID) فيه البناءَ الموقّع، وشخص في الفريق يحمل دور Account Holder أو Admin أو App Manager. هذه هي الأدوار التي تشترطها صفحة Submit an app لدى Apple للإرسال.

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

ما متطلبات البناء المطبّقة على عمليات الرفع إلى App Store في 2026؟

اعتباراً من أكتوبر 2026، تنص صفحة المتطلبات القادمة لدى Apple على أن "التطبيقات المرفوعة إلى App Store Connect يجب أن تُبنى باستخدام Xcode 26 أو أحدث مع SDK لـ iOS 26 أو iPadOS 26 أو tvOS 26 أو visionOS 26 أو watchOS 26" (منذ 28 أبريل 2026). كما تنص على أن تطبيقات iOS وiPadOS "يجب أن تستهدف iOS 13 أو أحدث" (منذ 9 سبتمبر 2026).

• زِد رقم البناء مع كل عملية رفع، وتأكد من أن رقم الإصدار يطابق الإصدار الذي تنوي إطلاقه.
• حدّث صورة Xcode في CI ‏(Codemagic وExpo EAS وGitHub Actions وغيرها) إضافة إلى جهازك الخاص.
• بعد المعالجة، أجب عن أي سؤال يتعلق بالامتثال لقيود التصدير (export compliance) وأرفق البناء المُعالَج بالإصدار.
• ثبّت بناء TestFlight على جهاز فعلي. اختبر شاشات التهيئة الأولى وتسجيل الدخول وحالات عدم الاتصال والمشتريات واستعادة المشتريات. فنجاح التشغيل على المحاكي لا يثبت أن البناء الموزَّع يعمل.
• اقرأ البريد الإلكتروني الذي يرسله App Store Connect بعد الرفع. فتحذيرات ITMS المتعلقة ببيانات الخصوصية أو إصدارات SDK تتحول إلى عوائق إذا تجاهلتها.

والإرشاد 2.1(a) صريح بشأن ما يحدث خلاف ذلك: "سنرفض حزم التطبيقات والملفات الثنائية غير المكتملة التي تتعطل أو تُظهر مشكلات تقنية واضحة." أزِل الشاشات المؤقتة وقوائم التصحيح والروابط المعطّلة قبل الأرشفة. ويستعرض مخطط اختبار بناء الإصدار للإرشاد 2.1 هذه الفحوصات بالتفصيل.

ما لقطات الشاشة والبيانات الوصفية التي يشترطها App Store Connect؟

اعتباراً من أكتوبر 2026، تشترط مواصفات لقطات الشاشة لدى Apple لقطة شاشة واحدة على الأقل لـ "iPhone المزوّد بـ Dynamic Island (شاشة متوسطة)"، مثل 1206 × 2622 أو 1179 × 2556 بالوضع العمودي. كما تحتاج التطبيقات التي تعمل على iPad إلى لقطة شاشة واحدة على الأقل لـ iPad مقاس 13 بوصة، مثل 2064 × 2752 أو 2048 × 2732.

"يمكنك رفع ما يصل إلى 10 لقطات شاشة لكل حجم جهاز بصيغ ‎.jpeg أو ‎.jpg أو ‎.png"، و"لا يجوز أن تتضمن الصور قنوات ألفا أو شفافية." وإذا كانت واجهتك متطابقة عبر الأحجام، فارفع أعلى دقة مطلوبة فقط وسيقوم App Store Connect بتصغيرها. وينص الإرشاد 2.3.3 على أن لقطات الشاشة "يجب أن تُظهر التطبيق أثناء الاستخدام، لا مجرد صورة العنوان أو صفحة تسجيل الدخول أو شاشة البداية."

• اكتب وصفاً يوضح لمن صُمّم التطبيق وما الذي يمكن للمستخدم فعله في جلسته الأولى.
• اجعل الاسم والعنوان الفرعي والكلمات المفتاحية ذات صلة. لا تكرر الكلمات المفتاحية ولا تستخدم أسماء المنافسين.
• تأكد من أن رابط الدعم ورابط سياسة الخصوصية يفتحان دون الحاجة إلى تسجيل دخول.
• أجب عن استبيان التصنيف العمري بناءً على ما يحتويه التطبيق فعلاً وما يمكنه فعله.
• اعرض البناء الحالي في لقطات الشاشة، بما في ذلك أي جدار دفع (paywall) سيواجهه المستخدم.

كيف تجعل إجابات الخصوصية مطابقة للتطبيق؟

لجعل إجابات الخصوصية مطابقة للتطبيق، أعدّ قائمة بكل SDK تضمّنه في التطبيق والبيانات التي يجمعها، ثم استخدم هذه القائمة لتعبئة App Privacy وكتابة سياسة الخصوصية وضبط سلوك التطبيق. وينص الإرشاد 2.3 على أن بياناتك الوصفية، "بما في ذلك معلومات الخصوصية"، يجب أن تعكس التطبيق بدقة.

ينص الإرشاد 5.1.1(i) على ما يلي: "يجب أن تتضمن جميع التطبيقات رابطاً لسياسة الخصوصية الخاصة بها في حقل البيانات الوصفية في App Store Connect وداخل التطبيق بطريقة يسهل الوصول إليها." ويضيف الإرشاد 5.1.1(v): "إذا كان تطبيقك يدعم إنشاء الحسابات، فيجب عليك أيضاً توفير حذف الحساب من داخل التطبيق." وعادةً ما تغيّر حزم SDK الخاصة بالتحليلات وتقارير الأعطال والإعلانات وتسجيل الدخول إجاباتك، لذا راجعها باستخدام تدقيق حزم SDK لملصقات الخصوصية. وتحقق أيضاً من أن تطبيقك وكل SDK مضمَّن فيه يحتوي على بيان خصوصية PrivacyInfo.xcprivacy يغطي أي واجهات برمجية تتطلب ذكر سبب الاستخدام (required-reason APIs) يستخدمها.

ما الذي يجب أن تتضمنه معلومات App Review؟

يجب أن تتضمن App Review Information جهة اتصال ستردّ فعلاً، وبيانات اعتماد تجريبية تعمل ولا تنتهي صلاحيتها، وملاحظات توجّه المراجع مباشرة إلى الميزات الأساسية. ويطلب الإرشاد 2.1(a) أن "تُضمّن معلومات الحساب التجريبي (وأن تشغّل خدمتك الخلفية!) إذا كان تطبيقك يتضمن تسجيل دخول"؛ أما استخدام وضع تجريبي مدمج بدلاً من حساب فيتطلب موافقة مسبقة من Apple.

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

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

لإرسال التطبيق للمراجعة، أرفق البناء بالإصدار، ثم انقر Add for Review، ثم انقر Submit for Review. فالنقر على Add for Review وحده لا يرسل شيئاً إلى Apple. ويتبع التسلسل أدناه صفحة Submit an app لدى Apple كما هي في أكتوبر 2026.

1. في Apps، اختر التطبيق، ثم انقر إصدار التطبيق في الشريط الجانبي.
2. انتقل إلى قسم Build وتأكد من إرفاق البناء الصحيح.
3. في قسم App Store Version Release، اختر الإطلاق اليدوي إذا أردت التحكم في يوم الإطلاق، ثم انقر Save.
4. انقر Add for Review واختر مسودة إرسال موجودة أو أنشئ مسودة جديدة. تتغير الحالة إلى Ready for Review.
5. انقر Submit for Review. وعند بدء المراجعة، تتغير الحالة إلى In Review.
6. احفظ نسخة من البيانات الوصفية والملاحظات المُرسلة، وراقب البريد الإلكتروني لجهة اتصال المراجعة تحسباً لأي أسئلة.

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

ما الذي حدث بشكل خاطئ لمطورين آخرين عند الإرسال؟

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

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

وتلقى مطوّر على منتدى JUCE رسالة "ITMS-91053: Missing API declaration" بعد عملية رفع، تفيد بأن عمليات الرفع الجديدة "يجب أن تتضمن مصفوفة NSPrivacyAccessedAPITypes في بيان الخصوصية الخاص بتطبيقك." وكانت الفئات المُشار إليها هي SystemBootTime وFileTimestamp، وأبلغ مستخدم آخر عن UserDefaults. وتمثّل الحل في ملف PrivacyInfo.xcprivacy يتضمن رموز الأسباب المعتمدة ويُضاف كمورد في Xcode. وقد أغفلت النسخة الأولى لدى أحد المستخدمين مفتاح النوع، ما تسبب في خطأ ITMS-91056 الخاص بالبيان غير الصالح إلى أن صحّحه.

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