لماذا يُرفض تطبيقك في App Store أو Google Play؟

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

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

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

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

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

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

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

خذ قائمة بكل إذن على iOS وAndroid واسأل: ما الوظيفة التي تفشل بدونه؟ متى يطلب التطبيق الإذن؟ ماذا يحدث إذا رفضه المستخدم؟ من الأفضل أن يفهم المستخدم السبب عند دخوله الوظيفة، وأن يبقى ما لا يعتمد على الإذن قابلًا للاستخدام. راجع مكتبات التحليل والإعلانات والإشعارات أيضًا؛ قد تجمع بيانات لا يلاحظها صاحب المنتج عند إعداد إفصاحات المتجر. طابق السلوك الفعلي مع تصريحات الخصوصية بمراجعة تقنية وقانونية مناسبة.

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

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

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

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

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

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