Native أم متعدد المنصات: كيف تقرّر فعلاً

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

Native يعني تطبيقين منفصلين لـ iOS وAndroid، كلٌّ بلغة منصّته. ومتعدد المنصات يعني كوداً واحداً يُنتج التطبيقين، باستخدام أداة مثل Flutter أو React Native.

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

1. كم من منتجك يعتمد على قدرات غير معتادة في الجهاز؟

هذا هو السؤال الحاسم، ويستحق أن تكون صريحاً فيه.

معظم التطبيقات، من الناحية التقنية، شاشات ونماذج وقوائم واتصالات بالشبكة. والتطوير متعدد المنصات يتعامل مع ذلك كله بسهولة منذ سنوات.

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

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

2. كم شخصاً سيصون التطبيق، ولأي مدة؟

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

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

أما ميزة Native فتظهر مع الحجم الكبير، حين يكون لديك فريقان منفصلان لـ iOS وAndroid يعملان باستقلال دون تنسيق على طبقة مشتركة.

إن كانت الإجابة الصادقة "مطوّران، لأجل غير محدد"، فهذه حجة قوية للتطوير متعدد المنصات.

3. هل يجب أن تبدو المنصتان مختلفتين؟

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

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

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

4. ماذا يستطيع فريقك أن يصون فعلاً؟

أفضل اختيار تقني لا يستطيع فريقك دعمه أسوأ من اختيار مقبول يستطيع.

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

الافتراض الصادق

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

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

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

أجب عن الأسئلة الأربعة أولاً. والتقنية ستظهر من الإجابات.