تطوير التطبيقات متعددة المنصات في عام 2020: أفضل أطر العمل التي يجب أخذها في الاعتبار

خلال 12 عامًا من وجودها، قطعت التطبيقات المحمولة شوطًا طويلاً.

في عام 2008، لم يكن عددهم يتجاوز 500 شخص. أما اليوم، فقد تجاوز عددهم خمسة ملايين. (1)

سواء كان إعلان شركة آبل لعام 2009 الذي حمل شعار «هناك تطبيق لذلك» مجرد شعار تسويقي أم نبوءة حقيقية، فإن أمراً واحداً مؤكداً — لقد تغيرت الطريقة التي نتواصل بها مع العالم من حولنا ونستكشفه تغيراً جذرياً خلال العقد الماضي؛ وهو تحول في نمط الحياة يُعزى في جزء كبير منه إلى تلك المربعات الصغيرة المرتبة بعناية على شاشاتنا.

بل إن الأمر وصل إلى درجة أن هذه الحياة التي أصبحت تعتمد على التطبيقات، والتي أصبحنا نعيشها، تجعلنا نتفقد هواتفنا 58 مرة في اليوم، ونقضي 90% من هذا الوقت في استخدام التطبيقات. (2، 3)

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

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

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

والخبر السار هو أن هناك طريقة للتغلب على هذه المشكلة.

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

من كان منكم يتابع أخبار مجال تطوير التطبيقات، لا بد أنه سمع بها بالفعل — Xamarin وReact Native وFlutter وCordova وما شابهها.

على مر السنين، لبت هذه الأطر احتياجات الشركات التي تسعى للوصول إلى مستخدمي الهواتف الذكية على منصتي iOS وAndroid (اللتين تشكلان 98% من سوق أنظمة تشغيل الهواتف المحمولة)، دون الحاجة فعليًّا إلى تطوير تطبيقين منفصلين لكل نظام تشغيل. (5، 6)

وبذلك، تمكنوا من الاستفادة مما يلي:

• Same accessibility with half the effort. One of the biggest benefits cross-platform app development offers is the ease of code reusability. Instead of releasing multiple native apps for each platform, you can reuse a significant amount of code and have the same app deployed across multiple platforms.
• Reduced costs. Because the code is written once, the development team will have to put in half the effort which translates into reduced production, maintenance, and hiring costs. The need for learning a platform-specific language is also reduced as fluency in JavaScript, C++, C#, and HTML5 will in most cases suffice for cross-platform development.
• Shorter time to market. Less work also means quicker deployment times. Subsequently, less time spent in development means you can deliver value to your customers faster and tweak your applications according to their feedback sooner.
• Near-native feel. Despite the substantial UX and UI differences between iOS and Android, cross-platform apps can emulate the native feel by handling design and navigation mismatches by default.

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

اتضح أن هناك عددًا لا بأس به من الأسباب، ومن بينها: 

• Language barrier. One of the main challenges that come with cross-platform app development is the fact developers are writing an app in a non-native language. This means they won’t have the same access to the native components simply because the code is written in a higher-level language. To bridge the two, they need to rely on third-party libraries specific to each framework, and the younger the framework is, the scarcer the library.
• UX discrepancy. Because both Android and iOS have very specific graphical user interfaces (navigation, buttons, menus, etc.), more effort is required to achieve a native feel for each platform. Sometimes, the labor put into making this happen outweighs the above-listed benefits.
• Performance issues. Performance is another known dealbreaker, and even though the differences are for the most part minute, developing a mobile game with Flutter or React Native won’t match the native technology.
• Size. Depending on the framework, code linkage and third-party plugins can nearly double the file size of your cross-platform app. And as you can imagine, larger apps don’t get as much love as their lighter counterparts. Not only do they require more storage space on the user’s device, but they also take more time and data to download. In fact, Google Play Apps & Games published a report showing a 100MB app will receive ~30% fewer downloads than an app that weighs around 10MB. 
• Your target audience. Finally, you may only need to serve Android or iOS users, in which case going native would make perfect sense. The programming language is now fully compatible with the platform and the device, meaning your developer won’t have to fish out that gyroscope plugin for Cordova.

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

ومع ذلك، بالنسبة للغالبية العظمى من الشركات (من أمثال «فيسبوك» و«جوجل» و«إيباي»)، أثبت نهج التطوير عبر المنصات أنه طريقة موثوقة وفعالة من حيث التكلفة لتطوير التطبيقات. 

دعونا نقيّم بعض أطر العمل الرائدة في عام 2020 ونرى نقاط قوتها ونقاط ضعفها.

React Native: اكتب مرة واحدة، وانشر في أي مكان

تأسست React Native على يد فيسبوك في عام 2015، وسرعان ما رسخت مكانتها كأحد أكثر أطر التطوير متعددة المنصات شيوعًا بين المطورين. 

العامل الرئيسي وراء انتشار استخدامه على نطاق واسع هو لغة البرمجة الخاصة بهذا الإطار، وهي JavaScript، التي تُستخدم في 95% من مواقع الويب البالغ عددها 1.7 مليار موقع في العالم. (7، 8)

وهذا يعني أن المطور الذي سبق له إنشاء موقع ويب باستخدام JavaScript لن يواجه صعوبة كبيرة في التعلم عند العمل على تطبيق متعدد المنصات باستخدام React Native. 

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

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

كوردوفا: هل يستحق WebView العناء؟ 

تمامًا مثل React Native، تُعد Cordova خيارًا جذابًا لمطوري الويب الذين تروق لهم فكرة إعادة استخدام مهاراتهم الحالية في HTML وCSS وJS لإنشاء تطبيق يعمل على كل من نظامي Android وiOS.

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

لكن توخَّ الحذر قبل أن تنضم إلى ركب «كوردوفا». فإذا لم تكن على دراية بحدود هذا الإطار (وحدودك أنت)، فقد يتحول هذا الحلم سريعًا إلى كابوس. 

أولاً وقبل كل شيء، سيكون من غير المنطقي تطوير لعبة جادة أو تطبيق ثقيل باستخدام Cordova. وعلى عكس React Native، الذي يستدعي الوظائف الأصلية عبر جسر اتصال، فإن Cordova يعرض الكود في WebView، وتشغيل التطبيق بهذه الطريقة لا يؤدي فقط إلى خسارة كبيرة في الأداء، بل يجعل التطبيق أيضًا عرضة لهجمات XSS. 

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

بالنسبة للتطبيقات الصغيرة والبسيطة، تُعد «كوردوفا» خيارًا يستحق الاهتمام. فعلى سبيل المثال، تم تطوير تطبيقات نمط الحياة والأخبار والفعاليات والتطبيقات التعليمية وتطبيقات المراسلة باستخدام «كوردوفا»، ويمكن تطويرها بسهولة باستخدامها، حيث تستحوذ «كوردوفا» — حتى وقت كتابة هذا المقال — على 7.88% من حصة سوق التطبيقات. 

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

Xamarin: رائد البرمجة عبر المنصات

كانت «Xamarin» من أوائل أطر العمل مفتوحة المصدر التي تم إطلاقها بهدف الربط بين المنصات الأصلية وجعل تطوير تطبيقات الهواتف المحمولة عملية أقل تكلفة. 

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

واليوم، يُعدّ أحد أطر التطوير الشائعة عبر المنصات المختلفة، حيث يضمّ أكثر من 60,000 مساهم من أكثر من 3,700 شركة. (9)

نظرًا لأن Xamarin تستند إلى لغة البرمجة C# الموجهة للكائنات، فإن الكثيرين يعتبرونها أصعب في التعلم من React Native، على الرغم من أن الكود يعمل بسلاسة على مجموعة من المنصات، بما في ذلك Android وiOS وtvOS وwatchOS وmacOS وWindows.

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

الآن، هناك مساران يمكن الاختيار من بينهما عند تطوير تطبيق باستخدام Xamarin، وكلاهما يتيح مستويات أداء تقترب من الأداء الأصلي.

1. Xamarin Native offers a low-level approach to building separate applications for each platform with Xamarin.iOS and Xamarin.Android libraries. It’s a basis for exposing some native functionalities to Xamarin Forms by calling platform-specific APIs.
    
2. Xamarin.Forms is a framework on top of Xamarin Native with all functionalities of Xamarin. It’s a better option for those just starting out with Xamarin as developers are able to reuse up to 96% of the code and product owners can scale and maintain their apps more easily.

Flutter: الوافد الجديد إلى الساحة

على عكس React Native وXamarin، فإن Flutter هو إطار عمل لم يمر على ظهوره سوى بضع سنوات. 

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

قد لا تحظى لغة البرمجة الخاصة بها، «دارت» (Dart)، بنفس شعبية «جافا سكريبت» (JavaScript)، لكنها سهلة التعلم نسبيًّا؛ فمن ناحية، يشبه جزء كبير من قواعدها النحوية لغات «سويفت» (Swift) و«كوتلين» (Kotlin) و«جافا» (Java)، مما يعني أن المطورين الذين يتمتعون بخبرة في لغتي «سي» (C) و«سي بلس» (C++) لن يواجهوا صعوبة كبيرة في التحول إلى هذه الطريقة الموجهة للكائنات في تطوير التطبيقات. 

وحتى لو واجهوا بعض العقبات في المستقبل، فإن Flutter توفر وثائق شاملة لدعم عملية انتقالهم.

ثم تأتي بنية Flutter، التي لا تعتمد — مقارنةً بـ React Native — على JavaScript Bridge لترجمة الاستدعاءات إلى واجهة برمجة تطبيقات أصلية. حيث يتم ترجمة الكود المكتوب بلغة Dart إلى كود آلي أصلي، مما يؤدي إلى أداء أكثر سلاسة وأفضل للتطبيق، بالإضافة إلى تجربة مستخدم محسّنة. 

ومع ذلك، فإن طريقة Flutter في التواصل مباشرةً مع النظام الأساسي باستخدام مكتبتها الخاصة من المكونات المدمجة ليست مثالية. فمن الصعب العثور على مكونات إضافية من جهات خارجية، كما أن واجهات برمجة التطبيقات (API) الخاصة بالأجهزة ليست متوفرة بنفس القدر الذي تتوفر به في React Native، مما يجعل Flutter خيارًا أقل ملاءمة للتطبيقات التي تعتمد على الأجهزة. 

ومن الجدير بالذكر أيضًا أن محركات C/C++ وDart تصبح ثقيلة جدًّا، ورغم أن التطبيقات المصممة باستخدام Flutter قد تعمل بشكل أفضل، إلا أنها ستشغل مساحة كبيرة. 

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

ما هو الإطار الذي ينبغي عليك اختياره؟

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

أياً كان النهج الذي تختاره — سواء كان تطبيقاً أصلياً، أو متعدد المنصات، أو حتى مزيجاً من الاثنين — فإن الأجهزة المحمولة لن تختفي. بل على العكس، من المتوقع أن نقضي هذا العام ما معدله 3.7 ساعة يوميًا على هواتفنا الذكية، وهو ما يمثل زيادة بنسبة 10% مقارنة بالعام الماضي ونموًا بنسبة 35% مقارنة بعام 2017. (10)

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