تطوير التطبيقات عبر المنصات المتعددة في 2020: أفضل الأطر التي يجب مراعاتها
خلال 12 عاماً من وجودها، قطعت تطبيقات الهاتف المحمول شوطاً طويلاً.
في عام 2008، لم يكن هناك سوى 500 منهم. أما اليوم، فهناك أكثر من خمسة ملايين. (1)
وسواء كان إعلان Apple في عام 2009 “هناك تطبيق لذلك” شعارًا تسويقيًا أو نبوءة حقيقية، فإن الشيء المؤكد هو أن الطريقة التي نتواصل بها مع العالم من حولنا ونختبره قد تغيرت تمامًا في العقد الماضي؛ وهو تحول في نمط الحياة يعزى بشكل كبير إلى المربعات الصغيرة المرتبة بدقة على شاشاتنا.
لدرجة أن هذه الحياة التي نعيشها والتي تعتمد على التطبيقات جعلتنا نتفقد هواتفنا 58 مرة في اليوم، ونقضي 90% من هذا الوقت في استخدام التطبيقات. (2, 3)
بطبيعة الحال، اتبعت الشركات الكبيرة والصغيرة على حد سواء الاتجاه السائد في مجال الهواتف المحمولة عن كثب، حيث أدركت أن التطبيق الخاص بها يزيد من ظهورها ويزيد من ولاء العملاء ويحسن من أرباحها النهائية.
من المتوقع أن تقترب إيرادات تطبيقات الأجهزة المحمولة (التنزيلات المدفوعة وعمليات الشراء داخل التطبيق والإعلانات) على مستوى العالم من 600 مليار دولار، ومن المتوقع أن ترتفع الأرقام مع تحول امتلاك تطبيق للأعمال إلى قاعدة لأي شركة صاعدة. (4)
وبالتالي، فإن التطبيقات ليست مطلوبة بشدة فحسب، بل يمكن أن تكون مربحة للغاية. ومع ذلك، عندما يتعلق الأمر ببناء تطبيق أصلي لكل من Android و iOS، فإن تكاليف التطوير المرتفعة وأوقات النشر البطيئة يمكن أن تضع ضغطاً هائلاً على أكثر الفرق طموحاً.
الخبر السار هو أن هناك طريقة للتغلب على ذلك.
قاعدة كود واحدة تحكمها كلها: إيجابيات وسلبيات تطوير الأجهزة المحمولة عبر المنصات المختلفة
أما أولئك الذين يتابعون مشهد تطوير التطبيقات فقد سمعوا عنها بالفعل، مثل Xamarin و React Native و Flutter و Cordova وما شابه ذلك.
على مر السنين، أشبعت هذه الأطر رغبات الشركات التي تتطلع إلى الوصول إلى مستخدمي الهواتف الذكية لكل من نظامي التشغيل iOS و Android (اللذين يشكلان 98% من سوق أنظمة تشغيل الهواتف المحمولة)، دون تطوير تطبيقين منفصلين لكل نظام تشغيل. (5, 6)
وبذلك، تمكنوا من الاستفادة من
- نفس إمكانية الوصول بنصف الجهد. واحدة من أكبر الفوائد التي يوفرها تطوير التطبيقات عبر المنصات هي سهولة إعادة استخدام التعليمات البرمجية. فبدلاً من إصدار تطبيقات أصلية متعددة لكل منصة، يمكنك إعادة استخدام قدر كبير من التعليمات البرمجية ونشر نفس التطبيق عبر منصات متعددة.
- انخفاض التكاليف. نظرًا لأن الكود يُكتب مرة واحدة، سيتعين على فريق التطوير بذل نصف الجهد الذي يُترجم إلى انخفاض تكاليف الإنتاج والصيانة والتوظيف. كما تقل الحاجة إلى تعلم لغة خاصة بالمنصة حيث أن إتقان لغة JavaScript و C++C و C# و HTML5 سيكفي في معظم الحالات للتطوير عبر المنصات.
- وقت أقصر للتسويق. عمل أقل يعني أيضًا أوقات نشر أسرع. وبالتالي، فإن قضاء وقت أقل في التطوير يعني أنه يمكنك تقديم قيمة لعملائك بشكل أسرع وتعديل تطبيقاتك وفقًا لتعليقاتهم في وقت أقرب.
- إحساس قريب من السكان الأصليين. على الرغم من الاختلافات الجوهرية في تجربة المستخدم وواجهة المستخدم بين نظامي iOS و Android، يمكن للتطبيقات عبر المنصات أن تحاكي الإحساس الأصلي من خلال التعامل مع عدم تطابق التصميم والتنقل بشكل افتراضي.
تبدو هذه الفوائد جيدة جداً لدرجة يصعب تصديقها. لماذا يسلك أي شخص الطريق الأصلي ويُنشئ تطبيقين منفصلين لكلا النظامين الأساسيين في حين أنه يمكنك الحصول على نفس إمكانية الوصول من خلال القيام بنصف العمل؟
اتضح أن هناك عدة أسباب، منها:
- حاجز اللغة. أحد التحديات الرئيسية التي تأتي مع تطوير التطبيقات عبر المنصات هو حقيقة أن المطورين يكتبون التطبيق بلغة غير اللغة الأصلية. هذا يعني أنه لن يكون لديهم نفس إمكانية الوصول إلى المكونات الأصلية ببساطة لأن الكود مكتوب بلغة ذات مستوى أعلى. للربط بين الاثنين، يحتاجون إلى الاعتماد على مكتبات الطرف الثالث الخاصة بكل إطار عمل، وكلما كان إطار العمل أصغر سنًا، كلما كانت المكتبة أكثر ندرة.
- تناقض تجربة المستخدم. لأن لكل من Android و iOS واجهات مستخدم رسومية محددة للغاية (التنقل والأزرار والقوائم وما إلى ذلك)، يلزم بذل المزيد من الجهد لتحقيق إحساس أصلي لكل منصة. في بعض الأحيان، يفوق الجهد المبذول في تحقيق ذلك المزايا المذكورة أعلاه.
- مشكلات في الأداء. الأداء هو أمر آخر معروف، وعلى الرغم من أن الاختلافات في معظمها دقيقة، إلا أن تطوير لعبة محمولة باستخدام Flutter أو React Native لن يتطابق مع التقنية الأصلية.
- الحجم. اعتمادًا على إطار العمل، يمكن أن يؤدي ربط التعليمات البرمجية والإضافات الخارجية إلى مضاعفة حجم ملف تطبيقك عبر المنصات تقريبًا. وكما يمكنك أن تتخيل، فإن التطبيقات الأكبر حجمًا لا تحظى بنفس القدر من الاهتمام الذي تحظى به نظيراتها الأخف وزنًا. فهي لا تتطلب مساحة تخزين أكبر على جهاز المستخدم فحسب، بل تستغرق أيضاً وقتاً أطول وبيانات أكثر للتنزيل. في الواقع، نشر جوجل بلاي للتطبيقات والألعاب تقريراً يُظهر أن التطبيق الذي يبلغ حجمه 100 ميغابايت سيحصل على تنزيلات أقل بنسبة 30% تقريبًا من التطبيق الذي يزن حوالي 10 ميغابايت.
- جمهورك المستهدف أخيرًا، قد تحتاج فقط إلى خدمة مستخدمي Android أو iOS، وفي هذه الحالة سيكون الانتقال إلى اللغة الأصلية منطقيًا تمامًا. أصبحت لغة البرمجة الآن متوافقة تمامًا مع المنصة والجهاز، مما يعني أن مطوِّرك لن يضطر إلى البحث عن ذلك المكون الإضافي الجيروسكوب لـ Cordova.
يمكنك أن ترى الآن كيف أن التطوير عبر المنصات ليس كله ورود. فقد يحدث الكثير من الأخطاء، والأمر متروك لك لتقرر ما إذا كان هذا النهج جديراً بمشروعك.
ومع ذلك، فبالنسبة للغالبية العظمى من الشركات (مثل فيسبوك وجوجل وإي باي)، أثبت نهج التطوير عبر المنصات أنه طريقة فعالة من حيث التكلفة وجديرة بالثقة لبناء التطبيقات.
دعنا نقيّم بعض الأطر الرائدة في عام 2020 ونرى أين تتألق وأين تقصر.
React Native: الكتابة مرة واحدة والنشر في أي مكان
تأسست React Native من قبل فيسبوك في عام 2015، وسرعان ما عززت React Native نفسها كواحدة من أكثر أطر التطوير عبر المنصات شعبية بين المطورين.
إن المحرك الرئيسي وراء استخدامه على نطاق واسع هو لغة البرمجة الخاصة بالإطار، وهي لغة البرمجة JavaScript، والتي تُستخدم في 95% من المواقع الإلكترونية في العالم البالغ عددها 1.7 مليار موقع. (7, 8)
هذا يعني أن المطور الذي أنشأ موقعًا إلكترونيًا بالفعل باستخدام JavaScript لن يواجه منحنى تعليمي حاد عند العمل على تطبيق متعدد المنصات في React Native.
هناك ميزة أخرى كبيرة أخرى تقدمها React Native وهي قدرتها على محاكاة الإحساس الأصلي للتطبيق بنجاح. على الرغم من أنه لا يتضمن العديد من مكونات واجهة المستخدم خارج الصندوق، إلا أن هناك وفرة من مكونات الطرف الثالث التي تجعل التجربة أصلية سلسة.
تكمن المشكلة في أنك عندما تعتمد بشكل كبير على المكتبات الخارجية، قد تقايض إحساسًا شبيهًا بالأصل مقابل أداء أبطأ. نظرًا لأن React Native تتطلب جسرًا لأغلفتها الأصلية، فقد ينتهي بك الأمر مع تطبيق يحتوي على الكثير من الاستدعاءات الأصلية، مما يسبب مشاكل في الأداء.
كوردوفا: هل يستحق WebView ذلك؟
على غرار React Native، تُعد Cordova خيارًا مغريًا لمطوري الويب الذين يقتنعون بفكرة إعادة استخدام مهاراتهم الحالية في HTML و CSS و JS لإنشاء تطبيق لكل من Android و iOS.
على الورق، تبدو Cordova كالحلم. هناك مجموعة من الأدوات والمكتبات التي تجعل حياتك أسهل – أيونيك، على سبيل المثال، رائعة للتعامل مع واجهة المستخدم ودمج خدمات إضافية مثل القياسات الحيوية لبصمات الأصابع ومعالجة الدفع في تطبيقك.
لكن توخَّ الحذر قبل أن تقفز على عربة كوردوفا. إذا لم تكن على دراية بحدود إطار العمل (وحدودك)، فقد يتحول هذا الحلم بسرعة إلى كابوس.
بادئ ذي بدء، سيكون من غير المنطقي كتابة لعبة خطيرة أو تطبيق ثقيل باستخدام كوردوفا. على عكس React Native، الذي يستدعي الوظائف الأصلية من خلال جسر، فإن Cordova يعرض الشيفرة في WebView، وتشغيل التطبيق بهذه الطريقة لا يسبب فقط خسارة كبيرة في الأداء، بل يجعل التطبيق عرضة لهجمات XSS.
من المحتمل أيضًا أن تقضي بعض الوقت في إيجاد حلول بديلة للأخطاء الخاصة بالمنصة. في بعض الأحيان، قد تنطوي هذه العملية على قدر كبير من الإحباط، حيث أن الوظائف الأصلية التي لطالما اعتبرتها أمراً مفروغاً منه تحتاج الآن إلى تصحيحها باستخدام مكونات إضافية تتطلب تخصيصها أو الأسوأ من ذلك، تطويرها من الصفر.
بالنسبة للتطبيقات الصغيرة والبسيطة، فإن كوردوفا خيارٌ يستحق العناء. فتطبيقات نمط الحياة والأخبار والأحداث والتطبيقات التعليمية وتطبيقات المراسلة على سبيل المثال يمكن إنشاؤها بسهولة باستخدام كوردوفا، والتي كانت وقت كتابة هذا التقرير يستحوذ على 7.88% من حصة سوق التطبيقات.
ولكن إذا كنت تطور لعبة ذات رسوم متحركة ثقيلة، فكر في استخدام النهج الأصلي. ستخسر وقتًا أطول في اكتشاف الحلول البديلة ذات الصلة أكثر مما وفرت من خلال كتابة قاعدة برمجية واحدة.
Xamarin: منصة Xamarin: نظام التشغيل عبر المنصات المتعددة
كان Xamarin من بين أوائل أطر العمل مفتوحة المصدر التي تم إطلاقها بهدف الربط بين المنصات الأصلية وجعل تطوير الأجهزة المحمولة أقل تكلفة.
وعلى الرغم من إطلاق Xamarin في عام 2011، إلا أن مجتمع التطوير لم يبدأ أخيرًا في إضفاء بعض المصداقية والجاذبية عليها إلا بعد استحواذ مايكروسوفت عليها في عام 2016.
وهو اليوم أحد أطر التطوير عبر المنصات المتعددة، حيث يضم أكثر من 60,000 مساهم من أكثر من 3,700 شركة. (9)
يعتمد Xamarin على لغة C#، وهي لغة برمجة موجهة للكائنات، ويعتبره الكثيرون أكثر صعوبة في التعلم من React Native، على الرغم من أن الكود يعمل بسلاسة على مجموعة من المنصات، بما في ذلك Android و iOS و tvOS و watchOS و macOS و Windows.
بالإضافة إلى ذلك، فإن المطورين مزودون بجميع الأدوات التي يحتاجونها لإنشاء تطبيقاتهم عبر المنصات من خلال .NET، بما في ذلك واجهات برمجة التطبيقات الخاصة بالمنصة والحزم و XAML.
والآن، هناك مساران للاختيار من بينهما عند إنشاء تطبيق في Xamarin، وكلاهما يتيح مستويات أداء قريبة من الأداء الأصلي.
- يوفر Xamarin Native نهجًا منخفض المستوى لبناء تطبيقات منفصلة لكل منصة مع مكتبات Xamarin.iOS و Xamarin.Android. إنه أساس لتعريض بعض الوظائف الأصلية لنماذج Xamarin من خلال استدعاء واجهات برمجة التطبيقات الخاصة بالمنصة.
- Xamarin.Forms هو إطار عمل فوق Xamarin Native مع جميع وظائف Xamarin. إنه خيار أفضل لأولئك الذين بدأوا للتو في استخدام Xamarin حيث يمكن للمطورين إعادة استخدام ما يصل إلى 96% من التعليمات البرمجية ويمكن لمالكي المنتجات توسيع نطاق تطبيقاتهم وصيانتها بسهولة أكبر.
الرفرفة: الطفل الجديد على الساحة
على عكس React Native و Xamarin، فإن Flutter هو إطار عمل موجود منذ بضع سنوات فقط.
ولكن على الرغم من كونه مبتدئًا في السوق، إلا أن تطبيق Flutter أحدث صدمة في المجتمع منذ إطلاقه من قِبل Google في عام 2018، حيث أثبت أنه منافس موثوق ومبتكر.
قد لا تحظى لغة البرمجة Dart بشعبية كبيرة مثل JavaScript، ولكن من السهل نسبيًا تعلمها؛ فمن ناحية أولى، تتشابه معظم صيغها مع Swift وKotlin وJava، مما يعني أن المطورين الذين لديهم خبرة في C/C++ لن يواجهوا مشكلة كبيرة في التحول إلى هذه الطريقة الموجهة للكائنات في بناء التطبيقات.
وحتى إذا واجهوا بعض العقبات في الطريق، فإن Flutter يوفر وثائق شاملة لدعم انتقالهم.
تأتي بعد ذلك بنية Flutter، والتي لا تعتمد على جسر JavaScript لترجمة المكالمات إلى واجهة برمجة تطبيقات أصلية مقارنةً بـ React Native. يتم تجميع الشيفرة المكتوبة بلغة Dart إلى شيفرة آلة أصلية، مما يؤدي إلى أداء تطبيق أكثر سلاسة وتحسينًا وتجربة مستخدم أفضل.
ولكن طريقة Flutter في التواصل المباشر مع المنصة باستخدام مكتبتها الخاصة من المكونات المدمجة ليست مثالية. من الصعب الحصول على إضافات الطرف الثالث، كما أن واجهات برمجة التطبيقات الخاصة بالأجهزة ليست وفيرة كما هو الحال مع React Native، مما يجعل Flutter خيارًا أقل جودة للتطبيقات المعتمدة على الأجهزة.
تجدر الإشارة أيضًا إلى حقيقة أن محرك C/C+++C و Dart ضخم جدًا، وعلى الرغم من أن التطبيقات المصممة في Flutter قد تعمل بشكل أفضل، إلا أنها ستشغل مساحة كبيرة.
ومع ذلك، فإن الأدوات التي تحصل عليها من خارج الصندوق قابلة للتخصيص بالكامل، بالإضافة إلى ميزة إعادة التحميل السريع، تجعل من Flutter إطار عمل مثالي لتطوير تطبيق MVP بواجهة مستخدم مصممة خصيصًا ومثالية.
أي إطار عمل يجب أن تختار؟
حسنًا، ستعتمد الإجابة على هذا السؤال إلى حد كبير على الأهداف التي حددتها لتحقيقها من خلال تطبيقك، بالإضافة إلى الوقت والميزانية التي يمكنك تخصيصها لإنتاجه وصيانته.
أيًا كان النهج الذي تختاره – سواء كان أصليًا أو عبر المنصات أو حتى مزيجًا من الاثنين – فإن الهاتف المحمول لن يذهب إلى أي مكان. بل على العكس، من المتوقع أن نقضي 3.7 ساعة في المتوسط على هواتفنا الذكية يومياً هذا العام، بزيادة 10% على أساس سنوي ونمو بنسبة 35% عن عام 2017. (10)
أيًا كانت الطريقة التي تقرر بها إنشاء تطبيقك، كن مطمئنًا أن Microblink سيكون موجودًا لدعمك عندما تحتاج إلى حل مسح ضوئي قوي وسلس مدمج فيه.
