Flutter أم React Native في 2026: مقارنة بالإصدارات والأرقام

السؤال المعتاد هو «أيهما أفضل؟»، والإجابة الصادقة أن الإطارين ينتجان تطبيقات إنتاجية ناضجة على iOS وأندرويد، وأن الفرق الذي يظهر في الميزانية لا يقع في جودة الواجهة بل في أربعة أمور: وتيرة الإصدارات، ومدة دعم كل إصدار، والحد الأدنى للأدوات التي يفرضها كل إطار على جهاز المطور وعلى خادم البناء، وما تعرفه شركتك أصلاً.

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

أين يقف كل إطار اليوم

أرقام Flutter من بيان الإصدارات الرسمي وصفحة ما الجديد، وأرقام React Native من صفحة الإصدارات على GitHub ومدونة المشروع.

الوتيرة ليست تفصيلاً هندسياً. إصدارات Flutter الرئيسية تنزل كل ثلاثة أشهر تقريباً: 3.35 في أغسطس 2025، ثم 3.38 في نوفمبر 2025، ثم 3.41 في فبراير 2026، ثم 3.44 في مايو 2026، ثم 3.47 في أغسطس 2026. أما React Native فتنزل إصداراته كل شهرين تقريباً: 0.82 في أكتوبر 2025، و0.83 في ديسمبر 2025، و0.84 في فبراير 2026، و0.85 في أبريل 2026، و0.86 في يونيو 2026، و0.87 في أغسطس 2026.

نافذة الدعم: الرقم الذي يحدد ميزانية الصيانة

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

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

البنية التقنية: ما الذي تغيّر فعلاً في الإطارين

Flutter: محرك Impeller

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

من ناحية التوفّر: Impeller هو محرك العرض الوحيد المدعوم على iOS، ولا توجد إمكانية للعودة إلى Skia. وعلى أندرويد يعمل افتراضياً على واجهة برمجة التطبيقات 29 فما فوق، مع بديل على الأجهزة الأقدم أو التي لا تدعم Vulkan. عملياً، أي جهاز أندرويد يدعم Vulkan يحصل على المسار الحديث، والأجهزة الأقدم تحصل على المسار الاحتياطي، وهي شريحة لا يمكن تجاهلها في السوق المصري.

React Native: نهاية البنية القديمة

هنا التغيير الأكبر، والأكثر أثراً على تطبيق قائم:

• في الإصدار 0.76 بتاريخ 23 أكتوبر 2024 أصبحت البنية الجديدة هي الافتراضية.
• في الإصدار 0.82 بتاريخ 8 أكتوبر 2025 أصبحت البنية الوحيدة. محاولة تعطيلها عبر newArchEnabled على أندرويد أو RCT_NEW_ARCH_ENABLED على iOS تُتجاهل، والتطبيق يعمل بالبنية الجديدة على أي حال. وتذكر المدونة صراحةً أن الإصدار 0.81 وExpo SDK 54 هما آخر إصدارين يسمحان بالبنية القديمة.
• في الإصدار 0.84 بتاريخ 11 فبراير 2026 صار Hermes V1 المحرك الافتراضي، وتوقّف تضمين شيفرة البنية القديمة في بناءات iOS افتراضياً، وهو ما يقلّل زمن البناء وحجم التطبيق.

ماذا يعني ذلك لصاحب تطبيق React Native مكتوب قبل 2024؟ الترقية ليست رفع رقم إصدار في ملف. إذا كان التطبيق ما زال على البنية القديمة، فالمسار الموصى به رسمياً هو الانتقال أولاً إلى 0.81 أو Expo SDK 54، ثم الهجرة إلى البنية الجديدة قبل تجاوز 0.82. هذا مشروع له تقدير وقت وتكلفة، ويستحق أن يُطرح صراحةً في أي عرض سعر للصيانة.

وأضاف الإصدار 0.87 تغييراً آخر يمس الفرق التقنية: واجهة TypeScript الصارمة صارت الافتراضية، والاستيراد العميق من المسارات الداخلية صار خطأً في الأنواع يستوجب الترحيل.

الأداء: ما الذي يمكن قوله بأمانة

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

• Flutter يراهن على قابلية التنبؤ. تصريف الشيدرات مسبقاً يلغي فئة كاملة من التقطيع الذي كان يظهر عند أول ظهور لتأثير بصري جديد.
• React Native بعد البنية الجديدة يتيح قياس التخطيط بشكل متزامن وجدولة التحديثات بحيث لا تظهر حالة وسيطة للمستخدم. مثال التوثيق نفسه هو تلميح يُحسب موضعه ثم يقفز بصرياً إلى مكانه الصحيح في البنية القديمة.

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

حجم التطبيق: لماذا لا تنطبق الأرقام المتداولة على مشروعك

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

والأهم أن دليل قياس الحجم يوضّح أن البناء الذي ينتج عن أمر البناء الافتراضي هو حزمة رفع للمتجر، لا حجم التنزيل عند المستخدم؛ فالمتاجر تعيد معالجة الحزمة وتقسّمها حسب كثافة شاشة الجهاز ومعمارية المعالج.

الطريقة الصحيحة للقياس:

1. على أندرويد: ابنِ حزمة التطبيق، ارفعها إلى Google Play Console، ثم اقرأ حجمي التنزيل والتثبيت من تبويب حجم التطبيق في Android vitals.
2. على iOS: أنشئ تقرير حجم التطبيق من Xcode، واقرأ ملف تقرير التخفيف الذي يعطيك الحجم المتوقع على طرازات وإصدارات مختلفة.
3. على الجانب الآخر، قلّل الأصول قبل أن تلوم الإطار: خط عربي واحد بأوزان متعددة قد يكلّف أكثر مما يكلّفه محرك العرض.

وفي React Native، التغيير الموثّق الذي يخفّض الحجم هو إزالة شيفرة البنية القديمة من بناءات iOS ابتداءً من 0.84.

متطلبات الأدوات: تكلفة تظهر في جهاز المطور وخادم البناء

هذا البند يُنسى في المقارنات وهو الذي يعطّل فريقاً لأسبوع.

مصادر الجدول: منصات Flutter المدعومة وجدول الاعتماديات الخارجية لإصدارات React Native.

اشتراط Xcode 26 يعني جهاز Mac بنظام يدعمه، ويعني تحديث صورة خادم البناء في CI. ولو كان فريقك يعمل من الرياض أو القاهرة على أجهزة مشتركة، فهذا بند شراء لا بند إعداد.

البدء الموصى به رسمياً

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

في المقابل، Flutter يأتي بمجموعة أدواته كاملة من البداية، وأضاف الإصدار 3.47 أداة معاينة الودجات إلى القناة المستقرة، ووسّع توثيق Swift Package Manager لـ iOS وmacOS.

الفريق والتوظيف: العامل الذي يحسم أغلب الحالات

بعيداً عن التفاصيل التقنية، هناك سؤال يحسم القرار في أغلب الشركات: ما الذي يعرفه فريقك اليوم؟

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

Flutter يطلب Dart، وهي لغة يتعلمها المطوّر خصيصاً لهذا الإطار. التكلفة تُدفع مرة واحدة في بداية المشروع، ومقابلها سطح تقني واحد ومتّسق: الأداة والمحرك والمكتبات الأساسية كلها من جهة واحدة، ما يقلّل قرارات الاختيار بين بدائل مجتمعية.

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

ما وراء الموبايل

إذا كان في الخطة لوحة تحكم أو نسخة سطح مكتب، فالفرق يتسع. منصات Flutter المدعومة تشمل إلى جانب iOS وأندرويد: Windows وmacOS وLinux والويب، بالشيفرة نفسها. React Native يركّز على iOS وأندرويد، ويُوسَّع إلى منصات أخرى عبر تنفيذات خارج الشجرة الأساسية يصونها أطراف أخرى.

هذا لا يعني أن Flutter الخيار الصحيح لكل مشروع متعدد المنصات؛ لوحة تحكم إدارية تُبنى عادةً بتقنيات الويب المعتادة بشكل أفضل، كما نوضّح في المقارنة بين React وLaravel. لكنه يعني أن وجود سطح مكتب في خارطة الطريق عامل يستحق أن يدخل القرار مبكراً.

متى تختار كل واحد

اختر Flutter إذا:

• كانت هوية التطبيق البصرية مخصصة وتريد تطابقاً بصرياً بين المنصتين، لأن المحرك يرسم العناصر بنفسه بدل استدعاء مكونات النظام.
• كنت تفضّل وتيرة تحديث أهدأ وسطح أدوات واحد تحت مظلة واحدة.
• كان الفريق يبدأ من الصفر، فتعلّم Dart تكلفة تُدفع مرة واحدة.

اختر React Native إذا:

• كان لديك فريق ويب يتقن React وTypeScript، فالانتقال إلى الموبايل لا يتطلب لغة جديدة.
• كنت تريد سلوكاً أقرب إلى مكونات النظام في كل منصة، لأن الإطار يترجم المكونات إلى عناصر واجهة أصلية.
• كان لديك بالفعل تطبيق React Native، فالاستمرار مع خطة ترقية أرخص من إعادة الكتابة.

فكّر جدياً قبل الالتزام بـ React Native إذا كانت شركتك بلا فريق تقني داخلي وبلا خطة صيانة سنوية، لأن وتيرة الإصدارات ونافذة الدعم تفترض تحديثاً دورياً.

وماذا عن تطبيق قائم بالفعل؟

إذا كان عندك تطبيق React Native على إصدار أقدم من 0.82 وما زال على البنية القديمة، فالخطوات بالترتيب: ثبّت الوضع على 0.81 أو Expo SDK 54، هاجر إلى البنية الجديدة وأصلح المكتبات غير المتوافقة، ثم اصعد إصداراً إصداراً. القفز مباشرة إلى 0.87 يجمع عليك هجرة البنية وهجرة واجهة TypeScript الصارمة في وقت واحد.

وإذا كان التطبيق على Flutter، فالترقية بين الإصدارات الرئيسية أهدأ عادةً، لكن راجع صفحة التغييرات الكاسرة لكل إصدار قبل الترقية.

اختيار الإطار المناسب وتقدير تكلفة الهجرة من بنية قديمة جزء من خدمات برمجة تطبيقات الموبايل في سنابل. وإذا كنت ما زلت متردداً بين التطوير المتعدد المنصات والتطوير الأصيل من الأساس، فابدأ من مقارنة Native وCross-Platform.

قبل أن تلتزم بإطار، اعرض متطلبات تطبيقك على فريق سنابل. سنعود إليك في غضون 24 ساعة بترشيح تقني مسبَّب وتقدير أولي للمدة والميزانية، بلا مقابل وبلا أي التزام.

أسئلة شائعة

ما أحدث إصدار مستقر من Flutter و React Native؟

حتى 19 سبتمبر 2026، أحدث إصدار مستقر من Flutter هو 3.47.5 الصادر في 18 سبتمبر 2026، ضمن سلسلة 3.47 التي أُطلقت في 12 أغسطس 2026. وأحدث إصدار مستقر من React Native هو 0.87.1 الصادر في 26 أغسطس 2026، بينما كان 0.88 ما زال في مرحلة المرشّح للإصدار.

أي الإطارين ينتج تطبيقاً أصغر حجماً؟

لا توجد إجابة ثابتة تصلح لكل مشروع. كلا الإطارين يضيف زمن تشغيل خاصاً به، لكن معظم حجم التطبيق يأتي من الصور والخطوط والحزم الخارجية التي تضيفها أنت. قِس مشروعك بنفسك: على أندرويد من تبويب حجم التطبيق في Google Play Console بعد رفع حزمة التطبيق، وعلى iOS من تقرير حجم التطبيق في Xcode.

عندي تطبيق React Native قديم، هل أرقّيه أم أعيد بناءه؟

ابدأ بمعرفة إصداره وهل يعمل بالبنية القديمة. اعتباراً من 0.82 لم تعد البنية القديمة مدعومة إطلاقاً، والمسار الموصى به رسمياً هو التثبيت على 0.81 أو Expo SDK 54، ثم الهجرة إلى البنية الجديدة، ثم الصعود تدريجياً. في أغلب الحالات تظل هذه الهجرة أقل تكلفة من إعادة الكتابة من الصفر.

هل يلاحظ المستخدم فرقاً في الأداء بين الإطارين؟

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

المصادر

• بيان إصدارات Flutter وما الجديد وImpeller والأسئلة الشائعة وقياس حجم التطبيق والمنصات المدعومة — توثيق Flutter من Google.
• إصدارات React Native على GitHub وإعلان 0.76 وإعلان 0.82 وإعلان 0.84 وإعلان 0.87 والبنية الجديدة ودليل البدء — توثيق React Native من Meta.
• سياسة دعم الإصدارات — مجموعة عمل إصدارات React Native.

جميع الروابط رُوجعت في 19 سبتمبر 2026.