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