قد تقضي أشهرًا في تطوير تطبيقك، وتجرب جميع الشاشات، وتتأكد من أن تسجيل الدخول يعمل وأن قاعدة البيانات سليمة، ثم ترفعه إلى App Store Connect وأنت تتوقع أن تكون الخطوة التالية هي النشر.

وبعد فترة تصلك الرسالة التي لا يريد أي مطور رؤيتها:

Your app has been rejected.

رفض Apple لا يعني بالضرورة أن التطبيق سيئ أو أن هناك خطأ برمجيًا كبيرًا.

أحيانًا يكون السبب:

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

لكن تجارب المطورين وحدها لا تكفي، لأن بعض النصائح المتداولة قد تكون مبسطة أكثر من اللازم أو غير دقيقة.

لذلك سنتعرف في هذا الدرس على أهم أسباب رفض التطبيقات، مع التفريق بين الخبرة العملية والقواعد التي تنص عليها Apple رسميًا.

قبل كل شيء: App Review ليست مجرد اختبار للأخطاء

عندما تراجع Apple التطبيق، فهي لا تسأل فقط:

هل التطبيق يفتح؟

المراجعة تشمل جوانب أوسع، مثل:

وتؤكد Apple في Guideline 2.1 أن التطبيق المقدم للمراجعة يجب أن يكون نسخة نهائية، وأن تكون الروابط وبيانات Metadata مكتملة، وأن تُزال النصوص المؤقتة والمحتويات غير المكتملة، وأن يُختبر التطبيق على جهاز حقيقي قبل التقديم.

١. التطبيق غير مكتمل أو يحتوي مشاكل واضحة

هذا أحد أسهل أسباب الرفض في تجنبه.

لا ترسل تطبيقًا يحتوي على:

Coming soon
TODO
Lorem ipsum
Test page

أو:

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

لا تختبر Debug فقط

قبل الإرسال اختبر:

فعبارة:

يعمل على جهازي.

لا تعني أن النسخة التي أرسلتها إلى Apple ستعمل بنفس الصورة.

٢. المراجع لا يستطيع تسجيل الدخول

قد يكون تطبيقك ممتازًا، لكن مراجع Apple لا يستطيع الوصول إلى أي شيء بعد شاشة تسجيل الدخول.

إذا كان التطبيق يتطلب حسابًا، يجب أن توفر في App Review Information بيانات Demo Account صالحة للمراجعة.

Apple تطلب اسم المستخدم وكلمة المرور عندما يحتاج التطبيق إلى تسجيل الدخول، كما يمكن استخدام Review Notes لإضافة حسابات إضافية أو تعليمات خاصة. ويجب ألا ينتهي حساب المراجعة أثناء عملية App Review.

لا ترسل مثلًا:

Username: test@test.com
Password: password

إذا كان الحساب:

اسأل نفسك

لو أعطيت هاتفك الآن لشخص لم ير التطبيق من قبل، هل يستطيع:

  1. تسجيل الدخول؟
  2. الوصول إلى أهم Feature؟
  3. تجربة المشتريات؟
  4. فهم ما يجب عليه فعله؟

إذا احتاج إلى الاتصال بك لمعرفة السر، فغالبًا سيواجه مراجع Apple المشكلة نفسها.

٣. سوء فهم قاعدة Sign in with Apple

من النصائح الشائعة بين بعض المطورين:

إذا كان التطبيق يحتوي على تسجيل دخول، فيجب إضافة Sign in with Apple.

لكن هذه العبارة ليست دقيقة بهذه الصورة المطلقة.

Apple تركز في Guideline 4.8 على التطبيقات التي تستخدم خدمة تسجيل دخول اجتماعية أو تابعة لطرف ثالث لإنشاء الحساب الأساسي أو المصادقة عليه، مثل:

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

هل هذا يعني أن كل تطبيق فيه Login يحتاج Sign in with Apple؟

لا.

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

لذلك:

يوجد Login

لا تعني تلقائيًا:

يجب إضافة Sign in with Apple

أما إذا كنت تستخدم Google أو Facebook أو خدمة اجتماعية مشابهة للحساب الأساسي، فراجع Guideline 4.8 بعناية.

٤. إجبار المستخدم على إنشاء حساب دون حاجة

يضيف كثير من التطبيقات شاشة Login تلقائيًا لأن هذا أصبح نمطًا مألوفًا:

Create account
→ Verify email
→ Login
→ Use app

لكن هل يحتاج التطبيق فعلًا إلى معرفة هوية المستخدم؟

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

مثلًا، إذا صنعت:

فاسأل:

لماذا أحتاج إلى بريد المستخدم أصلًا؟

كل معلومة تطلبها يجب أن يكون لها سبب.

٥. يوجد إنشاء حساب… لكن لا يوجد حذف للحساب

إذا كان التطبيق يسمح بإنشاء حساب، فإن Apple تطلب أن يستطيع المستخدم بدء عملية حذف حسابه من داخل التطبيق.

ومن الأفضل أن يكون الخيار سهل العثور عليه، مثل:

الإعدادات
→ الحساب
→ حذف الحساب

لا تخفِه تحت:

Settings
→ Advanced
→ Privacy
→ More
→ Other
→ Account
→ Delete

Apple تؤكد أن جعل عملية الحذف صعبة دون مبرر قد يؤدي إلى عدم اجتياز المراجعة.

٦. هل يكفي تحويل بيانات الحساب إلى null؟

تنتشر بين بعض المطورين نصيحة تقول:

لا تحذف حساب المستخدم فعليًا لأن ذلك قد يسبب مشاكل في العلاقات داخل قاعدة البيانات؛ اجعل البيانات الشخصية null بدلًا من ذلك.

فكرة الحذر من الحذف المباشر مفهومة هندسيًا، خصوصًا في قواعد البيانات التي تحتوي على علاقات كثيرة.

لكنها لا تصلح كقاعدة عامة لتحقيق متطلب Apple.

Apple توضح أن مجرد تعطيل الحساب مؤقتًا لا يكفي، وأن المستخدم يتوقع حذف الحساب والبيانات المرتبطة به، مع إمكانية الاحتفاظ فقط بما توجد حاجة قانونية أو تنظيمية مشروعة للاحتفاظ به.

إذن الحل ليس:

لا نحذف شيئًا ونستبدل الحقول بـ null.

بل:

صمّم عملية حذف الحساب بحيث لا تفسد قاعدة البيانات.

وقد تشمل العملية:

وإذا كان المستخدم يعتمد على Sign in with Apple، تشير Apple إلى ضرورة التعامل مع إلغاء Tokens عند حذف الحساب.

الفكرة المهمة

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

٧. طلب الكاميرا أو الميكروفون دون تفسير واضح

أحد الأشياء التي قد تسبب مشاكل في المراجعة هو طلب صلاحيات حساسة دون توضيح سبب استخدامها.

مثل:

This app needs microphone access.

السؤال الطبيعي للمستخدم هو:

لماذا؟

Apple تطلب أن تشرح Purpose Strings بصورة واضحة وكاملة كيفية استخدام البيانات، كما تشدد على الحصول على موافقة صريحة عند التسجيل باستخدام الكاميرا أو الميكروفون.

مثال ضعيف:

نحتاج إلى الميكروفون لاستخدام التطبيق.

مثال أفضل:

نستخدم الميكروفون لتسجيل الملاحظة الصوتية التي تختار إضافتها إلى التقرير.

وبالنسبة للكاميرا:

نستخدم الكاميرا لالتقاط صورة الإيصال وإرفاقها بالمعاملة التي تنشئها.

الشرح الثاني يوضح:

٨. طلب صلاحيات أكثر مما يحتاج إليه التطبيق

حتى لو استطعت تقنيًا طلب الوصول إلى:

فهذا لا يعني أنه ينبغي طلبها جميعًا.

Apple تطبق مبدأ Data Minimization وتوصي بطلب الوصول فقط إلى البيانات المرتبطة بالوظيفة الأساسية، واستخدام أدوات مثل Pickers بدل طلب وصول شامل إلى Photos أو Contacts عندما يكون ذلك ممكنًا.

مثال

إذا كان المستخدم يحتاج فقط إلى اختيار صورة واحدة، قد يكون استخدام:

Photo Picker

أفضل من طلب:

Full Photo Library Access

اسأل عن كل Permission:

ماذا سيتوقف في التطبيق إذا لم يعطِ المستخدم هذه الصلاحية؟

إذا لم تجد جوابًا واضحًا، فربما لا تحتاج إليها.

٩. سياسة الخصوصية غير موجودة أو لا تعكس التطبيق

Privacy Policy URL مطلوب للتطبيقات في App Store، كما تطلب Apple توضيح ممارسات جمع واستخدام البيانات داخل App Store Connect.

لكن المشكلة ليست مجرد وجود صفحة اسمها:

/privacy

يجب أن تعكس السياسة ما يفعله التطبيق فعليًا.

Apple تطلب أن توضح سياسة الخصوصية:

لا تنس أيضًا الخدمات التي أضفتها أنت ولم تكتب كودها بنفسك:

أنت مسؤول عن ممارسات الأطراف الثالثة، وكذلك SDKs التي تدمجها في التطبيق.

١٠. تطبيقات الذكاء الاصطناعي لديها نقطة خصوصية إضافية

هذه أصبحت مهمة جدًا.

إذا كان تطبيقك يرسل بيانات شخصية إلى:

فلا تفترض أن الأمر مجرد API عادية لا يحتاج المستخدم إلى معرفتها.

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

فإذا كان تطبيقك يرسل صوت المستخدم أو صوره أو مستنداته أو بريده أو محادثاته أو بياناته الشخصية إلى نموذج خارجي، فعليك التفكير في هذه النقطة منذ تصميم الميزة، لا عند كتابة Privacy Policy في آخر يوم — وهذا امتداد مباشر لنفس المسؤولية التي تتحملها عن حماية بيانات مستخدميك من أي مخاطر أمنية أخرى في مشروعك.

١١. عدم وضوح ما هو مجاني وما هو مدفوع

من المشاكل المتكررة أن تعرض صفحة App Store Feature بصورة جذابة ثم يكتشف المستخدم بعد تنزيل التطبيق أنها خلف Paywall.

يجب أن تكون تجربة المنتج وبيانات Metadata صادقتين بشأن نموذج العمل.

وتوضح Apple أن غموض نموذج العمل أو المشتريات داخل التطبيق قد يؤخر المراجعة ويؤدي إلى الرفض.

إذا كتبت:

إنشاء تقارير متقدمة.

وكانت هذه Feature مدفوعة، فاجعل ذلك واضحًا.

لا تجعل المستخدم يعتقد أنها متاحة مجانًا ثم يواجه:

Subscribe to continue

فور محاولته استخدامها.

١٢. استخدام طريقة دفع غير مناسبة

هذه من أهم النقاط التي يجب فهمها قبل بناء الدفع.

إذا كنت تفتح Features أو خدمات رقمية داخل التطبيق، مثل:

فالقاعدة العامة في Guideline 3.1.1 هي استخدام In-App Purchase.

لكن قواعد الدفع تحتوي استثناءات وتفاصيل تختلف حسب طبيعة السلعة، ونوع الخدمة، والدولة، ومتجر التطبيقات (Storefront)، وصلاحيات (Entitlements) قد يملكها التطبيق.

ولهذا لا تستخدم نصيحة عامة مثل:

Stripe دائمًا أفضل.

أو:

Apple IAP مطلوب لكل شيء.

كلاهما مبسط أكثر من اللازم.

السؤال الصحيح هو:

ماذا أبيع، وأين يتم استهلاكه، وما القاعدة التي تنطبق عليه؟

وتذكر Apple حاليًا اختلافات خاصة لبعض الروابط وطرق الشراء حسب Storefront، بما في ذلك قواعد مختلفة للمتجر الأمريكي وبعض المناطق الأخرى.

١٣. الاشتراك أو التجربة المجانية غير واضحين

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

Apple تنص على ضرورة وصف القيمة التي يحصل عليها المستخدم قبل طلب الاشتراك، كما تحظر الأساليب التي تخدع المستخدم إلى الاشتراك أو تستخدم Bait-and-Switch.

لا تجعل التصميم يقول بخط ضخم:

START FREE

وفي زاوية صغيرة جدًا:

ثم 49.99 ريالًا أسبوعيًا

الشفافية هنا ليست مجرد تحسين UX؛ إنها جزء من سلامة نموذج الدفع.

١٤. In-App Purchase موجودة… لكن Apple لا تستطيع رؤيتها

قد تكون قد بنيت StoreKit بصورة صحيحة، لكن مراجع Apple لا يجد المنتج.

Guideline 2.1 تطلب أن تكون المشتريات داخل التطبيق:

وإذا كان هناك سبب يجعل منتجًا معينًا غير ظاهر، فينبغي شرحه في Review Notes.

اختبر Review Flow كما لو كنت المراجع.

هل يحتاج إلى Secret Gesture أو Account خاص لم تخبره به؟

إذا نعم، فاكتب التعليمات.

١٥. وصف App Store لا يطابق المنتج

قد يكون الكود مثاليًا لكن Metadata تسبب الرفض.

يشمل ذلك:

إذا عرضت Screenshot لميزة لم تعد موجودة، أو كتبت وعدًا لا يستطيع الإصدار الحالي تنفيذه، فأنت تخلق مشكلة.

Apple تنص على أن المعلومات المقدمة يجب أن تعكس التطبيق بصورة دقيقة، كما أن تضليل المستخدم في التسويق يمكن أن يؤدي إلى إجراءات ضد التطبيق.

قبل الإرسال

افتح صفحة App Store بجانب التطبيق نفسه.

راجع كل عبارة وكل Screenshot واسأل:

هل هذا موجود فعلًا في Build الذي سأرسله؟

١٦. Support URL غير مفيد

وجود موقع للتطبيق فكرة جيدة، لكن Support URL ليس مجرد خانة نملؤها بأي رابط.

App Store Connect يوضح أن رابط الدعم يجب أن يقود إلى موقع دعم فعلي يتيح للمستخدم الوصول إليك بخصوص المشكلات والملاحظات وطلبات التطوير.

وتذكر الوثائق أن الرابط يجب أن يؤدي إلى معلومات اتصال فعلية وفق المتطلبات القانونية المناسبة.

صفحة:

Welcome to our company

بلا بريد أو وسيلة دعم ليست خيارًا جيدًا.

١٧. التطبيق مجرد موقع داخل WebView

أحيانًا تكون المشكلة ليست Bug ولا Privacy.

بل السؤال:

لماذا هذا تطبيق أصلًا؟

Apple تنص في Guideline 4.2 على أن التطبيق ينبغي أن يقدم Features ومحتوى وواجهة تجعله يتجاوز مجرد إعادة تغليف موقع إلكتروني. وإذا لم يقدم منفعة كافية أو تجربة تبدو كتطبيق حقيقي، فقد لا يتم قبوله.

إذا كان التطبيق كله:

WebView
→ https://mysite.com

فاسأل:

ما الذي يحصل عليه المستخدم من التطبيق ولا يحصل عليه من فتح الموقع؟

قد تكون الإجابة: وظائف Native، Offline، Camera integration، Notifications ذات قيمة، تجربة مختلفة، أو Workflows خاصة بالموبايل.

لكن مجرد وضع الموقع داخل غلاف iOS ليس دائمًا كافيًا.

١٨. التطبيق مبني من Template دون قيمة مميزة

هذا مهم جدًا مع انتشار أدوات البرمجة بلا كود (No-Code)، والفايب كودنق، ومولدات التطبيقات.

يمكن اليوم إنشاء تطبيق خلال ساعات من Template جاهز.

لكن Apple لديها Guideline صريحة حول التطبيقات المنشأة من Commercial Templates أو App Generation Services، وتطلب أن تكون التطبيقات مخصصة ومبتكرة وتقدم تجربة فريدة بدل تقديم نسخ مكررة.

التغيير من:

Blue

إلى:

Purple

مع تغيير الشعار لا يصنع منتجًا مختلفًا — وهذا بالضبط ما دفع Apple فعليًا إلى حذف مجموعة من تطبيقات Vibe Coding من المتجر حين لم تجد فيها ما يميزها عن بعضها.

١٩. التطبيق يشبه مئات التطبيقات الأخرى

Guideline 4.3 تتعامل مع Spam.

Apple لا تريد عشرات النسخ من التطبيق نفسه أو تطبيقات لا يمكن تمييزها عما هو موجود بكثرة بالفعل.

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

وهذا مهم جدًا في الفايب كودنق.

لا تجعل هدفك:

هل أستطيع توليد تطبيق خلال ساعتين؟

فقط.

اسأل:

لماذا يستحق هذا التطبيق مساحة جديدة في App Store؟

٢٠. تقليد تطبيق أو علامة تجارية أخرى

قد تعطي الذكاء الاصطناعي Screenshot وتقول:

انسخ هذا التطبيق تمامًا.

ثم تنتج واجهة شبيهة جدًا، واسمًا مشابهًا، وأيقونة (Icon) قريبة، أو Branding يمكن أن يسبب التباسًا.

Apple تمنع التطبيقات المقلدة واستخدام علامات أو أسماء أو أيقونات مطورين آخرين دون إذن.

استخدم التطبيقات الأخرى للإلهام. لا تحول الإلهام إلى نسخة.

٢١. استخدام خدمات أو محتوى طرف ثالث دون حق

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

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

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

٢٢. Review Notes فارغة رغم وجود خطوات خاصة

قسم Notes for Review ليس مجرد مكان اختياري لا قيمة له.

App Store Connect يوضح أنه مخصص للمعلومات التي يحتاجها فريق المراجعة، مثل إعدادات خاصة، وطريقة اختبار Feature، وبيانات حساب، وتعليمات مرتبطة بالمراجعة.

استخدمه.

مثال:

Review Instructions

1. Sign in using the demo account provided.
2. Open Settings → Subscription.
3. Select Pro Plan to view the subscription flow.
4. Microphone permission appears only after pressing
   "Record voice note".
5. Test data has already been added to the account.

أنت تعرف تطبيقك جيدًا. المراجع لا يعرفه. لا تجعله يخمن.

٢٣. نموذج العمل غير مفهوم

Apple تقول بوضوح: إذا لم يكن نموذج عمل التطبيق واضحًا، اشرحه في Metadata وفي App Review Notes، لأن عدم فهم كيفية عمل التطبيق أو عمليات الشراء قد يؤخر المراجعة أو يؤدي إلى الرفض.

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

لا تنتظر من المراجع اكتشاف نموذجك التجاري بنفسه.

٢٤. حساب Apple Developer: شرط مسبق وليس سبب رفض

من النصائح المتداولة بدء التسجيل في Apple Developer Program مبكرًا، وهذا مفيد لأن عملية التحقق قد تستغرق وقتًا بحسب الحساب والجهة.

لكن من المهم التفريق بين شروط الاستعداد للنشر وأسباب App Review Rejection.

عضوية Apple Developer Program شرط للتوزيع على App Store، وليست في حد ذاتها سبب رفض داخل App Review.

الرسوم الحالية للبرنامج هي 99 دولارًا أمريكيًا لكل سنة عضوية، مع اختلاف السعر بالعملة المحلية وإعفاءات محتملة لبعض الجهات المؤهلة.

قائمة الفحص قبل إرسال تطبيقك إلى Apple

بدل انتظار رسالة الرفض، نفذ مراجعة قبل Submit.

التطبيق

الحسابات

الصلاحيات

الخصوصية

الدفع

صفحة App Store

App Review

قيمة التطبيق

ماذا تفعل عندما ترفض Apple التطبيق؟

لا تبدأ بتعديل المشروع عشوائيًا.

اقرأ رسالة الرفض. ستجد عادة Guideline مثل:

Guideline 2.1

أو:

Guideline 4.8

أو:

Guideline 5.1.1(v)

ابدأ من رقم القاعدة. ثم:

  1. اقرأ النص الرسمي للقاعدة (Guideline).
  2. افهم ما الذي شاهده المراجع.
  3. حدد هل المشكلة في الكود أم Metadata.
  4. أعد إنتاج المشكلة إن أمكن.
  5. أصلح السبب المحدد.
  6. اختبره.
  7. اكتب في Review Notes ما الذي تغير.
  8. أعد الإرسال.

Apple نفسها تتيح التواصل مع فريق App Review عبر App Store Connect عند وجود أسئلة أو الحاجة إلى تقديم معلومات إضافية، كما توجد إمكانية الاستئناف إذا كنت تعتقد أن نتيجة المراجعة غير صحيحة.

لا تحاول حل الرفض بإخفاء المشكلة

إذا كانت لديك Feature تخشى أن ترفضها Apple، فلا تجعل خطتك:

سأخفيها أثناء المراجعة ثم أفعلها بعد الموافقة.

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

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

App Review تبدأ قبل رفع التطبيق

أحد أهم الدروس هنا أن التحضير لمراجعة Apple لا يبدأ عند فتح App Store Connect.

بل يبدأ عندما تقرر:

هل سأطلب إنشاء حساب؟

لأن عليك التفكير في حذف الحساب.

ويبدأ عندما تقول:

سأضيف Google Sign-In.

لأن عليك مراجعة Guideline 4.8.

ويبدأ عندما تقول:

سأستخدم الميكروفون.

لأن عليك تحديد سبب الاستخدام والموافقة.

ويبدأ عندما تقول:

سأرسل هذه الصورة إلى نموذج AI.

لأن الخصوصية ومشاركة البيانات أصبحت جزءًا من تصميم الميزة.

ويبدأ عندما تقول:

سأجعل هذه Feature مدفوعة.

لأن عليك تحديد آلية الدفع الصحيحة.

ويبدأ عندما تقول:

سأحول موقعي إلى تطبيق.

لأن عليك التأكد أن المنتج يقدم قيمة تتجاوز WebView.

الخلاصة

رفض Apple للتطبيق ليس حدثًا عشوائيًا بالكامل، ولا ينبغي التعامل معه بوصفه عقبة تظهر فقط في نهاية المشروع.

الكثير من أسباب الرفض يمكن تقليلها إذا صممت التطبيق منذ البداية مع App Review في ذهنك.

قبل التقديم تأكد من خمسة أشياء رئيسية:

أولًا: أن التطبيق مكتمل ويعمل في النسخة الحقيقية التي سترسلها.

ثانيًا: أن تسجيل الدخول والحسابات والحذف مصممة وفق متطلبات Apple الفعلية، لا وفق نصائح عامة متداولة.

ثالثًا: أن المستخدم يفهم لماذا تطلب بياناته وصلاحياته وإلى أين ترسلها.

رابعًا: أن المشتريات والاشتراكات والوصف والصور تعكس المنتج بصدق.

خامسًا: أن التطبيق يقدم قيمة حقيقية تستحق وجود تطبيق مستقل في App Store.

ولا تعتمد على مقطع فيديو أو تجربة مطور واحد بوصفها المصدر النهائي للسياسة.

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

App Store Review Guidelines الرسمية.

فالقاعدة قد تحتوي على استثناء لم يذكره صاحب التجربة، وقد تكون السياسة تغيرت منذ نشر المعلومة.

الهدف ليس فقط أن تصل إلى:

Ready for Distribution

بل أن تبني التطبيق من البداية بطريقة تجعل رحلة:

Build
→ Review
→ Approval

أكثر هدوءًا ووضوحًا، بدل أن تتحول إلى دورة طويلة من:

Submit
→ Reject
→ Guess
→ Fix
→ Submit
→ Reject again
صمّم للمراجعة منذ البداية، واختبر قبل الإرسال، واجعل مراجع Apple قادرًا على فهم تطبيقك وتجربته

دون الحاجة إلى تخمين ما كنت تقصده.

المصادر الأساسية

تمت مراجعة هذا الدرس بالرجوع إلى App Store Review Guidelines الرسمية المحدثة من Apple، ووثائق App Store Connect الخاصة بمعلومات المراجعة والخصوصية وروابط الدعم، وإرشادات حذف الحساب، ومتطلبات In-App Purchase وبرنامج Apple Developer Program. وتبقى إرشادات Apple الرسمية المرجع الأهم لأنها قابلة للتحديث مع تغير السياسات.