خارطة طريق تطوير تطبيقات الموبايل: Flutter أم React Native؟

معظم من يقتربون من تطوير الموبايل يبدأون بالسؤال الخاطئ. يسألون هل يتعلّمون Flutter أم React Native، وكأن الإجابة تحدّد كل ما يليها. وهي لا تفعل. فإطار العمل يحدّد صياغتك ومنظومتك؛ ولا يحدّد ما إذا كان تطبيقك يعالج انقطاع الاتصال بلطف، أو يستمر في العمل عند انتهاء صلاحية رمز، أو ينجو من المراجعة في متجر التطبيقات.

لذا يغطّي هذا المقال الأرضية المشتركة أولاً، ويتعامل مع اختيار إطار العمل باعتباره ما هو عليه فعلاً: قرار يعتمد على خلفيتك ومنتجك.

ما الذي يجعل الموبايل مختلفاً

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

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

الأساسيات التي يحتاجها كل تطبيق موبايل

تنطبق هذه بشكل متطابق في Flutter و React Native. وهي ما ستقضي وقتك فيه فعلاً.

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

‏Flutter

يستخدم Flutter لغة Dart، وهي لغة يجدها معظم الناس سريعة الالتقاط، خصوصاً القادمين من Java أو C#‎ أو JavaScript. وخاصيته المميّزة أنه يرسم عناصر واجهته بنفسه بدلاً من تفويض ذلك لمكوّنات المنصة الأصلية. والنتيجة العملية أن الشاشة تميل إلى أن تبدو وتتصرّف بالطريقة نفسها على المنصّتين، وهو أمر قيّم حين يهمّك الاتّساق البصري.

والمسار هو أساسيات Dart، ثم نموذج عناصر الواجهة والفرق بين عناصر بلا حالة وأخرى بحالة، ثم التخطيط، والتنقّل، وإدارة الحالة بحزمة مثل Provider أو Riverpod أو Bloc، ثم الشبكات، والتخزين المحلي، وعملية البناء والإصدار الخاصة بكل منصة.

‏React Native

يستخدم React Native لغة JavaScript أو TypeScript مع React، ويعرض مكوّنات أصلية فعلية. وإن كنت تعرف React أصلاً، فمعظم معرفتك تنتقل مباشرة — المكوّنات و props والحالة والخطّافات تعمل كما تتوقّع، وأنت تتعلّم أساساً عناصر أولية جديدة واهتمامات خاصة بالموبايل.

وهذا الانتقال هو أقوى حجّة منفردة له. فالمطوّر الذي يعرف React يمكن أن يصبح منتجاً في React Native في جزء من الوقت الذي يستغرقه تعلّم Dart و Flutter من الصفر، ويستطيع الفريق مشاركة الأنواع ومنطق التحقّق والأدوات المساعدة بين تطبيق ويب وتطبيق موبايل.

الاختيار بينهما

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

• قادم من React أو فريق JavaScript — React Native هو الطريق الأقصر والأرخص.
• تبدأ من الصفر بلا خلفية ويب — Flutter مكان متماسك ومكتفٍ بذاته للتعلّم.
• واجهة مخصّصة جداً يجب أن تبدو متطابقة في كل مكان — عرض Flutter الخاص يساعد.
• مشاركة الشيفرة والأنواع مع منتج ويب قائم — React Native يناسب بشكل طبيعي.
• فريق قائم بقيود توظيف — الإجابة الصادقة عادةً هي ما يعرفونه بالفعل.

ويستحق أن تعرف أيضاً أن التطوير الأصلي — Kotlin لأندرويد و Swift لـ iOS — يبقى الجواب الصحيح لبعض المنتجات: التكامل العميق مع المنصة، أو الرسوميات المتطلّبة أو الوصول للعتاد، أو منتج لمنصة واحدة لا يشتري فيه العمل عبر المنصات شيئاً.

النشر إلى المتاجر

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

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