ملاحظات المراجعة، والفيديو التوضيحي، والاتصال بـApple، والمراجعة العاجلة، وتوسع نطاق العمل، وتدفق التطبيقات المولّدة بالذكاء الاصطناعي: ما يساعد فعلاً على اجتياز App Review، وما ينتمي إلى الأساطير، وما قد يكلف أكثر بكثير من مجرد رفض.
تحتدم النقاشات هذه الأيام بين مطوري iOS، سواء على X أو في مجتمعات WhatsApp، ومنها مجتمع أديره. يدور الحديث عن مراجعات تطول بلا نهاية، وحسابات تُنهى، ويتبادل المطورون وصفات «للحصول على الموافقة في أقل من 48 ساعة»: ملاحظات مراجعة مفصلة، وفيديو توضيحي، ومكالمة مع Apple للدخول في قائمة انتظار منفصلة، ومنتج أولي بأقل قدر ممكن من الميزات لتجنب «كومة الأيام الأربعة عشر»…
تتضمن هذه النصائح أفكاراً موفقة جداً. لكنها تتضمن أيضاً ادعاءات يتعذر التحقق منها، وفكرة أو فكرتين قد تكلفان، عند تطبيقهما بصورة خاطئة، أكثر بكثير من مجرد رفض.
تستحق المهل الزمنية وإنهاء الحسابات فصلاً لكل منهما، لأنهما يلقيان الضوء على كل ما عداهما.
للتعريف بنفسي (مع أنك، وقد وصلت إلى هذا الموقع، «تعرف» على الأرجح من أنا): أنشر تطبيقات على App Store منذ عام 2008، سواء تطبيقاتي الخاصة أو تطبيقات العملاء. راجعت كل نصيحة وقارنتها بما تكتبه Apple صراحةً في صفحة App Review، وApp Review Guidelines، ومساعدة App Review. إليك ما يصمد أمام التدقيق وما لا يصمد.
أولاً، وضع مهلة الـ48 ساعة في سياقها
توحي الوصفات المتداولة بأن 48 ساعة إنجاز استثنائي. على الورق، هذه هي المدة المعتادة التي تعلنها Apple: يعمل فريق App Review على مدار الساعة في أنحاء العالم (في Cupertino وCork وأماكن أخرى)، ويهدف إلى معالجة 50% على الأقل من الطلبات خلال أقل من 24 ساعة، و90% خلال أقل من 48 ساعة.
على أرض الواقع، الصورة أكثر تعقيداً. هذه الأرقام متوسطات محسوبة على جميع الطلبات، وجزء كبير منها تحديثات لتطبيقات منشورة بالفعل، وغالباً ما تُراجع خلال ساعات قليلة. خلال الأسابيع الأخيرة، حصلت على موافقة لبعض التحديثات خلال 7 ساعات، وأخرى خلال 12 ساعة. أما التطبيق الجديد فقد ينتظر وقتاً أطول بكثير: في اللحظة التي أكتب فيها هذه السطور، تخضع بعض تطبيقاتي الجديدة للمراجعة منذ أكثر من عشرة أيام. إنها مدة طويلة، لكن هذا جزء من اللعبة.
شاركت Apple أرقاماً حديثة أيضاً. فعندما سألها MobileGamer.biz في 20 أكتوبر، قالت الشركة إنها عالجت في المتوسط 378,000 طلب أسبوعياً خلال الأسابيع الاثني عشر الماضية، بمتوسط مدة 1.5 يوم لجميع التطبيقات مجتمعة و14 ساعة للتحديثات البسيطة. وأوضحت أيضاً أن بعض التطبيقات الجديدة تستغرق وقتاً أطول عندما تتطلب فحصاً معمقاً. في ظل هذا الحجم من الطلبات، يُعد المتوسط لافتاً؛ وتتركز الفوارق في الطلبات الأولى للتطبيقات.
كان لدى المجتمع في السابق أداة لمتابعة هذه المهل. يتذكر المخضرمون موقع appreviewtimes.com، الذي أطلقه في أوائل العقد الثاني من الألفية صديقي Dave Verwer، صاحب iOS Dev Weekly. كانت الفكرة بسيطة: يغرد المطورون بمدة مراجعاتهم باستخدام الوسم #iosreviewtime (نعم، كان اسمه Twitter آنذاك)، ويحسب الموقع المتوسط. حين كانت المدة تُحسب بالأسابيع، كانت أداة لا غنى عنها لإدارة توقعات العملاء.
في عام 2019، أغلق Dave الموقع لأفضل الأسباب: أصبحت المراجعات سريعة إلى حد أن قياسها لم يعد مجدياً كثيراً، إذ كانت تستغرق نحو يوم واحد. ولم يُعد فتحه أبداً. وقد انضم Dave إلى Apple هذا الصيف مع Swift Package Index، وتولى Alex Ozun مسؤولية iOS Dev Weekly.
والنتيجة: في عام 2026، لم يعد هناك مقياس مجتمعي مرجعي، بل شهادات متفرقة في المنتديات وعلى الشبكات الاجتماعية. ومن علامات العصر أن الأداة التي أُغلقت لأن المراجعة أصبحت سريعة كانت ستجد مكانها اليوم من جديد.
تاريخ موجز للوقت
ليست هذه المرة الأولى التي تتغير فيها المهل. في بدايات App Store، كان من الممكن أن تستغرق المراجعة عدة أسابيع. انتظر تطبيقي الأول على الإطلاق 26 يوماً قبل الموافقة عليه، ليصدر في 14 يوليو 2008، بعد أربعة أيام من افتتاح App Store. ثم انخفضت المدة إلى أسبوع، وظل ذلك هو المعتاد لفترة طويلة. بعد ذلك سرّعت Apple العملية كثيراً، حتى أصبح يوم إلى ثلاثة أيام هو المألوف. منذ بداية عام 2026، عادت المهل للارتفاع بالنسبة للتطبيقات الجديدة، والسبب يستحق فصلاً بحد ذاته (تجده أدناه مباشرة).
لذا فإن استهداف 48 ساعة ليس سعياً إلى معاملة استثنائية، بل هو البقاء ضمن المسار المعتاد، مع العلم أن المسار المعتاد لإطلاق تطبيق يُحسب اليوم بالأيام. خطط على هذا الأساس.
يصبح السؤال الحقيقي: ما الذي يُخرج الطلب من هذا المسار؟ تقدم Apple مؤشراً قيّماً في صفحة App Review: أكثر من 40% من المشكلات غير المحلولة تندرج تحت المبدأ التوجيهي 2.1، App Completeness، أي اكتمال التطبيق: أعطال، ومحتوى مؤقت، ومعلومات ناقصة. ليست ذاتية المراجع هي ما يبطئ غالبية التطبيقات، بل الطلب غير المكتمل.
وكلاء البرمجة: تطبيقات أكثر وانتظار أطول
لماذا تعود المهل إلى الارتفاع؟ التفسير الأكثر ترجيحاً يمكن تلخيصه بكلمة واحدة: الوكلاء.
Claude Code وCodex وCursor والوكلاء المدمجون في Xcode: لم تكن كتابة تطبيق iOS في متناول هذا العدد من الناس من قبل. وفقاً لـSensor Tower، نقلاً عن The Information، استقبل App Store 235,800 تطبيق جديد في الربع الأول من عام 2026، بزيادة 84% عن العام السابق، وهي أعلى نسبة نمو مسجلة منذ أربع سنوات. وعلى امتداد النصف الأول كله، تقدر Sensor Tower عدد التطبيقات الجديدة بنحو 560,000 تطبيق، أي ضعف العام السابق، في حين لم ترتفع التنزيلات سوى 2%. وكتبت Apple نفسها في تقريرها عن مكافحة الاحتيال الصادر في مايو أن أدوات التطوير بالذكاء الاصطناعي تزيد عدد الطلبات المقدمة.
تحافظ Apple على هدفها المتمثل في معالجة 90% خلال 48 ساعة، وقد عدّلت طريقة عملها: مزيد من الأتمتة وإعطاء الأولوية للتحديثات. ومن جانب المطورين، تتسق الملاحظات مع هذا الخيار: لا تزال تحديثات التطبيقات القائمة تمر سريعاً، بينما تنتظر التطبيقات الجديدة مدة أطول.
الجانب المشرق: يا له من وقت رائع لتكون مطوراً
هذه أولاً أخبار ممتازة من نواحٍ كثيرة. لم يكن حاجز البرمجة منخفضاً إلى هذا الحد من قبل. بات بإمكان المصممين وخبراء المجالات والمطورين المستقلين الذين لم يكونوا ليتعلموا Swift أبداً أن يطلقوا تطبيقاً مفيداً اليوم. ويسلّم المطورون ذوو الخبرة في أسبوع ما كان يستغرق ثلاثة أشهر. أعمل أنا نفسي مع الوكلاء يومياً: يكتبون SwiftUI والاختبارات، وحتى مسودة أولى لملاحظات المراجعة.
لكن انتبه: القول إن الحاجز اختفى سيكون كذباً. يكتب الوكيل الشيفرة، لكنه لا يعرف بدلاً منك أي إطار عمل تختار، أو أي نمط سيصمد مع نمو التطبيق، أو كيف تعمل التزامنية في Swift وStoreKit والأذونات، أو لماذا تتعطل المراجعة. يضخّم الوكلاء ما تعرفه بالفعل. كلما عرفت المنصة أكثر، زادت سرعتك بفضلهم؛ وكلما قلّت معرفتك بها، أسرعت في تراكم مشكلات لا تعرف كيف تفهمها.
المكونات واحدة للجميع: Swift وSwiftUI وXcode وHuman Interface Guidelines، والآن وكيل أيضاً. ما يصنع تطبيقاً عظيماً هو طريقة جمعها معاً، بقصد وعناية: سبب للوجود يمكن صياغته في جملة واحدة، ومصدر واحد للحقيقة بالنسبة للبيانات، ومراجعة صادقة لإمكانية الوصول، واختبارات على أجهزة حقيقية. يستطيع الوكيل كتابة الشاشة، لكنه لن يخبرك إن كان التطبيق يستحق الوجود. أو أسوأ من ذلك، قد يتحول إلى أم فخورة تماماً: «يا لها من فكرة رائعة يا حبيبي!» ثم يساعدك على حرق مليار رمز لبناء تطبيق جمهوره المستهدف كله هو أنت وأمك وقطتك وطائرك الكناري وربما، ربما فقط، شريك حياتك. شرحت هذه العملية كلها بالتفصيل، من مبادئ التصميم الثمانية لدى Apple حتى النشر، في وصفة تطبيق iOS عظيم.
عند استخدامها جيداً، تساعد هذه الأدوات أيضاً في الامتثال. يمكن للوكيل مراجعة نصوص توضيح الغرض من طلب الأذونات، والتحقق من وجود خاصية حذف الحساب، ومقارنة تجربة الاستخدام بالإرشادات، وإعداد قائمة بالميزات غير الواضحة التي تحتاج إلى توثيق. يستطيع الوكيل التحقق مسبقاً من كل ما يصفه هذا المقال.
وبالمناسبة، لتسهيل المهمة عليك، أقدم لك مهارة تساعدك على اكتشاف الأخطاء قبل تقديم التطبيق: app-review-skill. ليست ضماناً للموافقة، لكنها على الأقل وسيلة وقائية. 😉
باختصار: يا له من وقت رائع لتكون مطوراً.
سراب المليونير بثلاثة طلبات
الوجه الآخر للعملة هو الخطاب المصاحب لهذه الموجة. نرى الوعد نفسه في كل مكان: ثلاثة طلبات، واشتراك (أو إعلانات في كل مكان)، وها أنت مليونير في ثلاثة أيام.
حرق للأحداث: هذا غير صحيح. والأرقام حاسمة. يُظهر تقرير RevenueCat بعنوان State of Subscription Apps 2026، الذي يشمل أكثر من 115,000 تطبيق وعائدات بقيمة 16 مليار دولار، ما يلي:
- بعد عام من إطلاقه، يحقق التطبيق الوسيط نحو 72 دولاراً شهرياً؛
- لا يصل إلى عائدات شهرية قدرها 1,000 دولار خلال أول عامين سوى 17.3% من التطبيقات، وتتجاوز 4.6% منها 10,000 دولار؛
- حتى أفضل 10% من التطبيقات أداءً لا تتجاوز سوى بالكاد 2,574 دولاراً شهرياً بعد عام: وهذا بعيد، بعيد جداً عن المليون؛
- لا تمثل التطبيقات التي أُطلقت في عام 2025 أو بعده سوى 3% من إيرادات الاشتراكات، بينما تستحوذ التطبيقات التي أُطلقت قبل عام 2020 على 69% منها.
ونحن نتحدث هنا عن تطبيقات جادة بما يكفي لدمج نظام اشتراكات.
يظن الجميع أن لديه الفكرة الكبيرة القادمة. آسف لإعادتك إلى أرض الواقع. إذا لم تكن فكرتك موجودة بعد على App Store، فهناك احتمالان فقط: إما أن أحداً جرّبها من قبل ولم تنجح، أو أن مئة شخص آخر يعملون على بنائها في هذه اللحظة نفسها. ومع الوكلاء، سرعان ما تتحول المئة إلى ألف.
هذا ليس تشاؤماً، بل ظاهرة موثقة جيداً: الاكتشافات المتزامنة. قدّم Alexander Graham Bell وElisha Gray طلبي براءة اختراع الهاتف في اليوم نفسه عام 1876. وتوصل Darwin وWallace كلٌّ على حدة إلى الانتقاء الطبيعي، حتى إنهما عرضا أعمالهما معاً عام 1858. واخترع Newton وLeibniz حساب التفاضل والتكامل بالتوازي. ليس في الأمر سحر: في أي حقبة، يتشارك الجميع الأدوات نفسها والمشكلات نفسها وإمكانية الوصول نفسها إلى المعلومات. وعندما يواجه عقلان المشكلة نفسها بالأدوات نفسها، يتوصلان بطبيعة الحال إلى الحل نفسه. وكما تقول العبارة المنسوبة غالباً إلى Victor Hugo، لا شيء أقوى من فكرة حان وقتها.
والنصيحة التي تترتب على ذلك: لا تُبقِ فكرتك سراً خوفاً من سرقتها. آخرون يعملون عليها بالفعل. وقد يلفت الأشخاص الذين تتحدث معهم انتباهك إلى تطبيقات منافسة لم تكن قد لاحظتها. لن يكون الفرق في الفكرة، بل في التنفيذ والتوزيع والوقت ولمستك الشخصية.
أعرف مطورين تدرّ عليهم تطبيقاتهم ما بين 80,000 دولار وأكثر من مليون دولار شهرياً. إنهم موجودون، وهم بارعون، وغالباً ما تقف وراءهم سنوات من التحسين المتكرر. ومن الواضح أنهم ليسوا الأغلبية.
هذا ليس سبباً لعدم البدء. بل سبب للبدء لأسباب وجيهة: حل مشكلة حقيقية، والتعلم، وبناء شيء يدوم. وللعناية بما لا يمكن أتمتته: الجودة.
الجانب الأقل إشراقاً
تصل تطبيقات متسرعة إلى المراجعة، وقائمة الانتظار مشتركة. إن إنشاء تطبيق في عطلة نهاية أسبوع لا يعني أنه جاهز: تصل طلبات كثيرة من دون أن تكون قد اختُبرت على جهاز، وبمحتوى مؤقت، ومن دون سياسة خصوصية أو ملاحظات مراجعة. وتطبيقات أخرى لا تهم أحداً سوى مطورها. لكن Apple تقول ذلك منذ مقدمة إرشاداتها: التطبيق الذي تريد عرضه على عائلتك وأصدقائك فقط لا مكان له على App Store؛ فقد صُمم Xcode والتوزيع عبر Ad Hoc لهذا الغرض. كل طلب من هذه الطلبات يشغل مراجعاً لن يكون متفرغاً لطلبك. وبإعطاء الأولوية لتحديثات التطبيقات القائمة، تحمي Apple المستخدمين الحاليين والمطورين الراسخين؛ والمقابل هو انتظار أطول للتطبيقات الجديدة.
الرسائل والتطبيقات المزعجة هي الهدف الأول. يحظر المبدأ التوجيهي 4.3 تقديم نسخ متعددة من التطبيق نفسه والتطبيقات في الفئات المشبعة من دون اختلاف حقيقي. باستخدام وكيل، يستغرق إنتاج خمس نسخ متطابقة فترة بعد الظهر؛ وهذا بالضبط ما تستبعده Apple. وتقول Apple إنها عززت الأتمتة واكتشاف إساءة الاستخدام، وأضافت وسائل حماية ضد الطلبات المتكررة التي تعاني المشكلات نفسها من دون حل. وكانت إرشاداتها تقول ذلك بالفعل: الرفض المتكرر للسبب نفسه يطيل المراجعة.
التطبيقات التي تولّد الشيفرة تحت المجهر. حجبت Apple تحديثات لعدة تطبيقات تعتمد على vibe coding أو أزالتها هذا العام، ومنها Replit وVibecode وAnything. السبب ليس vibe coding بحد ذاته، بل المبدأ التوجيهي 2.5.2: لا يجوز للتطبيق تنزيل شيفرة أو تنفيذها إذا كانت تغيّر وظائفه بعد المراجعة.
زيادة التطبيقات لا تعني زيادة المستخدمين. مع شبه استقرار التنزيلات، يتنافس كل تطبيق جديد على الاهتمام نفسه. انخفض الحاجز التقني، لكن حاجز الجودة ارتفع.
ما الذي يتغير بالنسبة إليك
- تظل المسؤولية مسؤوليتك. تذكّر الإرشادات بأن كل ما في تطبيقك، بما في ذلك حزم SDK التابعة لجهات خارجية، يقع تحت مسؤوليتك. القول إن «الوكيل هو من كتب ذلك» ليس حجة مقبولة.
- تصبح جودة الطلب ميزة تنافسية. في قائمة انتظار مزدحمة، يبرز التطبيق المكتمل المصحوب بملاحظات واضحة أكثر من ذي قبل.
- تطبيق واحد، لا خمس نسخ. استخدم عمليات الشراء داخل التطبيق أو الإعدادات لتقديم التنويعات، بدلاً من الإكثار من معرّفات الحزم.
- لا تعِد التقديم أبداً من دون تصحيح. جولة مراجعة غير ضرورية تكلفك أياماً، وقد تضعك ضمن أنماط السلوك التي تراقبها Apple.
- اترك هامشاً زمنياً. بالنسبة إلى تطبيق جديد، احسب أسبوعاً، إضافة إلى جولة مراجعة محتملة. وإذا تمت الموافقة خلال 48 ساعة، فهذا أفضل.
النصائح التي تصمد أمام التدقيق
الجودة مهمة، وهي منصوص عليها في القواعد
«سيُعامل التطبيق المتقن بصورة أفضل»: هذا صحيح، لكن ليس بسبب مزاج المراجع. ينص القسم 4 من الإرشادات بوضوح على أن Apple تتوقع واجهات بسيطة ومتقنة وسهلة الاستخدام. ويرفض المبدأ التوجيهي 4.2 (Minimum Functionality) التطبيقات التي لا تعدو كونها موقع ويب أُعيد تغليفه، أو مجموعة روابط، أو محتوى بلا قيمة مستدامة.
«ابنِ تطبيقاً أصلياً باستخدام SwiftUI»: نصيحة جيدة وليست قاعدة
أنا مطور تطبيقات iOS أصلية: أمارس هذا النهج وأدافع عنه وأروّج له وأدرّسه. بالنسبة إليّ، هو النهج المرجعي لبناء تطبيق يحترم أساليب استخدام المنصة ويستفيد استفادة كاملة مما يستطيع iPhone وiPad فعله. مع SwiftUI، تستفيد من Dynamic Type وsafe areas وsheets والتنقل على مستوى النظام والتكيف مع iPhone وiPad، مع وصول مباشر إلى widgets وLive Activities وApp Intents وإمكانات أخرى كثيرة توفرها أطر عمل Apple. يُحدث هذا التكامل فرقاً حقيقياً في الاستخدام اليومي ويقلل تلقائياً العيوب الصغيرة التي يلاحظها المراجع.
لكن أياً من الإرشادات لا يفرض استخدام SwiftUI. التطبيق المتقن المبني باستخدام Expo أو Flutter أو UIKit يجتاز المراجعة من دون مشكلة. ما يُؤخذ عليك هو النتيجة: عرض ويب متنكر في هيئة تطبيق، أو واجهة تتعطل على iPad (يشجع المبدأ التوجيهي 2.4.1 دعم iPad كلما أمكن)، أو لوحة مفاتيح تحجب حقلاً. يزيد التطوير الأصلي فرصك في التميز، لكنه لا يضمنه.
ملاحظة: Martin، لا تضرب، لا تضرب، لا تضرررر... صفعة
سياسة الخصوصية والدعم والأذونات
غالباً ما نهوّن هنا من حقيقة الأمر. هذه ليست ممارسات مستحسنة، بل التزامات:
- سياسة خصوصية متاحة في App Store Connect وفي التطبيق (5.1.1(i)). يجب أن تصف البيانات التي تُجمع واستخداماتها، وأن تُلزم الجهات الخارجية بمستوى حماية مماثل، وأن تشرح الاحتفاظ بالبيانات وحذفها وسحب الموافقة.
- رابط للدعم يتضمن بيانات اتصال محدّثة، على أن تعمل جميع الروابط (2.1 و5.1).
- نصوص واضحة لتوضيح الغرض لكل إذن حساس، ويُفضل أن تتضمن مثالاً عملياً على الاستخدام.
- تقليل البيانات (5.1.1(iii)): فضّل أدوات الاختيار التابعة للنظام، مثل منتقي الصور، على الوصول الكامل إلى مكتبة الصور.
- حذف الحساب من داخل التطبيق متى أمكن إنشاء حساب فيه (5.1.1(v)).
صيغة «HTML ثابت» التي يُنصح بها كثيراً ليست إلزامية. المهم أن تكون الصفحة متاحة ومحدّثة ومتسقة مع ما يفعله التطبيق.
التطبيقات الاجتماعية: أربعة متطلبات محددة
الإبلاغ والحظر والاتصال والإشراف: هذا هو بالضبط مضمون المبدأ التوجيهي 1.2 (User-Generated Content)، الذي يتطلب:
- وسيلة لتصفية المحتوى غير المقبول قبل نشره؛
- آلية للإبلاغ واستجابة سريعة للبلاغات؛
- إمكانية حظر المستخدمين المسيئين؛
- بيانات اتصال منشورة للتواصل معك.
منذ تحديث 16 أكتوبر 2026، يذكر المبدأ التوجيهي صراحةً تطبيقات الإنشاء بالذكاء الاصطناعي، وتوضح Apple أنه يجب العمل بنشاط على منع الصور الحميمة غير التوافقية وإزالتها، بما فيها الصور المولّدة بالذكاء الاصطناعي. وقد يُعتبر المطور الذي لا يضع وسائل حماية أو لا يصحح الوضع بعد إخطاره مخالفاً لمدونة السلوك.
تتكرر الإشارة في النقاشات إلى واجهة OpenAI المجانية للإشراف على المحتوى. إنها خيار تقني صالح، مع توضيح مهم: يفرض المبدأ التوجيهي 5.1.2(i) التصريح بوضوح عند مشاركة البيانات الشخصية مع جهات خارجية، بما في ذلك ذكاء اصطناعي تابع لجهة خارجية، والحصول على إذن صريح. إن إرسال صور مستخدميك إلى نموذج خارجي من دون إخبارهم يعني استبدال سبب رفض بآخر.
يجب أن تعمل عمليات الشراء داخل التطبيق
الأمر بديهي، لكن كثيرين يخفقون فيه: يطلب المبدأ التوجيهي 2.1(b) أن تكون عمليات الشراء داخل التطبيق مكتملة ومرئية وقابلة للاستخدام من قبل المراجع. إذا لم يكن أحد المنتجات التي أعددتها متاحاً في النسخة المقدمة، فاشرح السبب في الملاحظات. وأضف زر «استعادة المشتريات».
ملاحظات المراجعة: الأداة الأكثر استخفافاً بقيمتها
هذه أكثر النصائح فائدة على الإطلاق، وApple تذهب إلى أبعد من ذلك.
ما تطلبه Apple في قائمة التحقق «Before You Submit»:
- وصول كامل إلى التطبيق: حساب تجريبي نشط أو وضع تجريبي كامل، إضافة إلى الأجهزة أو الموارد اللازمة (بيانات تسجيل الدخول، ورمز QR نموذجي…)؛
- خادم خلفي متصل بالإنترنت طوال المراجعة؛
- شرح مفصل للميزات غير الواضحة وعمليات الشراء داخل التطبيق في الملاحظات، مع إرفاق الوثائق عند الحاجة.
نعم، هناك قدر من الأتمتة، وهذا طبيعي مع هذا الحجم من الطلبات. لكن Apple تكتب ذلك صراحةً في مقدمة إرشاداتها: يفحص الخبراء كل تطبيق. في تسع حالات من أصل عشر، إن لم يكن أكثر، هناك إنسان يتولى الأمر ويضغط على الزر الأخضر الصغير (أو الأحمر).
إذن ملاحظاتك موجهة إلى شخص يتعرف على تطبيقك في غضون دقائق. اكتبها من أجله.
والمبدأ التوجيهي 2.3.1(a) لا يحتمل اللبس: يجب وصف كل ميزة جديدة بدقة في الملاحظات، وتُرفض الأوصاف العامة.
انتبه إلى تفصيل: لا يُقبل الوضع التجريبي بدلاً من الحساب التجريبي إلا بموافقة مسبقة من Apple، وفقط إذا كانت التزامات قانونية أو أمنية تمنعك من توفير حساب.
هيكل فعّال
لا داعي لنسخ رواية كتبها شخص آخر. إليك الهيكل الذي أستخدمه:
مرحباً،
[اسم التطبيق] هو [جملة واحدة: ما يفعله التطبيق، ولمن، والمشكلة التي يحلها].
نموذج العمل: [مجاني / اشتراك / شراء لمرة واحدة]، عبر In-App Purchase.
الوصول:
- الحساب التجريبي: [اسم المستخدم] / [كلمة المرور]
(أو: لا يلزم حساب)
مسار الاستخدام الأساسي:
1. …
2. …
3. …
عمليات الشراء داخل التطبيق:
- أين تظهر شاشة الدفع، وكيفية الاختبار في sandbox.
- «استعادة المشتريات»: [الموقع].
الميزات غير الواضحة:
- [الميزة]: كيفية الوصول إليها، وما تفعله.
البيانات والأذونات:
- الأذونات المطلوبة، ومتى تُطلب، ولماذا.
- البيانات التي تُشارك مع جهات خارجية (بما فيها الذكاء الاصطناعي) والموافقة.
الخدمات الخارجية:
- [الخدمة]: الغرض منها (البيانات، والمصادقة، والدفع، والذكاء الاصطناعي، والإعلانات…).
الاختلافات الإقليمية:
- [لا توجد / ما هي].
اللوائح ومحتوى الجهات الخارجية:
- [لا ينطبق / المستندات المرفقة].
الحساب والأمان:
- حذف الحساب: [المسار].
- الإبلاغ / الحظر: [المسار] (في حالة محتوى المستخدمين).أما الأسلوب، فقاعدته الذهبية هي استخدام جمل قصيرة يفهمها من يكتشف التطبيق للمرة الأولى. لكنني أتحفظ قليلاً على نصيحة «لا تستخدم الذكاء الاصطناعي» التي نقرؤها أحياناً: إن تكليف وكيل يعرف شيفرتك بكتابة مسودة أولى يوفر الوقت فعلاً. المهم هو المراجعة والتبسيط قبل التقديم.
مثال حقيقي: الإفصاح عما يُتحكم فيه عن بُعد
إليك ملاحظة تركتها على أحد تطبيقاتي (بعد إخفاء هويته). هذه حالة شائعة: حزمة SDK الإعلانية مدمجة، لكن لا يمكن تفعيل الإعلانات قبل النشر، لأن AdMob تشترط نشر التطبيق في متجر للتحقق من «جاهزية التطبيق». لذلك تُعطّل الإعلانات باستخدام علامة ميزة وقت المراجعة.
الإفصاح عن الإعلانات - الإصدار الأول 1.0
يتضمن هذا التطبيق حزمة Google Mobile Ads (AdMob) SDK ودمج Google UMP للموافقة. إعلانات الإنتاج معطلة حالياً من خلال علامة ميزة تُدار عن بُعد. هذا هو إعداد الإطلاق العام، وليس شرطاً يستهدف App Review. نفصح صراحةً عن دمج الإعلانات؛ ولم تُعطّل لإخفائها عن المراجعين.
السبب هو أن هذا الإصدار الأول غير متاح بعد للعامة على App Store. تتطلب مراجعة جاهزية التطبيق لدى AdMob تطبيقاً منشوراً وقابلاً للتنزيل ومرتبطاً بمتجر مدعوم، كما تتطلب الموافقة قبل عرض الإعلانات بالكامل. لذلك لا نستطيع إكمال عملية التفعيل قبل النشر. بعد الإصدار، نخطط لربط صفحة App Store وإكمال عملية الجاهزية لدى AdMob وتفعيل إعلانات الإنتاج باستخدام علامة الميزة.
لا ينبغي تفسير غياب الإعلانات أثناء المراجعة على أن المنتج خالٍ من الإعلانات. سيظل عرض الإعلانات خاضعاً للموافقة وأذونات التتبع المعمول بها.
شرح Google: https://support.google.com/admob/answer/10564477?hl=enلماذا تنجح هذه الملاحظة:
- تذكر ما تتضمنه النسخة التنفيذية: حزمة AdMob SDK ووحدة الموافقة UMP.
- تفصح عن علامة الميزة وتوضح أنها لا تستهدف المراجعة. وهذا عكس الميزة الخاملة تماماً بالمعنى المقصود في المبدأ التوجيهي 2.5.19.
- تشرح السبب، مع مصدر خارجي يمكن التحقق منه.
- تعلن ما سيتغير بعد النشر، حتى لا يكون تفعيل الإعلانات مفاجأة.
- تذكّر بالموافقة: ستظل الإعلانات المخصصة خاضعة لأذونات التتبع.
لا شيء مخفي، ولا شيء يحتاج إلى تأويل: يعرف المراجع بالضبط ما يوافق عليه.
الفيديو التوضيحي: ليس إلزامياً، لكن الطلب عليه يتزايد
نقرأ أحياناً أن الطلبات الأولى التي لا تتضمن ملاحظات أو فيديو تُرفض تلقائياً. لا يوجد في وثائق Apple ما يقول ذلك. ما تكتبه Apple هو أنه يجب الاستعداد لتوفير فيديو توضيحي أو الأجهزة اللازمة عندما تعتمد بعض الميزات على بيئة يصعب إعادة إنشائها أو على أجهزة محددة.
عملياً، يساعد تسجيل قصير للشاشة مع شرح، يُرفق في App Review Information، كثيراً عندما يكون التطبيق غير مألوف: جهاز متصل، أو تحديد الموقع الجغرافي، أو ميزة اجتماعية تتطلب عدة حسابات. أما تطبيق ملاحظات لا يتطلب حساباً، فلا حاجة إليه.
يظل الهدف سليماً: جعل المراجعة واضحة وسهلة. المراجع الذي يفهم تطبيقك في ثلاث دقائق لا سبب لديه ليطرح عليك أسئلة.
عندما تطلب منك Apple «مزيداً من المعلومات»
بالنسبة إلى التطبيقات الجديدة، تتكرر رسالة أكثر فأكثر: طلب موحد للمعلومات مرتبط بالمبدأ التوجيهي 2.1. إليك الرسالة التي تلقيتها مؤخراً بشأن أحد تطبيقاتي:
نحتاج إلى معلومات إضافية لفهم التطبيق بصورة أفضل وإكمال المراجعة.
يرجى الرد في App Store Connect بجميع المعلومات التالية، وإضافتها أيضاً
إلى حقل Notes في قسم App Review Information في App Store
Connect، للرجوع إليها في الطلبات المستقبلية:
1. تسجيل للشاشة ملتقط على جهاز فعلي يعمل بأحدث إصدار من نظام التشغيل،
ويوضح وظائف التطبيق. يجب أن يبدأ التسجيل بتشغيل التطبيق ويعرض مسار
الاستخدام المعتاد. إذا كان التطبيق يتضمن أياً مما يلي، فأدرجه في التسجيل:
- مسارات تسجيل الحساب وتسجيل الدخول وحذف الحساب.
- أي محتوى ينشئه المستخدمون، بما في ذلك آليات الإبلاغ عن المحتوى
والحظر المطلوبة.
- الوصول إلى المحتوى أو الميزات المدفوعة داخل التطبيق.
2. وصف لغرض التطبيق والجمهور المستهدف، بما في ذلك المشكلة التي يحلها
والقيمة التي يقدمها
3. تعليمات إعداد ميزات التطبيق الرئيسية والوصول إليها، بما في ذلك
أي بيانات تسجيل دخول أو ملفات نموذجية مطلوبة
4. قائمة بالخدمات أو الأدوات أو المنصات الخارجية التي يستخدمها التطبيق لتقديم
وظائفه الأساسية (مثل مزودي البيانات أو خدمات المصادقة أو معالجي
الدفع أو خدمات الذكاء الاصطناعي)
5. وصف أي اختلافات إقليمية في ميزات التطبيق أو محتواه، أو تأكيد
أن التطبيق يعمل بصورة متسقة في جميع المناطق
6. إذا كان التطبيق يعمل في قطاع شديد التنظيم أو يتضمن مواد محمية
تابعة لجهة خارجية، فيرجى تقديم أي وثائق أو بيانات اعتماد ذات صلة
تثبت تصريحك بتقديم هذه الخدمات أو المواد المحميةوتذكّر الرسالة أيضاً بالمزالق المعتادة: أخطاء على جهاز فعلي، والحساب التجريبي، ولقطات الشاشة التي تُظهر التطبيق أثناء الاستخدام، وتهيئة عمليات الشراء داخل التطبيق معه، والتوزيع المخصص للشركات.
وإليك ردي بعد إخفاء الهوية:
1. [تسجيل الشاشة مرفق، وقد التُقط على جهاز فعلي.]
2. [التطبيق] هو تطبيق من فئة [الفئة] يتيح [ما يفعله التطبيق]. وهو مستوحى من
[مرجع معروف]، لكنه يضيف [ميزاته المميزة الخاصة]. صُمم التطبيق من أجل
[الجمهور المستهدف]، و[المشكلة التي يحلها / القيمة التي يقدمها].
3. لا يوجد حساب لإنشائه ولا يلزم تسجيل الدخول. يمكن للمستخدمين فتح
التطبيق والبدء باستخدامه مباشرة. يتكون المسار الرئيسي من [التفاعل الرئيسي]. ويمكن للمستخدمين
أيضاً [الميزات الثانوية] مباشرة من التطبيق. يتضمن التطبيق إعلانات اختيارية
بمكافأة لفتح [ميزة إضافية اختيارية].
4. يعمل التطبيق أساساً على الجهاز. وتُنفذ [المعالجة الأساسية] محلياً،
لذلك لا توجد واجهة API خارجية مرتبطة بالوظائف الأساسية. تُستخدم خدمة AdMob
من Google لعرض الإعلانات، بما في ذلك الإعلانات الاختيارية بمكافأة.
5. يعمل التطبيق بالطريقة نفسها في كل منطقة يتوفر فيها. والاختلاف الرئيسي
هو اللغة: للتطبيق اسم مترجم ومحتوى مكيف مع كل لغة. وتظل الميزات والآليات
الأساسية متسقة في جميع المناطق المدعومة.
6. لا ينطبق. [التطبيق] تطبيق أصلي ولا يعمل في قطاع
خاضع للتنظيم.ثلاثة دروس مستفادة:
- الفيديو ليس مطلوباً تلقائياً، لكنه مطلوب صراحةً هنا، على أن يُصوّر على جهاز فعلي بأحدث إصدار من iOS، بدءاً من تشغيل التطبيق. لذا من الأفضل تجهيزه قبل التقديم الأول.
- تطلب Apple إضافة هذه الإجابات إلى حقل Notes للطلبات اللاحقة. بعبارة أخرى: لو كانت موجودة فيه منذ البداية، لربما أمكن تجنب جولة المراسلة هذه.
- الأسئلة الستة قائمة تحقق ممتازة. الغرض، والجمهور، والوصول، والخدمات الخارجية، والاختلافات الإقليمية، والتنظيم: أدرجتها في نموذج الملاحظات أعلاه.
ما يجب تجنبه (ولماذا يكون أسوأ من الرفض أحياناً)
شاشات «متوفر قريباً»
المحتوى المؤقت، والأزرار المعطلة، والروابط الفارغة: هذا هو جوهر المبدأ التوجيهي 2.1، والسبب الأول للمشكلات وفقاً لـApple. احذف الميزة من النسخة المقدمة بدلاً من عرضها غير مكتملة.
تعديل شاشة الدفع بعد المراجعة
نرى أحياناً تصنيف «جعل شاشة دفع تُدار عن بُعد غير ممتثلة بعد المراجعة» ضمن أنماط التصميم المخادعة البسيطة. الأمر أخطر من ذلك بكثير.
يحظر المبدأ التوجيهي 2.5.19، الذي أُضيف في 16 أكتوبر 2026 ليستهدف صراحةً الاستدراج ثم التبديل، الميزات المخفية أو الخاملة أو غير الموثقة، وينص على إزالة التطبيق وإنهاء حساب المطور. ومقدمة الإرشادات أكثر صراحةً: تؤدي محاولة خداع عملية المراجعة إلى إزالة التطبيقات والاستبعاد من Apple Developer Program. هذا ليس رهاناً على تساهل مراجع، بل خطر يهدد نشاطك كله.
لا يوجد ما يحظر إعداد شاشة الدفع عن بُعد. أما تحويلها إلى شيء لم يره المراجع، فمحظور.
طلبات التقييم
يفرض المبدأ التوجيهي 5.6.1 استخدام واجهة API التي توفرها Apple لطلب التقييم، ويحظر رسائل الطلب المخصصة. ويحظر المبدأ التوجيهي 3.2.2(x) اشتراط تقييم التطبيق للوصول إلى ميزة.
طلب التقييم أثناء التهيئة الأولية ليس محظوراً صراحةً، لكنه عبثي: لم يرَ المستخدم شيئاً بعد، والنظام يحدّ على أي حال من تكرار عرض هذا الطلب. انتظر لحظة رضا حقيقية.
الدليل الاجتماعي الزائف والوعود التي يتعذر التحقق منها
ادعاء مختلق بوجود «مليون مستخدم»، وتقييمات مزيفة، وعبارة «يحل 100% من مشكلاتك»: يحظر المبدأ التوجيهي 5.6.3 أي تلاعب بالتقييمات أو التصنيفات أو البحث، ويحظر 2.3.7 الادعاءات التي يتعذر التحقق منها في البيانات الوصفية. وبالنسبة إلى التطبيقات الصحية، يتطلب 1.4.1 توثيق المنهجية وراء أي وعد بالدقة.
نسخ تطبيق آخر
الأمر بديهي، وApple تذهب إلى أبعد من ذلك. يرفض المبدأ التوجيهي 4.1 النسخ المقلدة، ويُعد انتحال تطبيق آخر انتهاكاً لمدونة السلوك. ويغلق 4.3 الباب أمام الفئات المشبعة (المصابيح اليدوية، والخلفيات، وتطبيقات المواعدة، والمؤقتات البسيطة…) ما لم تقدم تجربة مختلفة حقاً. يوجد بالفعل مليون صندوق لإصدار أصوات الريح، ومليون مصباح يدوي، ومليون تطبيق مواعدة: وتذكر Apple بالاسم تطبيقات أصوات الريح والتجشؤ ضمن التطبيقات التي لا تضيف شيئاً إلى App Store.
عروض الاحتفاظ بالمشتركين: استخدم الأدوات الرسمية
يدور حديث كثير عن «التخلي عن المعاملة» و«عروض المغادرة» (تقديم عرض لشخص متردد أو يريد الإلغاء). هذه الممارسات ليست محظورة بحد ذاتها، ويوفر StoreKit آليات رسمية لها: العروض الترويجية، وعروض استعادة المشتركين (win-back offers)، وشاشة النظام لإدارة الاشتراكات.
من المعقول تأجيلها إلى تحديث لاحق: نطاق أقل وأسئلة أقل. لكن القاعدة الفعلية في مكان آخر. يتطلب المبدأ التوجيهي 3.1.2(c) وصف ما يحصل عليه المستخدم مقابل السعر بوضوح، ويحظر 5.6 دفعه إلى مشتريات غير مرغوبة. العرض الواضح الموصوف في الملاحظات لا يدعو إلى القلق. أما العرض الذي يحجب حقيقة السعر، فيدعو إليه.
إنهاء الحسابات: افهم الأمر حتى لا تكون معنياً به
يكلفك الرفض بضعة أيام. أما إنهاء الحساب فيكلفك جميع تطبيقاتك. يشغل هذا الموضوع الشبكات الاجتماعية كثيراً في الأسابيع الأخيرة، ويستحق تناوله بهدوء.
لماذا تشدد Apple الإجراءات
في 16 أكتوبر 2026، شددت Apple إرشاداتها في نقطتين: الصور الحميمة غير التوافقية، بما فيها الصور المولّدة بالذكاء الاصطناعي، التي يجب على التطبيقات منعها وإزالتها (1.2)؛ والاستدراج ثم التبديل، أي التطبيقات التي تبدو غير ضارة أثناء المراجعة وتفعّل ميزات ضارة بعد الموافقة (2.5.19). وفي الإعلان نفسه، تقول Apple إنها منعت أكثر من 150,000 تطبيق يعاني مشكلات أمنية من الوصول إلى المستخدمين العام الماضي، وأنهت أكثر من 193,000 حساب مطور بسبب الاحتيال وإساءة الاستخدام.
توضح هذه الأرقام جوهر الأمر: الاحتيال على App Store واسع النطاق ومنظم. تكاثرت تطبيقات «التعرية»، وطالبت سلطات مثل مدينة San Francisco بإزالتها، ويزيد تدفق الطلبات المولّدة بالذكاء الاصطناعي الضغط أكثر. وصمود ثقة المستخدمين في App Store رغم كل ذلك يعود إلى حد كبير إلى هذا العمل.
على هذا النطاق، يحدث أيضاً أن يقع مطورون حسنو النية في الشباك. ولهذه الحالات تحديداً يوجد الاستئناف لدى App Review Board.
ما يرويه المطورون
تستند الإشعارات التي جرت مشاركتها إلى القسم 3.2(f) من Developer Program License Agreement، وتشير إلى «نمط من السلوك التلاعبي أو المضلل»، تتبعه قائمة بسلوكيات محتملة: بيانات وصفية غير دقيقة، ومحتوى مضلل، وتقييمات مزيفة، وردود مضللة للدعم أو في App Store Connect، وعمليات شراء قائمة على الاستدراج ثم التبديل…
نشر Phillip Shoemaker، الذي سبق أن أدار App Review، تحليله في أواخر أكتوبر. ويرى أن سجل الرفض أصبح له الآن وزن كبير: عدد الطلبات، وتغييرات الاسم، والرفض المتكرر بسبب محتوى غير مقبول، ولا سيما في تطبيقات الصور التوليدية. ويقر أيضاً بصعوبة المهمة من جانب Apple: من الصعب جداً مراجعة التطبيقات التوليدية، ويمكن التراجع عن أي تصحيح على جانب الخادم في أي وقت، كما تربط Apple الحسابات بعضها ببعض، مما يمنحها رؤية لا تتوفر دائماً للمطور. ومقترحاته بنّاءة: رفض أكثر دقة في تحديد ما يجب تغييره، وذكر عناصر ملموسة في الإشعارات حتى يكون الاستئناف مجدياً.
من يظن نفسه أذكى من الجميع قد يقع في الهاوية
لا حاجة إلى ذكر أسماء: القصص المتداولة متشابهة. وعند قراءتها عن كثب، نجد غالباً التصرفات نفسها. قلما تنطلق من نية سيئة، لكنها من منظور Cupertino تشبه كثيراً ما تحاول Apple رصده:
- إعادة التقديم مراراً مع تغيير تفصيل في كل مرة، «لنرى إن كان سيمر».
- تغيير اسم التطبيق أو مفهومه أو فئته أثناء العملية، وأحياناً عدة مرات.
- التصحيح شكلياً: إزالة خيار من قائمة مع بقاء الميزة متاحة بطريقة أخرى.
- الإبقاء على مفتاح تحكم على جانب الخادم لم يره المراجع قط.
- حشو الكلمات المفتاحية، أو الاقتباس أكثر من اللازم من اسم تطبيق منافس.
- تعدد الحسابات أو إعارة حسابك لتجاوز الرفض.
- تحريف الحقيقة في الردود على App Review.
قد تبدو كل واحدة من هذه الخطوات بمفردها بريئة. لكن جمعها يرسم نمطاً. وعلى مستوى مئات آلاف الطلبات أسبوعياً، تقرأ Apple هذا النمط، لا نواياك.
العبرة بسيطة: محاولة التفوق بالتحايل على App Review تشبه المراهنة ضد صاحب الكازينو. وصاحب الكازينو لديه السجل كاملاً.
يظل App Review Board موجوداً لتصحيح الخطأ، وينجح مطورون حسنو النية في استئنافهم. لكن أفضل استئناف هو الذي لا تحتاج إلى تقديمه أصلاً.
ما الذي يتغير بالنسبة إليك
لن أدّعي أنني خبير قانوني: عند إنهاء الحساب، السبيل الوحيد هو الاستئناف لدى App Review Board، وفي الحالات المبلغ عنها يمنح الإشعار مهلة 30 يوماً للقيام بذلك. إذا حدث لك هذا، فاستعن بمن يرافقك. في المقابل، تقلل بعض الممارسات الخطر بوضوح:
- سجل الرفض مهم. يترك كل طلب أثراً. لا تعِد التقديم أبداً «لمجرد التجربة»: اطرح سؤالاً محدداً في App Store Connect قبل التصحيح.
- لا تغيّر هوية التطبيق أثناء العملية. الاسم والمفهوم والفئة: تبدو التغييرات المتكررة شبيهة بما تحاول Apple رصده. إذا طلب منك App Review ذلك، فاطلب تأكيده كتابةً في App Store Connect، حتى بعد المكالمة، ولخّص كتابةً ما قيل عبر الهاتف.
- عندما يتكرر الرفض بلا نهاية، توقف عن إعادة التقديم. اطلب كتابةً القائمة الكاملة للنقاط التي تعوق الموافقة، ثم الجأ إلى الاستئناف لدى App Review Board بدلاً من تكرار المحاولات.
- وثّق كل ما يمكن ضبطه عن بُعد. علامات الميزات، وشاشة الدفع، ونماذج الذكاء الاصطناعي: اذكرها في الملاحظات وأظهر ما يمكن أن يتغير.
- في التطبيقات التوليدية، عالج المشكلة من المصدر. إزالة خيار من قائمة لا تكفي إذا كان النموذج لا يزال ينتج المحتوى بمجرد طلبه. يجب أن تكون التصفية فعلية، على مستوى النموذج والمخرجات.
- أجب بدقة في App Store Connect. ترد «الردود المضللة» صراحةً ضمن قائمة الأسباب.
- احتفظ بأرشيف لكل طلب. النسخة المقدمة، والملاحظات، ولقطات الشاشة، والمراسلات مع App Review: هذا هو ملفك الوحيد في حالة الاستئناف.
- انتبه لمن تتعامل معهم. الحسابات المشتركة، والشهادات المُعارة، والشركاء ذوو الممارسات المشبوهة: تربط Apple الحسابات بعضها ببعض.
ولهذا أيضاً لا أتبع الفكرة التي تُطرح أحياناً، ومفادها أن «Apple تريد منا اختبار الحدود». في عام 2026، يُحتسب كل طلب في سجلك. من الأفضل استهداف الوضوح بدلاً من اختبار الحدود.
تسريع المراجعة: ما هو متاح فعلاً
هنا تنتشر الأفكار المغلوطة أكثر من أي موضع آخر.
المراجعة العاجلة (expedite)
المراجعة العاجلة متاحة في ظروف استثنائية: خلل حرج أو إطلاق مرتبط بفعالية ترتبط أنت بها مباشرة. إليك بعض التفاصيل التي كثيراً ما تُنسى:
- لا يمكن تسريع إلا طلب أُرسل بالفعل للمراجعة؛
- في حالة الخلل الحرج، اذكر في الملاحظات خطوات إعادة إنتاجه على الإصدار الحالي؛
- في حالة الفعالية، اذكر اسمها وتاريخها وعلاقة التطبيق بها؛
- تعالج Apple الطلب بحسب التوفر وحجم الطلبات، من دون ضمان؛
- والأهم أن Apple تحتفظ بحق رفض طلباتك المستقبلية في حالة إساءة الاستخدام.
لذا فإن القول «لا حاجة إلى ذكر سبب» مضلل: النموذج بسيط، لكن يجب وضع المبرر في الملاحظات. أما «لحظة الانتشار الواسع» أو «التسويق» فلا يردان ضمن المعايير. لن أهدر هذه الفرصة من أجلهما.
الاتصال بـApple: ليس مساراً سريعاً
غالباً ما يُقدّم الاتصال على أنه طريقة غير معروفة للانتقال إلى قائمة انتظار منفصلة. هذا ليس ما تصفه Apple.
يمكن طلب مكالمة مع ممثل عن Apple من نافذة الرد على App Review، بعد أول رد منهم، مع تحديد المنطقة الزمنية واللغة. تُجرى هذه المكالمات عادة خلال ثلاثة إلى خمسة أيام عمل. وهي أداة ممتازة لإزالة سوء فهم بشأن الرفض، لكنها ليست بأي حال طريقاً مختصراً إلى 48 ساعة. تذكّر أن المراجعة التالية قد يجريها شخص آخر: احرص دائماً على تأكيد النتائج كتابةً في App Store Connect.
مواعيد App Review: السر الحقيقي
ما نادراً ما يُذكر، وأنصح به جميع عملائي قبل تقديم أول طلب حساس، هو مواعيد App Review عبر Meet with Apple. ثلاثون دقيقة عبر الفيديو مع خبير في App Review، يومي الثلاثاء والخميس بحسب التوفر، لطرح أسئلة محددة حول كيفية انطباق أحد الإرشادات على تطبيقك.
هناك قيدان يجب معرفتهما: الموعد للحصول على المعلومات، ولا يحل محل المراجعة أو يسرّعها أو يضمنها، ولا تمنح Apple موافقة مسبقة على أي ميزة. لكن الوصول إلى مرحلة التقديم وأنت تعرف مسبقاً كيف تنظر Apple إلى حالتك هو أفضل استثمار ممكن.
الخروج من دوامة الرفض المتتالي
الكابوس معروف: رفض، ثم تصحيح، ثم رفض جديد لسبب آخر. للخروج منه، لا بد من استخدام القنوات المناسبة:
- الرد في App Store Connect بسؤال محدد عن الميزة أو المبدأ التوجيهي أو الخطوة التي تحتاج إلى توضيح. يجيبك اختصاصي يعرف تطبيقك. ومن حقك أن تسأل «هل توجد نقاط أخرى تعوق الموافقة؟»، حتى لو لم يستطع أحد ضمان الإجابة.
- Bug Fix Submission: بالنسبة إلى تطبيق منشور بالفعل، لا يُحجب تحديث لإصلاح الأخطاء بسبب مشكلات أخرى متعلقة بالإرشادات، إلا إذا تعلّق الأمر بمسألة قانونية أو أمنية. تصلح الباقي في الطلب التالي.
- الاستئناف لدى App Review Board إذا رأيت أن التطبيق لم يُفهم بصورة صحيحة: مرة واحدة لكل طلب مرفوض، مع حجج محددة.
أما فيما يخص أسلوب الحديث، فيذكّر المبدأ التوجيهي 5.6 بوجوب معاملة الجميع باحترام، بما في ذلك في المراسلات مع Apple. الشكوى لا تفيد؛ أما الاستناد إلى الإرشادات في حججك فيفيد.
توسع نطاق العمل: أفضل نصيحة مع توضيح
«قدّم منتجاً أولياً قابلاً للاستخدام» نصيحة ممتازة، وتؤكدها Apple بطريقتها: قد يتطلب التطبيق المعقد أو الذي يثير أسئلة جديدة فحصاً أعمق، كما أن الرفض المتكرر بسبب المبدأ التوجيهي نفسه يطيل المراجعة.
في المقابل، لا يوجد توثيق في أي مكان لوصف «كومتين» مع تصعيد إلى اختصاصي أقدم وانتظار 14 يوماً. ما توثقه Apple هو وجود مجالات خاضعة للتنظيم تتطلب مستندات إضافية ووقتاً أطول:
- يجب أن تقدم تطبيقات المصارف والتمويل والصحة والمقامرة والعملات المشفرة والنقل الجوي من قِبل الكيان القانوني الذي يوفر الخدمة (5.1.1(ix))؛
- يجب احتساب وقت إضافي لألعاب المقامرة (5.3)؛
- يجب أن تقدم التطبيقات الطبية أو المرتبطة بمحتوى مرخّص التصاريح المقابلة.
وتوضيح أخير: المنتج الأولي القابل للاستخدام ليس تطبيقاً هزيلاً. ينطبق الحد الأدنى للمبدأ التوجيهي 4.2 منذ الإصدار الأول. قلّل عدد الميزات، لا مستوى إتقانها.
خلاصة: صحيح، ويحتاج إلى توضيح، وخاطئ
| ما يُتداول | الحكم | ما تقوله Apple |
|---|---|---|
| يمكن الحصول على الموافقة خلال 48 ساعة | يحتاج إلى توضيح | هدف رسمي يتحقق لمعظم التحديثات؛ وقد ينتظر التطبيق الجديد أكثر من أسبوع |
| تساعد ملاحظات المراجعة المفصلة | صحيح | مطلوبة للميزات غير الواضحة (2.3.1(a)) |
| يلزم حساب تجريبي | صحيح | إلزامي إذا كان التطبيق يتطلب تسجيل الدخول (2.1(a)) |
| يجب أن تشرف التطبيقات الاجتماعية على المحتوى | صحيح | التصفية والإبلاغ والحظر ونشر بيانات الاتصال (1.2) |
| يجب البناء باستخدام SwiftUI | يحتاج إلى توضيح | لا يوجد إلزام؛ النتيجة وحدها هي المهمة (4.2) |
| الفيديو التوضيحي شبه إلزامي | يحتاج إلى توضيح | لا يوجد رفض تلقائي موثق، لكنه يُطلب بصورة متزايدة للتطبيقات الجديدة |
| تأجيل العروض العدوانية إلى وقت لاحق | يحتاج إلى توضيح | تصرف حكيم، لكن القاعدة الحقيقية هي الوضوح (3.1.2، 5.6) |
| يمر المنتج الأولي بسرعة أكبر | يحتاج إلى توضيح | نعم، من دون النزول عن الحد الأدنى في 4.2 |
| لا حاجة إلى تبرير طلب المراجعة العاجلة | خاطئ | يوضع التبرير في الملاحظات؛ وتترتب عواقب على إساءة الاستخدام |
| ينقل الاتصال الطلب إلى قائمة منفصلة | خاطئ | بعد رد من App Review، خلال 3 إلى 5 أيام عمل |
| الرفض تلقائي من دون ملاحظات أو فيديو | غير موثق | لا يوجد مصدر رسمي |
| كومتان، إحداهما تنتظر 14 يوماً | غير موثق | تتحدث Apple فقط عن فحص أكثر تعمقاً |
| تريد Apple منا اختبار الحدود | خاطئ | خداع المراجعة يؤدي إلى الاستبعاد من البرنامج |
قائمة التحقق الخاصة بي قبل التقديم
الاكتمال (2.1)
معلومات المراجعة
البيانات الوصفية (2.3)
الاستراتيجية
السر الحقيقي: كن مملاً وصادقاً
نقرأ أحياناً أن Apple تريد منا اختبار الحدود. لا أتفق مع ذلك. الإرشادات وثيقة حية، وتقر Apple بأن التقدير الشخصي يؤدي دوراً فيها. لكن المقدمة واضحة: المبدأ هو توفير تجربة آمنة للمستخدمين، وأي محاولة لخداع المراجعة لها ثمن باهظ جداً.
أما الباقي، فهناك قاعدة يتفق عليها الجميع: كن واضحاً وصادقاً، واشرح ما تفعله وأظهره. يمر الطلب المكتمل والواضح والخالي من المفاجآت ضمن المهل المعتادة. بالنسبة إلى التحديثات، غالباً ما تكون المدة أقل من 48 ساعة. أما التطبيق الجديد في عام 2026، فمن الأفضل أن تحسب أسبوعاً وتترك لنفسك فرصة المفاجأة السارة.
مع الوكلاء الذين يتيحون للجميع تقديم تطبيق في عطلة نهاية أسبوع، تعود App Review إلى ما كانت عليه في البداية: مرشح. وهذا أمر جيد. فهذا المرشح هو ما يسمح للمستخدم بتثبيت تطبيق لا يعرفه من دون ريبة، وهذه الثقة هي ما يمنح App Store قيمته بالنسبة إلينا نحن المطورين. تعالج فرق App Review مئات آلاف الطلبات أسبوعياً؛ وتسهيل عملها يعني أيضاً تسهيل حياتنا.
فلنكن على الجانب الصحيح من هذا المرشح.
أنشئ التطبيقات وأنشرها منذ ولادة App Store، لنفسي ولشركات ناشئة ولدور لها متاجر في Champs-Élysées. إذا كنت تستعد لتقديم طلب أول حساس، أو تطبيق اجتماعي، أو نموذج اشتراك، أو تطبيق في مجال خاضع للتنظيم، فهذا هو نوع الدعم الذي أقدمه مع BNC Consulting. اكتب إليّ.
وللحديث عن ذلك بين المطورين، انضم إلى مجتمع ⌘+F: نتبادل قصص الرفض أيضاً في اللقاءات، حول فنجان قهوة أو على العشاء.
وأخيراً، عناق كبير إلى Raph’ وAnders وErica وEwelina وجميع أصدقائي الآخرين في فريق App Review، الذين يؤدون عملاً صعباً على نحو خاص. وعناق آخر إلى Martin وMac وSiQing وفرق WWDR، الذين يؤدون غالباً دور الوسيط، وإلى كل من أعرفهم حول العالم ولا أستطيع ذكر أسمائهم هنا.
شكراً لوجودكم لحماية المستخدمين. هذا أيضاً من الجوانب المشرقة لـApp Store.
— Clément
المصادر الرسمية (تم الاطلاع عليها في 1 نوفمبر 2026)
- App Review — Apple Developer
- App Review Guidelines (تحديث 16 أكتوبر 2026)
- طلب مراجعة عاجلة
- الاتصال بـApp Review وطلب مكالمة
- طلب موعد مع App Review
البيانات والصحافة
- MobileGamer.biz — مهل المراجعة وتدفق التطبيقات المولّدة بالذكاء الاصطناعي (20 أكتوبر 2026، مع رد Apple المدعوم بالأرقام)
- 9to5Mac — ارتفاع التطبيقات الجديدة بنسبة 84%
- TweakTown — 560,000 تطبيق جديد في النصف الأول من 2026
- RevenueCat — State of Subscription Apps 2026
- iPhoneSoft — AppReviewTimes يغلق أبوابه (مارس 2019)
- Apple — تعزيز App Review Guidelines ضد الصور الحميمة غير التوافقية وتطبيقات الاستدراج ثم التبديل (16 أكتوبر 2026)
- Phillip Shoemaker — وافقت Apple على التصحيح، ثم وصفت المطور بالكاذب (30 أكتوبر 2026)
- 9to5Mac — قواعد جديدة ضد التعرية والاستدراج ثم التبديل
كالمعتاد، كُتب المقال الأصلي يدوياً بالفرنسية. أُنجزت الترجمة العربية والرسوم التوضيحية باستخدام أدوات OpenAI.