نشر التطبيق في App Store وGoogle Play: التجهيز والمراجعة وأسباب الرفض

بعد أشهر من التصميم والتطوير، قد يتأخر إطلاق التطبيق أيامًا أو أسابيع بسبب ملاحظة في مراجعة المتجر لم يتوقعها الفريق. فلكل من App Store وGoogle Play إرشادات مكتوبة وعملية مراجعة، ومعرفتها مبكرًا توفر وقتًا وجهدًا كبيرين.

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

1. جهّز الحسابات والمواد قبل الإرسال

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

• حساب المطوّر باسم الشركة: سجّل حساب Apple Developer وحساب Google Play Console باسم المنشأة، فالتسجيل كجهة اعتبارية قد يتطلب مستندات تحقق تستغرق وقتًا.
• هوية التطبيق: اسم التطبيق ومعرّف الحزمة (Bundle ID أو Package Name) يُحددان مبكرًا، لأن المعرّف لا يتغير بعد النشر.
• سياسة الخصوصية وشروط الاستخدام: صفحات منشورة على موقع الشركة بروابط تعمل.
• المواد المرئية: أيقونة وصور شاشة بالمقاسات المطلوبة لكل متجر ولأحجام الأجهزة المختلفة.
• حساب تجريبي: إذا كان التطبيق يتطلب تسجيل دخول، جهّز حسابًا يستخدمه فريق المراجعة مع بيانات تجريبية واضحة.

2. كيف تسير المراجعة في المتجرين

يرسل الفريق نسخة البناء إلى المتجر مع بيانات الصفحة، ثم يراجعها المتجر للتحقق من توافقها مع إرشاداته قبل إتاحتها للجمهور. وتعتمد Apple على مراجعة تجمع بين الفحص الآلي والبشري وفق إرشادات مراجعة App Store، بينما تعتمد Google على سياسات مطوري Google Play وفحوص آلية وبشرية كذلك. ويتيح المتجران قبل ذلك قنوات اختبار، مثل TestFlight لدى Apple ومسارات الاختبار الداخلي والمغلق في Google Play.

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

3. أسباب الرفض الشائعة وكيف تتجنبها

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

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

4. الخصوصية وإفصاحات البيانات

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

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

5. تحسين صفحة المتجر لزيادة الظهور والتنزيل

صفحة التطبيق في المتجر هي أول ما يراه المستخدم، وتحسينها يُعرف بتحسين متجر التطبيقات (ASO). والهدف أمران: أن يظهر التطبيق في نتائج البحث، وأن تقنع الصفحة الزائر بالتنزيل.

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

6. ما بعد النشر: التحديثات والإصدار التدريجي

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

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

الخلاصة

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