اختيار التكنولوجيا اللي هيتبني بيها أول أبلكيشن لشركتك قرار بيزنس قبل ما يكون قرار برمجة. الاختيار الغلط مش بيبان يوم الإطلاق. بيبان بعد سنة ونص، لما التوظيف يبقى صعب، أو ميزة بسيطة تاخد ٣ أضعاف الوقت اللي اتقال لك، أو الأبلكيشن يحتاج يتعاد من الأول لأن التكنولوجيا الأولانية مش قادرة تعمل اللي المنتج محتاجه دلوقتي. المقال ده بيقارن بين React Native وFlutter والتطوير الـ Native الكامل (Swift لـ iOS وKotlin لـ Android) لشركة بتبني أول أبلكيشن، وبيديك طريقة قرار تقدر تطبقها على مشروعك.

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

إيه الفرق الحقيقي بين الاختيارات التلاتة؟

الفرق الأساسي في حاجتين: الواجهة بتترسم فين، والكود بتاع المنطق مكتوب بأنهي لغة.

Native (Swift وKotlin): كودين منفصلين، كل واحد بيستخدم أدوات الواجهة الأصلية للنظام ولغته. بتاخد كل ميزة جديدة في النظام من أول يوم وسلوك مضمون، لكن بتبني وتصين كل حاجة مرتين.
React Native: كود واحد بـ JavaScript أو TypeScript بيعرض عناصر واجهة أصلية حقيقية. الزرار على iPhone زرار iPhone حقيقي، وعلى Android زرار Android حقيقي.
Flutter: كود واحد بلغة Dart بيرسم كل بكسل بنفسه. Flutter مش بيستخدم أزرار النظام ولا قوايمه. بييجي بمجموعة عناصره ومحرك الرسم بتاعه جوه الأبلكيشن.

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

React Native النهارده بيشتغل إزاي؟

React Native بيخلي الفريق يكتب منطق الواجهة بـ TypeScript باستخدام React، وبعدين يحوله لعناصر أصلية. مقالات كتير قديمة بتتكلم عن “جسر” بطيء بين JavaScript والكود الأصلي. الكلام ده قديم. حسب فريق React Native نفسه، المعمارية الجديدة (New Architecture) مفعلة افتراضيا من إصدار 0.76 (أكتوبر ٢٠٢٤). أهم أجزائها:

JSI: بيخلي JavaScript والكود الأصلي يتكلموا مع بعض مباشرة من غير الجسر القديم اللي بيبعت رسائل بشكل غير متزامن.
المحرك الجديد للعرض (Fabric): مكتوب بـ C++ ومشترك بين المنصات. بيحتفظ بالواجهة في شجرة ثابتة، وده بيسمح بترتيب الأولويات: تحديث عاجل زي الكتابة في حقل مش هيتعطل بسبب عرض تقيل.
نظام الموديولات الأصلية الجديد (TurboModules): موديولات أصلية بعقود واضحة بتتولد تلقائيا من Codegen، وبتتحمل وقت الحاجة بس، وبتدعم النداء المباشر في الحالات اللي بتنفع.
ميزات React المتوازية: زي Suspense وtransitions، وده بيساعد الواجهة تفضل سريعة الاستجابة على موبايلات الفئة المتوسطة.

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

React Native بيناسب مين؟

الشركات اللي عندها فريق ويب بيعرف React، لأن المهارات بتنتقل ونفس المطورين يقدروا يشتغلوا على الويب والموبايل.
الأبلكيشنات اللي شاشاتها أغلبها فورمات وقوايم وصفحات تفاصيل ولوحات متابعة وتنقل عادي، وده أغلب أبلكيشنات الشركات.
المنتجات اللي عايزة إحساس أصلي على iOS وAndroid من غير فريقين منفصلين.
الشركات اللي عندها منصة ويب وعايزة تشارك قواعد التحقق وعملاء الـ API والأنواع والمنطق بين الموقع والأبلكيشن.

React Native بيتعب فين؟

الأبلكيشنات اللي مبنية على رسومات مخصصة جدا أو تفاعل شبه الألعاب، لأنك هتبقى بتحارب نظام العرض بدل ما تستخدمه.
المشاريع اللي بتعتمد على SDK أصلي ضيق ملوش غلاف React Native متصان. تقدر تكتب الغلاف بنفسك، لكن ده شغل Native والجدول لازم يحسبه.
الفرق اللي مفيهاش حد يقدر يقرا كود Native. لما البيلد يفشل جوه Xcode أو Gradle لازم حد يعرف يشخص المشكلة.

Flutter النهارده بيشتغل إزاي؟

توثيق Flutter الرسمي بيشرح معمارية من تلات طبقات: Embedder خاص بكل منصة، ومحرك بـ C++، وإطار عمل بلغة Dart فوقهم. إطار العمل فيه العناصر والحركة واللمس وأنظمة التصميم Material وCupertino. ولأن Flutter بيرسم واجهته بنفسه، المشهد بيتركب بنفس الطريقة بغض النظر عن أدوات الواجهة في النظام.

وده اللي بيترتب على كده حسب التوثيق الرسمي:

الثبات: الواجهة بتبان وتتصرف بنفس الشكل على إصدارات النظام المختلفة، لأنها مش معتمدة على عناصر المنصة. مفاجآت أقل بعد تحديثات iOS وAndroid.
محرك رسم خاص: Flutter بيستخدم Impeller، وهو بيجهز مجموعة أصغر من الـ shaders وقت بناء المحرك فمبيتعملهاش compile وقت التشغيل. Impeller هو الافتراضي على iOS وعلى أجهزة Android بإصدار API رقم ٢٩ فما فوق، مع رجوع تلقائي للأجهزة الأقدم. نسخة الويب لسه بتستخدم Skia. الهدف المعلن هو أداء متوقع.
طريقة التجميع: وقت التطوير الأبلكيشن بيشتغل في VM بيدعم hot reload مع الحفاظ على الحالة. وقت الإصدار، Dart بيتحول مباشرة لكود آلة أصلي (أو لـ JavaScript أو WebAssembly للويب).
الوصول للنظام عن طريق platform channels: لنداء كود المنصة، Flutter بيبعت رسائل عبر قناة ليها اسم. ولواجهات C، dart:ffi بيربط مباشرة من غير تحويل، بس مش متاح على الويب.
Platform views: تقدر تحط عناصر أصلية حقيقية زي الخريطة جوه Flutter. التوثيق بيقول إن ده ليه تكلفة في المزامنة، فبيناسب عنصر أو اتنين معقدين مش الأبلكيشن كله.
أكتر من موبايل: التوثيق بيذكر Embedders لـ Android وiOS وWindows وmacOS وLinux، إضافة للويب.

Flutter بيناسب مين؟

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

Flutter بيتعب فين؟

لما المنتج لازم يبان زي أبلكيشن iOS أو Android أصلي بالظبط، ويتبنى أي تغيير جديد في تصميم النظام فورا. Flutter لازم يعيد تنفيذ سلوك المنصة في عناصره، فممكن يبقى فيه تأخير.
لما الشركة عندها فريق JavaScript وملهاش خبرة في Dart. Dart سهلة التعلم، لكن التوظيف والتدريب ليهم تكلفة حقيقية، خصوصا إن عدد المطورين أصحاب الخبرة في Flutter في السوق المحلي ممكن يختلف عن عدد مطورين React.
لما جزء كبير من الأبلكيشن محتوى أصلي مدمج، لأن platform views استثناء مش أساس التصميم.

إمتى يبقى Native الكامل هو الاختيار الصح؟

كودين يعني تكلفة أعلى. لكن فيه حالات واضحة التكلفة دي بتتبرر فيها:

تكامل عميق مع الجهاز أو النظام: معالجة في الخلفية، أجهزة Bluetooth، كاميرا متقدمة، حساسات الصحة واللياقة، خدمات إمكانية الوصول، ويدجتس وتطبيقات الساعة. الأدوات متعددة المنصات بتوصل لكتير من ده، لكن أحسن دعم دايما بيظهر في الـ Native الأول.
منتج لمنصة واحدة: لو جمهورك كله على iPhone، زي بعض شرايح الفنادق والعقارات الفاخرة، أبلكيشن iOS أصلي بيشيل سبب استخدام أداة متعددة المنصات.
متطلبات أداء قصوى: صوت أو فيديو لحظي، واقع معزز، أو حسابات تقيلة على الجهاز نفسه.
منتجات طويلة العمر بميزانيات كبيرة لما التميز الخاص بكل منصة هو الميزة التنافسية.

في أول أبلكيشن، Native نادرا ما يكون نقطة البداية الصح إلا لو واحدة من النقط دي بتنطبق عليك. لو مش متأكد، ابني الرحلة الأساسية بأداة متعددة المنصات، وتعامل مع أي ميزة Native فقط كموديول معزول. React Native (عن طريق native modules) وFlutter (عن طريق platform channels أو FFI) متصممين بالظبط عشان يسمحوا بكده.

مقارنة سريعة جنب بعض

عدد الأكواد: Native محتاج اتنين. React Native وFlutter محتاجين واحد لأغلب الميزات.
اللغة: Swift وKotlin للـ Native. TypeScript لـ React Native. Dart لـ Flutter.
طريقة الواجهة: Native بيستخدم عناصر المنصة. React Native بيحول لعناصر المنصة. Flutter بيرسم بنفسه.
الوصول لميزات النظام الجديدة: فوري في Native. في React Native عادة بعد تحديث مكتبة. في Flutter بعد تحديث plugin أو عنصر.
الثبات البصري بين المنصات: الأعلى في Flutter. في React Native وNative الواجهة بتتبع المنصة.
مشاركة الكود مع منصة ويب: الأقوى مع React Native لو الموقع React أو TypeScript. محدود في Native. محدود في Flutter (المشاركة بتتم من خلال عقد الـ API مش من خلال الكود).
مهارات الفريق: Native محتاج فريقين متخصصين. React Native بيستفيد من عالم الويب. Flutter محتاج مهارات Dart.
الصيانة على المدى الطويل: بتعتمد على انضباط المكتبات في الأداتين متعددتي المنصات، وعلى مزامنة كودين في Native.

سبع أسئلة بتحسم القرار

بدل ما تسأل “أنهي فريمورك أحسن”، جاوب على الأسئلة دي عن منتجك. قيم كل واحد وغالبا الإجابة هتبان لوحدها.

١. مين في فريقك، أو مين هتوظف؟

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

٢. الأبلكيشن بيعمل إيه بالظبط؟

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

٣. قد إيه الإحساس الأصلي مهم؟

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

٤. التصميم مخصص قد إيه؟

لو عندك نظام تصميم بلغة حركة خاصة وانتقالات مخصصة وعناصر بهوية قوية، Flutter بيديك تحكم في كل بكسل. ولو التصميم ماشي على عادات iOS وAndroid، React Native أو Native أنسب.

٥. الأبلكيشن جنب منصة ويب؟

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

٦. احتياجات الأوفلاين والمزامنة إيه؟

أبلكيشن بيقرا ويكتب وهو أونلاين بس سهل. أبلكيشن لازم يشتغل في بدروم أو على مركب أو في جناح فندق إشارته ضعيفة ويزامن بعدين محتاج استراتيجية واضحة لحل التعارضات. دي مشكلة تصميم بيانات مش مشكلة فريمورك، وممكن تضاعف جهد المشروع مهما كانت الأداة. قررها بدري واكتبها في الـ brief.

٧. إيه الخطة بعد الإطلاق؟

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

إيه اللي بيحدد تكلفة أول أبلكيشن؟

اختيار الفريمورك بيأثر على التكلفة، لكنه نادرا ما يكون العامل الأكبر. البنود دي بتحرك الميزانية أكتر بكتير:

عدد الشاشات وتعقيدها وحالاتها، بما فيها حالة الفراغ والخطأ والتحميل اللي بتتنسى بسهولة.
تسجيل الدخول وأدوار المستخدمين: إيميل وباسورد، دخول بحسابات اجتماعية، أكواد مؤقتة، وإيه اللي كل دور مسموح له يشوفه.
التكاملات: بوابات الدفع، الخرايط، الرسائل، وربط ERP أو CRM.
شغل التصميم: نظام تصميم مخصص بيكلف أكتر من تعديل عناصر جاهزة.
اللغات وRTL: أبلكيشن عربي وإنجليزي محتاج اختبار حقيقي للاتجاه من اليمين لليسار، مش بس ترجمة النصوص. التواريخ والأرقام والأيقونات اللي بتدل على اتجاه والنصوص المختلطة كلها محتاجة اهتمام.
لوحة التحكم والباك إند: أغلب الأبلكيشنات محتاجة طريقة للموظفين يديروا المحتوى والمستخدمين، ولوحة التحكم دي كتير بتبقى شغل مساوي للأبلكيشن نفسه.
متطلبات المتاجر: إعلانات الخصوصية، مسار حذف الحساب، ودورات المراجعة على المتجرين.
الاختبار على أجهزة حقيقية بمدى واقعي من موبايلات Android، مش بس آخر iPhone.

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

العربي وRTL والسوق المصري

للشركات اللي بتخدم عملاء في مصر، فيه تلات نقط تستاهل سطر خاص في الـ brief.

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

الدفع كمان عامل محلي. بوابات الدفع المحلية بتوثق مسارات التحويل والـ callback على الويب، وفي بعض الحالات SDK للموبايل. قبل ما تختار الفريمورك، اتأكد هل البوابة اللي محتاجها فيها SDK ليه، ولا الدفع عن طريق صفحة ويب جوه الأبلكيشن مقبول لمستخدميك. مسار دفع محتاج حل التفافي أحسن تكتشفه في مرحلة التحليل مش وقت مراجعة المتجر.

اختبار نموذج تجريبي في أسبوع

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

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

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

قرارات معمارية أهم من الفريمورك

أيا كانت الأداة، خمس قرارات معمارية بتحدد هل الأبلكيشن هيبقى مريح في الصيانة.

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

لو شركتك عندها باك إند مخصص، اختيار لارافيل أو أي إطار API تاني منفصل عن اختيار الموبايل. API متصمم كويس بيخدم أبلكيشن React Native وأبلكيشن Flutter وأبلكيشن Native وموقع بنفس الكفاءة، والاستقلالية دي أرخص تأمين تقدر تشتريه.

أخطاء شائعة في أول أبلكيشن

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

توصية عملية حسب الحالة

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

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

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