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