كان التطبيق جاهزاً. البناء يعمل، والاختبار المغلق في لوحة المطوّرين انتهى بنجاح، والملاحظات عُولجت. ثم توقّف كل شيء عند عقبة لم تكن في أي قائمة قرأناها: الحساب يتطلّب كياناً تجارياً موثّقاً، لا حساب فرد. لا علاقة للأمر بجودة التطبيق ولا بكوده — مجرّد شرط إداري يظهر في نهاية الطريق لا في بدايته.
هذا المقال هو ما كنّا نتمنّى قراءته قبل أن نبدأ: العقبات الحقيقية بترتيب ظهورها، ولماذا ينكسر كلٌّ منها، وأيّها يُكتشف متأخّراً جدّاً. أغلبها ليس برمجياً — وهذا بالضبط سبب المفاجأة.
الالتباس الأول: مفتاحان لا مفتاح واحد
هذا أكثر ما يُربك من ينشر أول مرّة، وهو مصدر أعطال يستحيل تشخيصها بلا فهمه.
حين تفعّل توقيع التطبيقات من قوقل (Play App Signing) — وهو الوضع الافتراضي اليوم — يصبح لديك مفتاحان مختلفان تماماً:
- مفتاح الرفع (upload key): تولّده أنت على جهازك، وتوقّع به الحزمة التي ترفعها. وظيفته إثبات أن الرفع منك.
- مفتاح التوقيع (app signing key): يملكه قوقل ويحفظه، ويعيد توقيع تطبيقك به قبل توصيله للأجهزة. هذا هو المفتاح الذي يراه الجهاز فعلاً.
الأثر الذي يصعق المطوّرين: أي خدمة تتحقّق من بصمة التوقيع سترى بصمة قوقل في النسخة المنزّلة من المتجر، لا بصمتك. فتعمل نسخة التطوير على جهازك بلا مشكلة، وتعمل نسخة الاختبار المرفوعة، ثم تفشل النسخة المنشورة فقط. المستخدم يشتكي وأنت لا تستطيع تكرار المشكلة.
وتحتاج البصمة بصيغتين لا صيغة واحدة: SHA-1 تكفي لتسجيل الدخول بقوقل، أمّا التحقّق برقم الجوال فيحتاج SHA-256 لأنه يعتمد إثبات سلامة التطبيق. تفصيل الأولى في فشل تسجيل الدخول بقوقل، والثانية في رمز التحقّق بالجوال.
حماية المفتاح: خطأ واحد لا رجعة فيه
ملف مفتاح الرفع وكلمة سرّه لا يجوز أن يدخلا مستودعاً عاماً أبداً. استثنِهما صريحاً في ملف .gitignore قبل أول التزام لا بعده — فالملف الذي دخل تاريخ المستودع مرّة يبقى فيه حتى لو حذفته لاحقاً.
وتحفّظ عملي نتّبعه: مستودعنا خاصّ، فنُبقي ملف الإعدادات الذي يحمل كلمات المفاتيح متتبَّعاً بوعي، ونستثني ملف المفتاح نفسه دائماً. القرار مقبول بشرطين: أن يكون المستودع خاصّاً فعلاً، وأن يكون القرار موثّقاً حتى لا يُخلط بسهو. أمّا مع مستودع عام فلا استثناء ولا نقاش.
وأهمّ من ذلك: احفظ نسخة من مفتاح الرفع في مكان آمن مستقلّ. ضياعه ليس نهاية العالم — يمكن طلب إعادة تعيينه — لكنّ العملية تستغرق أياماً وتحتاج إثباتات. ولو كنت لا تستخدم توقيع قوقل فضياع المفتاح يعني استحالة تحديث تطبيقك إلى الأبد، وحلّه الوحيد نشر تطبيق جديد بمعرّف حزمة جديد وخسارة كل مستخدميك وتقييماتك.
الاختبار المغلق: شرط لا خيار
الحسابات الجديدة لم تعد تنشر مباشرة. عليك أولاً تشغيل مسار اختبار مغلق بعدد أدنى من المختبرين الحقيقيين، ولمدّة متّصلة، قبل أن يُسمح لك بطلب النشر العام. والتفاصيل التي تُغفل:
- المختبرون يجب أن ينضمّوا فعلاً ويثبّتوا التطبيق. حساب مضاف بلا تثبيت لا يُحتسب.
- المدّة متّصلة: انقطاع المسار أو تفريغ قائمة المختبرين قد يُعيد العدّاد.
- ابدأ هذه الخطوة مبكراً بالتوازي مع إكمال التطبيق، لا بعد اكتماله. هي أطول عنصر زمني في المسار كلّه ولا يمكن تسريعها بالمال ولا بالجهد.
العقبة التي لا تُكتشف إلا متأخّراً: نوع الحساب
هذه التي أوقفتنا. بعض الحسابات — بحسب تاريخ إنشائها وبلدها وطبيعة تطبيقها — يُطلب منها التحوّل إلى حساب مؤسسة: كيان تجاري موثّق بسجل رسمي، لا حساب فرد. والمشكلة ليست في الشرط نفسه بل في توقيت ظهوره: بعد كتابة التطبيق واختباره وتجهيز صفحته وإكمال كل الإفصاحات.
ما نوصي به بناءً على ذلك: تحقّق من متطلّبات حسابك في اليوم الأول، قبل أن تكتب سطراً. إن كان تطبيقك تجارياً أو ينوي تحقيق دخل، افترض أن الكيان التجاري سيُطلب، وابدأ إجراءات تسجيله بالتوازي مع التطوير. تسجيل السجل التجاري يستغرق أسابيع في أفضل الحالات، وهي أسابيع يمكن أن تمرّ وأنت تكتب الكود بدل أن تنتظرها عاطلاً بعد أن ينتهي.
الإفصاحات الإلزامية: أشهر أسباب الرفض
هذه أرخص العقبات وأكثرها تسبّباً في الرفض، لأنها تُترك للنهاية فتُملأ بعجالة:
- نموذج سلامة البيانات (Data safety): تصريح بما يجمعه تطبيقك وما يشاركه ولماذا. يجب أن يطابق سلوك تطبيقك فعلاً — والمراجعة تفحص التطابق. تصريح بأنك لا تجمع شيئاً مع وجود مصادقة وتحليلات = تناقض يُرفض.
- سياسة خصوصية علنية: رابط يعمل على الويب، لا داخل التطبيق فقط، ويجب أن تُسمّى فيه أنواع البيانات فعلاً لا صياغة عامة منسوخة.
- صفحة حذف الحساب: إن كان تطبيقك يتيح إنشاء حساب، فعليك توفير مسار لحذفه وصفحة ويب تشرحه يمكن الوصول إليها بلا تثبيت التطبيق. هذا شرط منفصل عن سياسة الخصوصية، ويُغفل كثيراً.
- تقييم المحتوى: استبيان يحدّد الفئة العمرية. أجب بدقّة — إجابة غير مطابقة للمحتوى تُعالج كتضليل.
- الأذونات: كل إذن حسّاس يحتاج تبريراً. أذونات مطلوبة بلا استخدام فعلي سبب رفض مباشر — راجع بيان التطبيق واحذف ما لا تستخدمه.
تطبيقات الغلاف: أدقّ معيار في المراجعة
إن كان تطبيقك يعرض موقعك في WebView، فأنت في المنطقة الأكثر حساسية. المتجر يرفض ما هو «مجرّد موقع مُغلَّف» بلا قيمة مضافة. ما يُصنَع الفرق فعلاً:
- ميزات أصلية حقيقية: إشعارات فورية، عمل دون اتصال، تكامل مع مشاركة الملفات أو الكاميرا — شيء لا يقدّمه المتصفّح.
- تجربة تطبيق لا تجربة متصفّح: بلا شريط عنوان، وبتنقّل يستجيب لزرّ الرجوع، وبشاشة بداية، وبمعالجة لحالة انقطاع الشبكة.
- عدم فتح روابط خارجية داخل الغلاف — تُفتح في المتصفّح.
وقيد إعلاني حاكم يخصّ هذه التطبيقات تحديداً: إعلانات المواقع مخصّصة للمواقع، وظهورها داخل تطبيق منشور مخالفة. والتطبيق الذي يحمّل نطاقك الحيّ يعرض كل ما يعرضه موقعك، إعلاناته ضمناً. فيجب كشف البيئة الأصلية برمجياً وحجب سكربتات إعلانات الويب داخل التطبيق — تفصيلها في من موقع إلى تطبيق أندرويد بـ Capacitor، وأثرها على العائد في إعلانات المواقع العربية.
أعطال تقنية تعطّل الرفع
عقبات صغيرة لكنها توقف البناء أو الرفع تماماً:
- بيئة الجافا للبناء: أدوات البناء تحتاج إصدار جافا متوافقاً بالضبط. أسلم حلّ عملي هو توجيه
JAVA_HOMEإلى بيئة التشغيل المرفقة مع بيئة تطوير أندرويد نفسها، بدل الاعتماد على تنزيل مستقلّ قد يُحدَّث أو يُحذف فينكسر البناء برسالة غامضة لا تذكر جافا أصلاً. - رقم الإصدار: كل رفع يحتاج رقم بناء أعلى من كل ما سبقه. لا يمكن إعادة استخدام رقم ولا الرجوع للخلف.
- مستوى واجهة برمجة التطبيقات الهدف: المتجر يفرض حدّاً أدنى يتحدّث سنوياً، ويرفض الرفع دونه — حتى لو كان تطبيقك يعمل تماماً.
- حجم الحزمة والأصول: صيغة الحزمة الحديثة تولّد نسخاً مخصّصة لكل جهاز، فراجع الأصول غير المستخدمة قبل الرفع.
قائمة تحقّق قبل الرفع
- متطلّبات نوع الحساب مُتحقَّق منها — في اليوم الأول.
- بصمات المفاتيح الثلاثة مسجّلة، بصيغتَي
SHA-1وSHA-256. - ملف المفتاح مستثنى من المستودع، ونسخته الاحتياطية محفوظة مستقلّة.
- مسار الاختبار المغلق شُغّل مبكراً بمختبرين ثبّتوا التطبيق فعلاً.
- نموذج سلامة البيانات يطابق سلوك التطبيق حرفياً.
- سياسة خصوصية وصفحة حذف حساب، كلتاهما على الويب وتعملان.
- الأذونات مُنقّاة — لا إذن بلا استخدام.
- تسجيل الدخول مُختبَر على نسخة الاختبار المرفوعة لا على نسخة التطوير وحدها.
- الاختبار على جهاز حقيقي لا محاكي، خصوصاً للمصادقة.
أسئلة شائعة
كم تستغرق المراجعة؟ النطاق واسع جدّاً: أيام إلى أسابيع، ويطول مع الحسابات الجديدة وتطبيقات الغلاف. لا تربط موعد إطلاق تسويقي بتاريخ لا تتحكّم فيه.
رُفض تطبيقي — هل أعيد الرفع فوراً؟ لا. اقرأ سبب الرفض بحرفيته وعالجه تحديداً. إعادة الرفع بلا تغيير حقيقي، أو تغيير عشوائي رجاء أن ينجح، يُطيل الدورة ويترك سجلاً سيّئاً على الحساب.
هل أنشر مباشرة أم بإطلاق تدريجي؟ تدريجي دائماً. تبدأ بنسبة صغيرة من المستخدمين وتراقب أعطال التشغيل، فيمكنك إيقاف الانتشار قبل أن يصل خلل إلى الجميع.
هل أحتاج حساب مؤسسة من البداية؟ ليس كل الحسابات تُطلب منها ذلك، لكن التحقّق مجاني ويستغرق دقائق. القاعدة الآمنة: افترض أنه سيُطلب إن كان تطبيقك تجارياً، وتحقّق قبل أن تبدأ.
خلاصة
الكود هو الجزء الذي تسيطر عليه، ولهذا لن يكون سبب تأخّرك. ما يؤخّرك: التسجيل التجاري، ومدّة الاختبار المغلق، ودورات المراجعة — وكلّها خارج سيطرتك، وكلّها يمكن أن تبدأ قبل أن تنتهي من التطوير.
ودرسنا الأغلى: بصمة التوقيع. تحقّق دائماً من نسخة المتجر لا من نسخة جهازك، لأن قوقل يعيد توقيع تطبيقك بمفتاحه — فالبصمة التي يراها العالم ليست بصمتك، وأي خدمة تتحقّق منها ستفشل في المكان الوحيد الذي لا تختبره: عند مستخدميك.