ما الذي يقدّمه التطوير الأصلي إلى اليوم
بناء تطبيقين منفصلين، واحد بـ Swift لـ iOS وآخر بـ Kotlin لأندرويد، يبقى الخيار الأضمن حين يعيش التطبيق على العتاد: معالجة الفيديو، والواقع المعزَّز، والمستشعرات عالية التردّد، أو التكامل العميق مع النظام كالأدوات المتقدّمة والامتدادات.
ويحتفظ الأصلي أيضًا بأفضلية اليوم صفر: فحين تطلق آبل أو غوغل قدرة نظام جديدة، تكون متاحة فورًا، بينما على إطار متعدّد المنصّات أن ينقلها أوّلًا.
وثمن هذا الأمان آليّ: قاعدتا شيفرة، وكفاءتان تُوظَّفان، وكلّ وظيفة تُكتب ثمّ تُختبر مرّتين. وعمليًّا، احسب الضعف تقريبًا.
ما الذي يغيّره Flutter
يترجم Flutter قاعدة شيفرة واحدة إلى iOS وأندرويد، ويرسم واجهته بنفسه بدل قيادة مكوّنات النظام. وهذا يفسّر قوّته وحدّه معًا: العرض متطابق في كلّ مكان وسلس، لكنّ التطبيق يبدو أقلّ التصاقًا بروح النظام.
وبالنسبة للغالبية العظمى من التطبيقات المهنية، هذه مقايضة جيّدة. فالكتالوج، ومساحة الزبون، وأخذ الطلبات، وتتبّع التوصيل، والأداة الداخلية: كلّها تُبنى مرّة وتخرج إلى المتجرين.
والمكسب الحقيقي ليس الكلفة الأولية فقط، بل الصيانة. فالإصلاح يُكتب مرّة واحدة. أمّا على تطبيقين أصليين فيُكتب مرّتين، ويُختبر مرّتين، وينفصل أحدهما عن الآخر عاجلًا أو آجلًا.
الخيار المنسيّ: تطبيق الويب القابل للتثبيت
قبل الالتزام بتطبيق، اسأل هل تحتاجه أصلًا. فتطبيق الويب الحديث يُثبَّت على الشاشة الرئيسية، ويعمل دون اتّصال، ويرسل إشعارات على أندرويد، ويُحدَّث دون انتظار مراجعة متجر.
وهو يتفادى مصدرَي احتكاك كبيرين: التحميل، الذي يفقدك حصّة معتبرة من المستخدمين، ومراجعة المتاجر، التي تضيف أيّامًا إلى كلّ إصلاح. كما أنّه أقلّ كلفة بوضوح، لأنّه العمل نفسه الذي يتطلّبه موقع.
وحدوده حقيقية: الإشعارات تبقى مقيَّدة على iOS، والولوج إلى العتاد أضيق، ولا تظهر في المتاجر، وهو ما يهمّ إن كان الاكتشاف يمرّ منها. لكن بالنسبة لأداة يستعملها زبائن يأتون أصلًا من موقعك، يبقى الجواب الأعقل غالبًا.
المعيار الذي يحسم
اطرح الأسئلة بهذا الترتيب. هل يحتاج التطبيق عتاد الهاتف إلى ما هو أبعد من الكاميرا والموقع؟ إن كان الجواب نعم، فالأصلي. وإلّا، فهل المتاجر قناة اكتساب حقيقية لك؟ إن كان الجواب لا، فتطبيق ويب قابل للتثبيت يكفي على الأرجح.
وإن كنت تحتاج المتاجر دون العتاد المتقدّم، فـ Flutter هو نقطة التوازن: قاعدة شيفرة واحدة، ومتجران، وكلفة قريبة من كلفة تطبيق أصلي واحد.
ولا تختر بناءً على سمعة إطار عمل. اختر بناءً على هذه الأسئلة الثلاثة، بهذا الترتيب، والجواب سيكون تقريبًا دائمًا هو نفسه الذي يعطيك إيّاه مطوّر صادق.
المقارنة
| المعيار | Flutter | أصلي (iOS وأندرويد) |
|---|---|---|
| قواعد الشيفرة المصانة | واحدة | اثنتان |
| الكلفة النسبية | المرجع | الضعف تقريبًا |
| الولوج إلى العتاد المتقدّم | جيّد، عبر جسور | كامل وفوري |
| مستجدّات النظام | متاحة بعد النقل | متاحة يوم الإطلاق |
| التطابق بين النظامين | متطابق بالبناء | يُصان يدويًّا |
| الحضور في المتاجر | نعم | نعم |
| إصلاح خلل | يُكتب مرّة | يُكتب ويُختبر مرّتين |
الخلاصة
اختر الأصلي إن كان التطبيق يعيش على العتاد أو وجب عليه تبنّي مستجدّات النظام فورًا. واقبل الكلفة المضاعفة، فهي بنيوية.
واختر Flutter لكلّ التطبيقات المهنية تقريبًا التي يجب أن توجد في المتجرين. فهو أفضل توازن بين الكلفة والمدّة والجودة المدرَكة.
وفكّر جدّيًّا في تطبيق الويب القابل للتثبيت قبلهما. فلأداة موجَّهة إلى مستخدمين يعرفونك أصلًا، يخرج أسرع، ويكلّف أقلّ، ويُصلَح دون انتظار مراجعة.