حين يصل سؤال Native أم Cross-Platform إلى طاولة القرار، يُطرح عادةً بصيغة «أيهما أفضل؟». والصيغة التي توفّر المال غيرها: أي طبقة من تطبيقك يجب أن تُكتب مرتين؟ لأن الفرق بين المسارين لا يقع في جودة التطبيق الذي يصل إلى المستخدم، بل في حجم العمل الذي يتضاعف بين iOS وأندرويد، وفي عدد المواضع التي ستضطر فيها إلى كتابة شيفرة أصلية مهما كان الإطار الذي اخترته.

وهناك سبب يجعل إعادة طرح السؤال ضرورية هذا العام: أغلب ما تقرؤه اليوم عن Native أم Cross-Platform كُتب قبل تغييرات حقيقية جرت في الإطارين الكبيرين، وقبل أن يستقر مسار ثالث لا يظهر في أي منها. هذا الدليل يقارن المسارات الثلاثة بما هو منشور في التوثيق الرسمي حتى 22 سبتمبر 2026، مع التواريخ.

ما الذي تغيّر فعلاً خلال العامين الماضيين

React Native: البنية القديمة مجمّدة لا مهجورة

أهم تغيير في المسار المتعدد خلال عامين هو قرار توقّف. أعلنت مجموعة عمل React Native في 29 مايو 2025 أنها تجمّد البنية القديمة اعتباراً من 2 يونيو 2025: لا تطوير لميزات فيها، ولا قبول لطلبات الدمج التي تمسّها، ولا اختبار لها عند إصدار نسخة جديدة. الاستثناءان الوحيدان هما إصلاحات الأمان وإصلاح عطل يجعل البنية القديمة غير قابلة للاستخدام أصلاً.

البنية الجديدة كانت قد صارت الافتراضية في الإصدار 0.76 في أكتوبر 2024. وحتى 22 سبتمبر 2026، أحدث إصدار مستقر هو 0.87.1، بينما 0.88 ما زال مرشّحاً للإصدار.

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

Flutter: وتيرة معلومة ومحرك يرسم كل شيء بنفسه

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

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

المسار الثالث: مشاركة المنطق وحده

والتغيير الثالث يعيد صياغة السؤال من أساسه. تذكر صفحة Kotlin Multiplatform على موقع مطوّري أندرويد أن Google تتيح رسمياً استخدام KMP لمشاركة منطق العمل بين أندرويد وiOS، وأن المنصة صارت مستقرة وجاهزة للاستخدام في بيئات الإنتاج. وجدول استقرار المنصات المنشور من JetBrains يضع أندرويد وiOS وسطح المكتب والخادم عند مستوى Stable، ويترك watchOS وtvOS والويب عند Beta.

أما الواجهة، فهي اختيار منفصل. تستطيع أن تشارك المنطق فقط وتكتب الواجهة مرتين بـ SwiftUI وJetpack Compose، أو تشارك الواجهة أيضاً عبر Compose Multiplatform، التي صارت مستقرة وجاهزة للإنتاج على iOS مع الإصدار 1.8.0 في مايو 2025، ووصلت إلى الإصدار 1.12.0 الذي يدعم أندرويد 5.0 وiOS 14 فأحدث.

الفرق العملي أن هذا المسار لا يطلب قراراً واحداً نهائياً. تستطيع أن تبدأ بمشاركة طبقة البيانات والتحقق من المدخلات وحسابات الأسعار، وتبقي كل شاشة أصلية، ثم توسّع المشترك لاحقاً إذا نجحت التجربة. وGoogle تدرج مكتبات Jetpack جاهزة لهذا الاستخدام، منها Room وDataStore وLifecycle وViewModel وPaging.

وللأمانة في عرض الأرقام: تذكر JetBrains في إعلان الاستقرار نفسه أن Compose Multiplatform تضيف نحو 9 ميجابايت إلى حجم تطبيق iOS مقارنةً بتطبيق SwiftUI أصلي بالكامل بالواجهة والأصول نفسها، وتسوق تطبيق Respawn مثالاً يشارك 96% من شيفرته بين المنصتين. الرقمان من الجهة الراعية للتقنية وبقياسها هي، فاقرأهما بهذا الاعتبار.

المسارات الثلاثة في صورة واحدة

أصلي بالكاملمتعدد المنصات بالكاملمشاركة المنطق مع واجهة أصلية
الأدواتSwift/SwiftUI و Kotlin/Jetpack ComposeFlutter أو React NativeKotlin Multiplatform، والواجهة أصلية أو Compose Multiplatform
ما يُكتب مرة واحدةلا شيء من جانب العميلالواجهة والمنطق معاًمنطق العمل والبيانات والتحقق
ما يُكتب مرتينكل شيء من جانب العميلما يحتاج واجهات نظام غير مغطّاةكل شاشة، إن اخترت الواجهة الأصلية
متى يستحقالعتاد والخلفية المستمرة وحساسية الأداءالمتاجر والحجوزات والخدمات ولوحات المتابعةتطبيق طويل العمر بقواعد عمل ثقيلة وواجهات مختلفة عمداً
الخطر الأساسيتكلفة مضاعفة وفريقان بخبرتينمكوّن وسيط غير مصان يعطّل ميزةمنظومة أحدث، وخبرة أقل توافراً في السوق المحلي

جدول القرار: تطبيقك من أي نوع؟

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

نوع التطبيقالمسار الأنسبالسبب التقني
متجر إلكتروني أو كتالوجمتعدد المنصاتالعمل كله شبكة وقوائم ونماذج وبوابة دفع؛ لا شيء منها يحتاج واجهة نظام غير مغطّاة
حجز مواعيد أو خدماتمتعدد المنصاتالإشعارات والتقويم والخرائط لها مكوّنات ناضجة ومصانة في الإطارين
توصيل بتتبع مندوبمتعدد المنصات للعميل، وتطبيق المندوب يُقاس على حدةتتبّع الموقع في الخلفية على أندرويد 11 فأحدث لا يُمنح من مربع حوار النظام بل من صفحة الإعدادات، وضبط سلوك الخلفية على المنصتين شغل أصلي في الحالتين
تطبيق بنك أو محفظةأصلي، أو مشاركة منطق مع واجهة أصليةالاعتماد على مخزن المفاتيح والمصادقة الحيوية وكشف التلاعب، وكلها واجهات نظام تتغيّر مع كل إصدار
أداة داخلية للموظفينمتعدد المنصاتالعدد محدود والأجهزة معروفة، والسرعة أهم من التلميع؛ وغالباً يكفيك موقع بدل تطبيق
لعبة أو رسوميات ثقيلةمحرك ألعاب، لا هذا ولا ذاكUnity أو Unreal هو المسار الطبيعي، ومقارنة Flutter بـ Swift هنا خارج الموضوع
صحة ولياقةأصلي، أو مشترك مع وحدات أصليةHealth Connect خاص بأندرويد من الإصدار 28 فأحدث، ونظيره على iOS منفصل تماماً، فالطبقة الصحية تُكتب مرتين على أي حال
واقع معزّزأصليبعض واجهات ARCore فقط متاحة على المنصتين، وتشترط Apple في البند 4.2.1 من إرشادات المراجعة تجربة واقع معزّز غنية ومتكاملة لا مجرد وضع نموذج في مشهد

ما الذي يكسر المسار المتعدد فعلاً

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

توثيق قنوات المنصة في Flutter يقولها صراحة: الشيفرة الخاصة بمنصة بعينها تُكتب بلغة تلك المنصة، أي Kotlin أو Java لأندرويد، وSwift أو Objective-C لـ iOS، وتتبادل الرسائل مع Dart عبر قناة. المبدأ نفسه ينطبق على وحدات React Native الأصلية.

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

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

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

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

ومع المدفوعات داخل التطبيق تشترط Apple في البند 3.1.1 من إرشادات المراجعة استخدام الشراء داخل التطبيق لفتح ميزات أو محتوى داخله، وتمنعه في البند 3.1.3(e) للسلع والخدمات التي تُستهلك خارجه. المكوّنات الجاهزة تغطي عملية الشراء نفسها، لكن التحقق من الإيصالات وحالة الاشتراك على خادمك يبقى نظامين منفصلين.

هل تخطط لبناء أو تطوير مشروع رقمي؟

فريق سنابل يوفر لك دراسة فنية مخصصة لتحديد التقنيات المناسبة وتكلفة التنفيذ الدقيقة.

تواصل عبر واتساباستكشف خدماتنا

وفي الصحة واللياقة والواقع المعزّز، المنظومتان مستقلتان على المنصتين بأنواع بيانات وأذونات ومراجعة مختلفة، ولا تمر تجربة واقع معزّز من مراجعة Apple بغير عمل أصلي.

الحالة المحلية: التكامل مع جهة بلا توثيق منشور

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

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

أين يقع فرق التكلفة فعلاً

الجملة المتداولة «المسار المتعدد يوفّر نصف التكلفة» تخطئ في موضع النصف. التوفير يقع على جانب العميل وحده، لا على الميزانية كلها.

قسّم المشروع إلى ثلاث مجموعات:

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

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

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

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

مثال افتراضي

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

أصليمتعدد المنصات
ما لا يتضاعف700700
جانب العميل1,200600
عمل أصلي باقٍلا يوجد120
الإجمالي1,900 ساعة1,420 ساعة

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

رسوم المتاجر لا تفرّق بين المسارين

نقطة تُخلط كثيراً: اشتراك Apple Developer بـ 99 دولاراً لكل سنة عضوية، ورسوم تسجيل Google Play بـ 25 دولاراً تُدفع مرة واحدة، وعمولات المتاجر على المحتوى الرقمي، كلها متطابقة في المسارين. فإذا رأيت عرضين يختلفان في هذه البنود، فالاختلاف في طريقة العرض لا في التكلفة. تفصيل هذه الرسوم في مقارنة تكلفة PWA بالتطبيق الأصلي.

الصيانة السنوية: الفرق يظهر في السنة الثانية

في السنة الأولى تبدو الأرقام في صالح المسار المتعدد بوضوح. في السنة الثانية يدخل عامل آخر: عدد المنظومات التي عليك متابعتها.

المسار الأصلي يتبع إصدارين سنويين: نظام Apple ونظام Google. والمسار المتعدد يتبع ثلاثة: النظامان نفساهما، زائد وتيرة الإطار وما يترتب عليها من ترقية للمكوّنات الوسيطة. وهذا الثالث ليس صغيراً: سياسة الدعم المنشورة لإصدارات React Native تحصر الدعم النشط في نطاق ضيق من أحدث الإصدارات، وتشترط لإصداري 0.87 و0.88 نسخة Xcode 26 كحد أدنى، وJDK 17، وNode 22.11.

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

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

أبدأ متعدد المنصات ثم أتحوّل: كم يكلفني ذلك؟

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

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

ويُعاد بناؤه: جانب العميل كاملاً، مرتين.

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

ثلاثة قرارات تخفض هذه الفاتورة، وكلها تُتخذ قبل أول سطر:

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

كيف تقرأ العرضين اللذين أمامك

إذا كنت تقارن عرضين الآن، فثلاثة أسئلة تكشف الفرق أسرع من أي جدول:

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

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

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

المصادر