رعايةتسجيل الدخولأرسِل
المدونة

كتبت Apple كيف يعمل App Review. هذا ما سأغيّره قبل الإرسال

بقلم Justinas Rolando، صانع MacPip

الجواب المختصر

في ملاحظة Hello Developer بتاريخ نوفمبر 2026، أشارت Apple إلى مقالات مساعدة جديدة عن App Review. وهي تكتب ما تعلّمه معظمنا من حالات الرفض: تهدف Apple إلى مراجعة 50% من الإرسالات في أقل من 24 س و90% في أقل من 48 س؛ ويجب أن تعمل بيانات الدخول التجريبية عند بدء المراجعة؛ وعليك الرد في App Store Connect بدل إعادة الإرسال للإجابة عن سؤال؛ والرفض الذي يبدأ بـ «Bug Fix Submissions:» يتيح لك إصدار الإصلاح ومعالجة المشكلة في المرة القادمة؛ ويجب أن تُظهر أكثر من نصف لقطاتك التطبيق قيد الاستخدام؛ ولكل إذن purpose string واضحة خاصة به. مقال واحد فقط يذكر Mac بالاسم، لكن كل قاعدة تنطبق على الإرسال إلى Mac App Store.

معظم ما أعرفه عن App Review تعلمته من رسائل الرفض. لذلك عندما كتبت Apple في Hello Developer بتاريخ نوفمبر 2026 عبارة «Browse new App Review help articles»، قرأتها كلها. وهي الآن في مكان واحد، App Review Help، وتقول بصراحة أشياء كثيرة كانت أقرب إلى الموروث الشعبي.

إليك ما فيها من أمور مهمة لتطبيق Mac، وما سأغيّره قبل إرسالي التالي.

أولًا، لمن هذا المقال

App Review لا ينظر إلا فيما يمر عبر App Store Connect: Mac App Store وTestFlight وIn-App Purchases وغيرها. وإذا كنت تبيع تطبيق Mac من موقعك الخاص باستخدام Developer ID، فلا أحد في Apple يراجعه. فهو يمر عبر التوثيق (notarization)، وهو فحص آلي. فإذا كنت توزّع مباشرة فقط، فتصفّح هذا المقال سريعًا واحتفظ به ليوم تضيف فيه نسخة لـ Mac App Store.

كم تستغرق المراجعة

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

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

حقل Notes هو حيث تُكسب المراجعات

مقال المراجعة الكاملة صريح: «الإرسالات غير المكتملة سيتم رفضها.» والتفاصيل المهمة:

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

عند الرفض

هذا هو الجزء الذي تمنيت لو كان مكتوبًا قبل سنوات.

أربع قواعد بالأرقام

مقالات الإرشادات قصيرة وملموسة.

السطر الوحيد عن Mac

مقال الأجهزة المتوافقة وحده يسمّي Mac. يقول إن تطبيقات iPhone وiPad المتوافقة يمكن أن تعمل دون تعديل على أجهزة Mac بمعالج Apple silicon، وإن التطبيقات التي تعتمد على اللمس الذي لا يمكن فعله بلوحة المفاتيح لا تناسب macOS. إذا كنت تصنع تطبيق iPad، فتحقق مما إذا كان يظهر في Mac App Store، وأوقف ذلك إذا كان لا يعمل جيدًا مع لوحة المفاتيح ولوحة التتبع. وتقول الصفحة نفسها إن حدود TestFlight هي: المختبرون الداخليون حتى 100، والخارجيون حتى 10,000، وإن أول نسخة تقدمها للمختبرين الخارجيين تذهب إلى App Review أيضًا.

What's New يُحتسب أيضًا

قاعدة أخرى من الإرشادات، لا من المقالات الجديدة. تقول Guideline 2.3.12 إن نص What's New يجب أن يصف الميزات والتغييرات الجديدة، ولا يكفي سطر عام إلا لإصلاحات الأخطاء البسيطة وتحسينات الأداء. أما «Bug fixes and improvements» في إصدار فيه ميزة جديدة فهو يستجلب سؤالًا.

لذلك أداة اليوم المجانية الجديدة هي منسّق ملاحظات الإصدار. الصق ملاحظات أولية أو أسطر git log --oneline. يرتّبها في «جديد» و«محسّن» و«مُصلَح»، ويحذف أسطر chore وci وmerge، وينبّه إلى أرقام التذاكر وأسماء الملفات، ويفحص حد 4,000 حرف، ويعطيك ثلاث نسخ: نصًا عاديًا لـ App Store Connect، وHTML لـ Sparkle appcast، وMarkdown لـ GitHub. تبقى ملاحظاتك في متصفحك. أداة فحص Sparkle appcast بجانبها، للخلاصة التي تدخل فيها.

قائمتي المختصرة

  1. يومان كاملان قبل يوم الإطلاق، وإصدار يدوي.
  2. حقل Notes يستطيع غريب أن يتبعه، مع حساب تجريبي يعمل.
  3. ردّ ولا تعد الإرسال عندما يسألون سؤالًا فقط.
  4. عُدّ لقطات الشاشة، واقرأ كل purpose string، وأبعد أسماء التطبيقات الأخرى عن الكلمات المفتاحية.
  5. What's New يقول ما الذي تغيّر.

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

المصادر

واصل القراءة

أرسِل تطبيقكأدوات مجانية للصُّنّاع