تطبيقات جوّال لنظامي iOS وAndroid.

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

تعدد المنصات هو الافتراضي الصحيح حين

• يتكوّن التطبيق من شاشات ونماذج وقوائم ووسائط ونداءات API — وهذا وصف لمعظم المنتجات التي يدفع الناس لبنائها.
• يجب أن يصدر iOS وAndroid معًا، من فريق واحد وقائمة أعمال واحدة.
• تكون لغتك البصرية الخاصة أهم من مطابقة عناصر التحكم القياسية في كل منصة بدقة.
• يجب أن تغطي الميزانية منصتين، ولا مجال لفريق أصلي ثانٍ.

والأصلي يستحق كلفته حين

• يعيش التطبيق على العتاد: Bluetooth Low Energy متواصل، أو مسارات كاميرا، أو حسّاسات، أو واقع معزّز، أو سلوك دقيق في الخلفية.
• يعتمد على SDK من مورّد لا يصدر إلا لـ Swift وKotlin، بلا جسر مصان.
• يستند إلى واجهات نظام أصلية بطبيعتها — عناصر الشاشة الرئيسية، والأنشطة الحية، وتطبيقات الساعة، وامتدادات المشاركة، والتكامل العميق مع النظام.
• تكون إحدى المنصتين هي المنتج والأخرى فكرة لاحقة.
• يصون فريق قائم شيفرة أصلية أنت تمدّها لا تستبدلها.

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

التصميم يعرض الشاشات. والبناء هو الشاشات مضافًا إليها كل ما تفرضه المنصتان حولها، وهذه القائمة الثانية هي موضع تجاوز مشاريع الجوّال لتقديراتها.

• التهيئة والأذونات: طلب الإشعارات أو الكاميرا أو الصور أو الموقع في لحظة يفهم فيها المستخدم السبب — والتصرّف الصحيح حين يكون الجواب لا.
• إدارة الحساب: تسجيل الدخول، واستعادة كلمة المرور، وانتهاء الجلسة على جهاز يحتفظ به صاحبه سنوات، وحذف الحساب من داخل التطبيق، وهو ما تشترطه Apple على كل تطبيق يتيح إنشاء حساب.
• Sign in with Apple، وتشترطه Apple حين تعرض خيارات تسجيل دخول أخرى من أطراف ثالثة.
• المدفوعات: السلع المادية والخدمات في العالم الواقعي تمر عبر مزوّد دفع عادي. أما المحتوى الرقمي والاشتراكات التي تُستهلك داخل التطبيق فتمر عبر فوترة App Store وGoogle Play، بما يرافقها من عمولة المنصة والتحقق من الإيصالات.
• تقارير الأعطال وتحليلات المنتج موصولة قبل الإطلاق، لأن أعطال الأسبوع الأول هي التي تحدّد تقييمك.
• سياسة خصوصية، وإفصاح Apple عن خصوصية التطبيق، ونموذج سلامة البيانات لدى Google — وكلاهما يجب أن يطابق ما يرسله التطبيق فعلًا.
• مواد المتجر: الأيقونة، ولقطات الشاشة بكل مقاسات الأجهزة المطلوبة، والأوصاف والكلمات المفتاحية بكل لغة تدرجها.
• السلوك دون اتصال، والحالات الفارغة، وحالات الخطأ، وما يفعله التطبيق على اتصال بطيء داخل مصعد.

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

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

الحسابات والتوقيع

حساب Apple Developer Program وحساب Google Play Console لك، باسم شركتك. وحساب المؤسسة لدى Apple يتطلب رقم D-U-N-S، والحصول عليه يستغرق وقتًا، لذلك يُبدأ فيه مبكرًا لا في الأسبوع السابق للإطلاق. نعمل داخل حساباتك. ومفاتيح التوقيع والشهادات لك وتبقى لك، لأن فقدانها من الأخطاء القليلة الموجعة فعلًا في الجوّال.

لماذا تُرفَض التطبيقات

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

قبل الإنتاج

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

الإشعارات الفورية

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

العمل دون اتصال

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

الروابط العميقة

الرابط في بريد أو إعلان يجب أن يفتح الشاشة الصحيحة داخل التطبيق حين يكون مثبَّتًا، وصفحة ويب حين لا يكون. وهذا يتطلب Universal Links على iOS وApp Links على Android: ملف ارتباط يُقدَّم من نطاقك ويتحقق منه النظام، إضافةً إلى توجيه داخل التطبيق يصمد أمام البدء البارد. وهو عمل دقيق ويستحق أن يُنجَز كما ينبغي، لأنه الفرق بين حملة تُحوِّل وحملة تُلقي بالناس على شاشة رئيسية.

التطبيق عميل. وكل ما يعرضه تقريبًا يأتي من مكان ما، وذلك المكان جزء من المشروع حتى حين لا يذكر الطلب سوى الشاشات.

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

نبني الخلفية أيضًا — عادةً بـ Next.js وPostgreSQL — أو نتكامل مع ما تشغّله بالفعل. وفي الحالتين لا يكون التطبيق أفضل مما يقف خلفه، والتقدير الذي يتجاهل الخادم ليس تقديرًا.

تباعُد الإصدارات

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

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

• تشترط Apple أن تُبنى الإرسالات الجديدة على SDK حديث، فيحتاج الإصدار إلى Xcode حالي وما يرافقه من تغييرات النظام.
• تشترط Google Play أن تستهدف التطبيقات مستوى API حديثًا يُحدَّث سنويًا، وإلا توقّف قبول التحديثات.
• كل إصدار نظام يغيّر شيئًا ظاهرًا: الأذونات، والتنفيذ في الخلفية، وسلوك الإشعارات، ونوافذ الخصوصية، والتخطيط عند حواف الأجهزة الجديدة.
• الشهادات وملفات التزويد ومفاتيح الإشعارات تنتهي وفق جدولها الخاص، في لحظة غير مناسبة عادةً.
• الاعتماديات تتحرك من تحتك، ووحدة أصلية واحدة مهجورة قد تعطّل ترقية كاملة.

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

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

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