لنفترض أنك تبني تطبيق قائمة مهام في المحادثة منذ أسبوعين. إنه موقع ويب الآن — React وقاعدة بيانات، لا شيء معقد. تكتب "اصنع لي نسخة أندرويد" وتضغط إدخال. إليك ما يحدث فعليًا بين تلك الضغطة وملف .aab يصل إلى مجلد التنزيلات لديك، لأن معظم المنصات لا تُظهر لك هذا الجزء، والجزء الذي تخفيه هو حيث كان كل الألم يكمن سابقًا.
ملف .aab لأندرويد
يتولى Gradle الأمر أولًا. الوحدات الأصلية لتطبيقك — الوصول إلى الكاميرا، التخزين المحلي، وأي إضافات جلبها البناء — كل منها يُعلن عن إصدار NDK الذي تم تجميعه به، وهذه الإعلانات لا تتفق دائمًا. رأيت وحدة مبنية على NDK r25 ترفض الربط مع أخرى افترضت r26، والخطأ الذي يظهر لا يقول "تعارض إصدار"، بل شيئًا عن رمز مفقود على عمق ثلاث طبقات داخل ملف .so. إصدارات Kotlin تفعل شيئًا أكثر خفاءً: إصدار مُثبَّت داخل وحدة Gradle واحدة يمكن أن يحجب بصمت الإصدار المُعلن في أعلى سكريبت البناء الخاص بك، وينجح البناء — لكنه ينتج ثنائيًا يتعطل على إصدارات أندرويد محددة في الواقع. لا شيء من هذا غريب. إنها الضريبة المعتادة لإطلاق تطبيق أندرويد أصلي، ولهذا تستأجر الفرق شخصًا مهمته الوحيدة معرفة أي إعداد يُزيل خطأ هذا الأسبوع.
البناء هنا يشغّل سلسلة الأدوات الحقيقية ويتحمل عمل الحل بنفسه:
- اكتشاف تعارضات الاعتماديات قبل أن تتحول إلى عطل وقت التشغيل
- إعدادات سلسلة الأدوات تتحسن في كل مرة يُعلّمها فيها فشل جديد شيئًا
نسخة أسرع ومزيّفة من هذا — شيء يُشكّل ملف .aab دون تشغيل مهام Gradle الفعلية — قد تُصدَر في أقل من دقيقة. لكنها ستنهار فور احتياج تطبيقك خدمة خلفية أو مكتبة تشفير أصلية، وستُبلغ مراجعة متجر Play عنها خلال يوم. نفضّل قضاء العشرين دقيقة.
ملف .dmg لنظام macOS
يدخل بناءان في هذا الملف الواحد. تقوم أدوات سطر أوامر Xcode بتجميع ثنائي Apple Silicon وثنائي Intel بشكل منفصل، ثم lipo تدمجهما في ملف تنفيذي عالمي واحد.
هذا مغرٍ — إصدار ثنائي واحد وانتهى الأمر — إلى أن تتذكر أن كثيرًا من الناس يستخدمون جهاز حاسوبهم المحمول الخاص بجهة العمل لا اختيارهم الخاص من العتاد، وقد يكون هذا الجهاز عمره ثلاث سنوات ويعمل بمعالج Intel. بدلًا من إجبار المستخدم على معرفة نوع المعالج لديه (معظمهم لا يستطيع إخبارك)، نصدر النسختين ونترك نظام التشغيل يختار بصمت. البديل، الذي جربناه في البداية، هو التجميع المتقاطع لكل شيء من جهاز Linux باستخدام سلاسل أدوات محاكاة. إنه أسرع. لكنه أيضًا الطريقة التي ينتهي بها الأمر بحالة توقيع كود حافة تظهر فقط على عتاد macOS 12 حقيقي، بعد ستة أسابيع من الإطلاق، يُبلّغ عنها مستخدم حائر لا يعرف لماذا لا يفتح تطبيقه.
مُثبّت ويندوز
هنا تتقرر تجربة أول تشغيل ما إذا كان المستخدم سيثق بالتطبيق أصلًا. لا يعرف Windows SmartScreen مثبّتك بعد — فهو لم يبنِ سمعة لدى خوادم مايكروسوفت بعد — لذا يعرض شاشة زرقاء "حمى Windows جهاز الكمبيوتر الخاص بك" بزر يقول "عدم التشغيل" بخط عريض ورابط "مزيد من المعلومات" بالكاد مرئي، والذي يكشف عند النقر عليه "تشغيل على أي حال". يقوم macOS بنسخته الخاصة من هذه الرقصة: نقر بزر الفأرة الأيمن، فتح، تأكيد، لأن التطبيقات خارج App Store غير موثوقة افتراضيًا أيضًا. في البداية، ربطنا كلا الأمرين بصفحة أسئلة شائعة عامة. أخبرتنا تذاكر الدعم أن هذا لا يجدي — شخص يحدّق في شاشة تقول إن تنزيله قد يكون برمجية خبيثة لا يذهب لقراءة الوثائق، بل يلتقط صورة للشاشة ويسأل إن كان قد تعرض للاختراق. لذا يكتشف مسار التثبيت نظام التشغيل ويعرض النقرات الثلاث المحددة اللازمة، دون الحاجة إلى أسئلة شائعة. تفصيل صغير، لكن الملف نفسه مهم أيضًا: التنزيل يُسمى باسم منتجك، لا باسم ناتج بناء. لا يجب أن يضطر أحد لشرح عبر دعم الدردشة أنه نزّل "app-release-signed-v2-final.exe" ولا يمكنه معرفة إن كان هو الملف الصحيح.
بيان إضافة المتصفح (manifest)
هذا هو العنصر الشاذ في كامل خط الإنتاج — لا Gradle، لا NDK، ولا خطوة تجميع بالمعنى المعتاد. ما يملكه بدلًا من ذلك هو بيان (manifest)، وهذا البيان هو تفاوض مع مراجع متجر Chrome لن تتحدث معه مباشرة أبدًا.
| الصلاحية المطلوبة | نتيجة المراجعة |
|---|---|
| <all_urls> (أوسع مما تحتاجه الميزة) | جدال لمدة أسبوعين مع شخص لن يقول بالضبط ما اعترض عليه |
| activeTab (مقتصرة على الحاجة الفعلية) | تُقبل في نفس اليوم |
تُعقّد MV3 أيضًا شيئًا كان MV2 يجعله سهلًا: يتم إلغاء تحميل عمّال الخدمة الخلفيين في منتصف المهمة بحسب التصميم، وهو قرار سياسة من جوجل يهدف إلى إطالة عمر البطارية، والميزة التي تحتاج للنجاة من ذلك يجب بناؤها حوله لا ضده. نضبط كل إضافة افتراضيًا على أضيق مجموعة صلاحيات تحتاجها وظيفتها الفعلية ونوسّعها فقط عندما تتطلب ميزة محددة ذلك.
مفتاح التوقيع (Keystore)
تحت بناء أندرويد يكمن الأثر الوحيد الذي لا تراه أبدًا ولا يمكنك تحمّل فقدانه: مفتاح التوقيع. فقدانه لا يعني فقط فقدان القدرة على تحديث تطبيقك — بل فقدان القدرة على تحديثه بهويته القائمة، بشكل دائم، دون أي مسار استعادة تمنحه جوجل أبدًا. إنها ليست بنية تحتية براقة. إنه مجرد ملف. لكنه الفرق بين إصدار النسخة السادسة بعد ستة أشهر كتحديث سلس، وإصدارها كقائمة جديدة تمامًا تبدأ من صفر تثبيت وصفر تقييمات. نُنشئ واحدًا لكل مشروع ونحتفظ به حتى تُوقّع كل عمليات البناء المستقبلية بنفس المفتاح منذ اليوم الأول.
خيط المحادثة تحت كل هذا
لا شيء مما سبق يعيش في "مشروع جوال" منفصل. إنها نفس المحادثة التي بنت تطبيق الويب. اطلب تغييرًا في الواجهة، ويتحدث بناء الويب؛ اطلب حزمة أندرويد بعد ذلك، وتُجمّع من نفس الحالة الحالية، لا من نسخة انحرفت عن التزامن قبل ثلاثة أسابيع. معظم الفرق التي راقبتها تحاول إضافة الأصلي لاحقًا تنتهي بصيانة قاعدتي أكواد تتباعدان — تطبيق ويب يُصدر يوميًا وغلاف أصلي يجب على شخص ما تذكّر تحديثه قبل كل إصدار. تلك الفجوة هي مكان تراكم القِدم، وهي بالضبط ما يُزيله سجل بناء واحد. لكن للأمر وجهين: إن كانت المحادثة سريعة ومتساهلة مؤخرًا، يرث بناء أندرويد ذلك أيضًا. إنه ليس تمريرة تلميع منفصلة، بل تجميع مباشر لكل ما هو موجود فعليًا — وهو ما يُبقي الناس صادقين عمليًا، لأنه لا توجد مهمة جانبية بعنوان "سننظف هذا قبل التقديم" يمكن تخطيها.
عندما يصبح جاهزًا لمتجر التطبيقات، يُسلّم مسار الإطلاق إلى قائمة متجر Play الخاصة بك وحساب Apple Developer الخاص بك. ليس حسابنا. لم نرغب في الوقوف بينك وبين توزيعك الخاص.
