كيف تحصل على موافقة App Store وPlay Store على تطبيقك

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

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

مشكلة العمل: الموافقة خطر على الإطلاق وليست إجراءً شكليًا

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

مراجعة Apple أكثر صرامة ويجريها مراجعون بشر، ولذلك تحدث فيها معظم المفاجآت. أما مراجعة Google فأسرع لكنها أصبحت أكثر تشددًا مع السنين. على سبيل المثال، يجب على حساب مطوّر شخصي جديد في Google Play أن يجري اختبارًا مغلقًا مع 12 مختبِرًا على الأقل لمدة 14 يومًا متتالية قبل أن يتمكن من النشر للإنتاج (حسابات المؤسسات معفاة). إن لم تكن تعرف ذلك، فقد تأخر موعد إطلاقك أسبوعين للتو.

التعامل مع الموافقة كجزء من الخطة، لا كأمر ثانوي، هو ما يحافظ على موعد إطلاقك.

ما الذي تشترطه المتاجر فعلًا

تتغير التفاصيل مع الوقت، لكن فئات المتطلبات ثابتة:

• تطبيق مكتمل يعمل. يرفض المراجعون التطبيقات التي تتعطل، أو فيها ميزات معطلة، أو تبدو غير مكتملة. العرض التجريبي الذي "يعمل في الغالب" لا يكفي، وهي الفجوة التي أتناولها في ما الذي يجعل تطبيق الجوال جاهزًا للإنتاج.
• الشفافية في الخصوصية. يشترط المتجران إفصاحًا واضحًا عن البيانات التي تجمعها وسبب جمعها، وسياسة خصوصية، وطلبات أذونات سليمة. ملصقات الخصوصية في Apple وقسم Data safety في Google Play إلزاميان، كما تتوقع Apple وجود بيانات خصوصية (privacy manifests) لحزم SDK الخارجية المضمّنة في تطبيقك.
• وصول فعلي إلى الحساب. إذا كان لتطبيقك تسجيل دخول، يحتاج المراجعون بيانات دخول تجريبية تعمل لاختباره. إغفال ذلك سبب شائع للرفض ويمكن تجنبه.
• صفحات متجر صادقة ودقيقة. يجب أن تطابق لقطات الشاشة والوصف والبيانات الوصفية ما يفعله التطبيق فعلًا.
• حذف الحساب. إذا كان المستخدمون يستطيعون التسجيل، فالمتجران يتوقعان الآن وسيلة لحذف الحساب من داخل التطبيق. كما يطلب Google Play رابطًا على الويب يتيح للمستخدمين طلب الحذف دون إعادة تثبيت التطبيق.
• إصدارات محدّثة. يرفع المتجران الحد الأدنى لمتطلبات SDK كل عام. تشترط Apple إصدارات مبنية بإصدار حديث من Xcode وiOS SDK، ويشترط Google Play أن تستهدف التطبيقات الجديدة والتحديثات مستوى Android API حديثًا. إن فاتك الموعد النهائي فلن تتمكن من نشر التحديثات حتى تُرقّي.
• تصنيفات عمرية دقيقة. أعادت Apple تصميم تصنيفاتها العمرية (بإضافة 13+ و16+ و18+)، ولدى بعض المناطق الآن قوانين للتحقق من العمر. أجب عن أسئلة التصنيف بعناية، خاصة إن كان تطبيقك يحتوي على دردشة أو محتوى ينشئه المستخدمون.
• قواعد المنصة. مثل الالتزام بإرشادات التصميم والمحتوى، وقواعد الدفع مقابل السلع الرقمية. قواعد الدفع في تغير مستمر: فبعد قضايا Epic في المحاكم، أصبح بإمكان التطبيقات في الولايات المتحدة توجيه المستخدمين للدفع عبر الويب، كما تسمح Google بالفوترة البديلة في الولايات المتحدة، وللاتحاد الأوروبي قواعده الخاصة بموجب قانون الأسواق الرقمية. ولا تزال الرسوم والشروط قيد الحسم في المحاكم، لذلك أتحقق من القواعد الحالية لكل سوق قبل تصميم مسار الدفع.

لماذا يهم هذا المؤسسين

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

مثال واقعي

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

أسباب شائعة لرفض التطبيقات

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

كيف أتعامل مع تقديم التطبيق للمتجر

1. أخطط للموافقة من اليوم الأول، لا كمهمة في اليوم الأخير.
2. أبني العناصر المطلوبة مبكرًا: سياسة الخصوصية، والأذونات، وحذف الحساب، والوصول التجريبي.
3. أتأكد أن التطبيق جاهز للإنتاج فعلًا، لا مجرد عرض تجريبي مصقول.
4. أُعدّ صفحات متجر صادقة ودقيقة بلقطات شاشة وبيانات وصفية حقيقية.
5. أقدّم التطبيق مع كل ما يحتاجه المراجعون لتكون المحاولة الأولى هي الناجحة.
6. أبقى متجاوبًا أثناء المراجعة، ليُحسم أي استفسار في ساعات لا أيام.

بهذه الطريقة تصبح موافقة المتجر خطوة متوقعة بدلًا من مقامرة مقلقة عند خط النهاية.

هل تخطط لإطلاق تطبيق جوال؟

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

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