Flutter أم React Native؟ أفضل تقنية لبرمجة التطبيقات 2026

«Flutter أم React Native؟» هو السؤال الذي يسبق كل الأسئلة حين يقرر صاحب شركة في القاهرة أو الرياض بناء تطبيق. عادةً يكون قد قرأ مقالتين متحمستين: واحدة تقول إن فلاتر هو المستقبل، وأخرى تقول إن رياكت نيتف هو الخيار الآمن. والحقيقة التي يعرفها أي فريق بنى بالتقنيتين أن الاثنتين ناضجتان اليوم إلى الحد الذي يجعل مستخدمك غير قادر على معرفة أيهما استُخدم في تطبيقك.

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

في جاد للتطوير الرقمي (Jad Digital) نبني تطبيقات عملائنا بالتقنيتين منذ سنوات، ونكتب التوصية وأسبابها داخل العرض قبل أول سطر كود. ما يلي هو المعيار الفعلي الذي نستخدمه، محدّثاً بما تغيّر في 2025 و2026 — لأن كثيراً مما يُتداول عن «الجسر البطيء» و«حجم التطبيق الضخم» صار كلاماً عن نسخ لم تعد موجودة.

بناء تطبيق أصلي منفصل لكل منصة يعني فريقين وقاعدتي كود وضعف زمن كل ميزة وضعف الاختبار — ثمن مرتفع مقابل مكسب لن يلاحظه المستخدم. تقنيات الكود الواحد تنتج تطبيقاً للمنصتين من مصدر واحد بجودة قريبة جداً من الأصلية، ولهذا تُبنى بها اليوم معظم تطبيقات الأعمال: المتاجر والحجوزات والتوصيل والتطبيقات الداخلية للموظفين والمندوبين. الفارق الحقيقي في التكلفة يظهر بين «كود واحد» و«كودين»، لا بين Flutter وReact Native.

وإن كنت لم تحسم بعد هل تحتاج تطبيقاً أصلاً أم موقعاً متجاوباً يكفيك الآن، فابدأ من تطبيق ولا موقع؟ — أسوأ تطبيق هو الذي بُني قبل أن يثبت أن الناس تحتاجه.

الفارق بينهما ليس ذوقاً؛ إنه في طريقة رسم الشاشة، ومنه تتفرع معظم المفاضلات الأخرى.

React Native تكتب واجهاتها بلغة JavaScript أو TypeScript، ثم تطلب من نظام التشغيل رسم مكوناته الأصلية: زر الأندرويد زر أندرويد حقيقي، وقائمة iOS قائمة iOS حقيقية. الانتقاد التاريخي كان أن التواصل بين كود الجافاسكريبت والمكونات الأصلية يمر عبر «جسر» يرسل رسائل غير متزامنة، فيظهر تأخر في الشاشات الثقيلة.

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

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

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

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

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

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

حيث يوجد فارق حقيقي فهو في طرفين: الأنيميشن المعقد والرسومات المرسومة يدوياً (مخططات، خرائط حرارية، تجارب بصرية غير تقليدية) حيث يتفوق Flutter؛ والشاشات التي تعتمد بكثافة على مكونات أصلية ثقيلة كالخرائط التفاعلية والفيديو حيث يكون React Native أكثر مباشرة لأنه يستخدم المكون الأصلي نفسه.

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

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

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

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

السؤال هنا عملي: هل ما يحتاجه تطبيقك متاح جاهزاً للتقنية التي ستختارها؟

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

• بوابات الدفع: Paymob وFawry في مصر، ومدى وApple Pay وحلول التقسيط مثل Tabby وTamara في السعودية، تعمل عبر واجهات برمجية وصفحات دفع مستضافة تعمل مع أي تقنية؛ بعضها يوفر حزمة أصلية تحتاج غلافاً رقيقاً. اسأل الفريق: هل ربطتم هذه البوابة تحديداً من قبل، وفي أي تطبيق منشور؟
• الخرائط والتتبع: خرائط جوجل ومكتبات التتبع الحي متاحة للاثنتين بجودة عالية. وحين تكون الخريطة التفاعلية معروضة طوال اليوم (توصيل، مندوبون، نقل) يميل الترجيح قليلاً لـ React Native لأنه يعرض مكون الخريطة الأصلي مباشرة.
• الإشعارات: البنية نفسها من جوجل وأبل، والدعم متكافئ — بما فيه الإشعارات الغنية والصامتة والمجدولة.
• الأجهزة الطرفية: قارئات الباركود وطابعات الإيصالات عبر البلوتوث وقارئات NFC متاحة للاثنتين، لكن جودة الحزم تتفاوت حسب الجهاز. إن اعتمد تطبيقك على جهاز معين فاطلب اختباراً عملياً عليه قبل التعاقد.
• الامتثال والفوترة: الربط بالفوترة الإلكترونية في مصر أو السعودية يحدث في الباك إند لا في التطبيق، فلا علاقة له بهذا الاختيار.

عامل يتجاهله كثيرون وأثره كبير على المدى الطويل. React Native تُكتب بلغة الويب نفسها، وسوق مطوري الجافاسكريبت في مصر ضخم، فاستبدال مطور أو تسليم المشروع لفريق آخر بعد سنتين أسهل وأسرع. Flutter ينمو بسرعة في مصر والسعودية ومجتمعه نشط، لكن السوق أصغر — أي وقت أطول في التوظيف أحياناً.

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

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

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

رغم أننا نبني معظم المشاريع بكود واحد، هناك حالات نقول فيها بصراحة إن الأصلي هو الصحيح:

وحتى هنا الحل نادراً ما يكون «كل شيء أصلي»: يمكن بناء الشاشة الحرجة وحدها كوحدة أصلية داخل تطبيق بكود واحد — نمط نستخدمه حين تكون ميزة واحدة هي الاستثناء.

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

• لديك موقع أو منصة ويب بتقنيات حديثة، أو تخطط لها: أفضلية لـ React Native.
• الواجهة البصرية الغنية والأنيميشن المعقد هما قلب المنتج: أفضلية لـ Flutter.
• هوية بصرية واحدة صارمة يجب أن تبدو متطابقة على كل جهاز: أفضلية لـ Flutter.
• تريد تطبيقاً يبدو ويتصرف كابن المنصة على iOS وAndroid: أفضلية لـ React Native.
• خريطة تفاعلية أو فيديو أصلي في قلب التجربة: أفضلية طفيفة لـ React Native.
• ستبني فريقاً داخلياً في مصر خلال عامين: أفضلية لـ React Native لسعة سوق التوظيف.
• الأولوية لثبات الأداء على أجهزة أندرويد متواضعة: أفضلية طفيفة لـ Flutter.
• حجم التنزيل حرج لجمهورك: أفضلية طفيفة لـ React Native.
• دعم العربية وRTL: متعادل — الفارق في الفريق لا التقنية.
• التكلفة والمدة: متعادل عملياً؛ من يعدك بتوفير كبير لمجرد تغيير التقنية يبيعك وهماً.

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

اخترنا React Native: المطورون أنفسهم عملوا على المنصتين، وأُعيد استخدام جزء من منطق السلة والطلبات، وصدرت إصلاحات سريعة في موسم العروض دون مراجعة متجر في كل مرة. القرار هنا كان تنظيمياً لا تقنياً — وهو غالباً الاعتبار الأهم.

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

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

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

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

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

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

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

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

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