أصلي أم متعدد المنصات؟ كيف تختار لتطبيقك

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

يتناول هذا المقال القرار لا الأدوات، ولذلك لا يكرر المقارنة بين الأطر. وللمفاضلة بين Flutter وReact Native اقرأ مقال [Flutter أم React Native](/blog/flutter-vs-react-native). وللتعريفات المبسطة راجع مدخلي المسرد عن [التطبيق الأصلي](/glossary/native-app) و[التطبيق متعدد المنصات](/glossary/cross-platform-app).

ابدأ مما يجب أن يفعله التطبيق على الجهاز

السؤال الأول تقني، ويمكنك الإجابة عنه في ساعة: أي الميزات تلامس العتاد أو نظام التشغيل بطريقة غير معتادة؟ فأغلب ما تفعله التطبيقات عادي، وكلا النهجين يتعامل معه. وقليل منها غير عادي، وهذا القليل هو الذي يحسم الأمر.

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

عوامل المنتج التي ترجّح الكفة

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

يختلف التنقل والإيماءات بين iOS وAndroid: سلوك الرجوع، والنوافذ السفلية، والقوائم، وحوارات النظام. والتطبيق الأصلي يتبع هذه الأعراف دون جهد. أما التطبيق متعدد المنصات فيستطيع اتباعها أيضًا، لكن لا بد أن يقرر أحدهم أين يتكيّف وأين يُبقي تصميمًا واحدًا تقوده هوية العلامة على المنصتين. اتخذ هذا القرار عن قصد في مرحلة [تصميم تطبيقات الجوال](/services/ui-ux-design/mobile-app-design) لا أثناء الاختبار.

إن كنت ما زلت تختبر الطلب، فأرخص بناء يجيب عن السؤال هو الأنسب. قد يكون [منتجًا أدنى قابلًا للتطبيق](/glossary/mvp) متعدد المنصات، أو نموذجًا أوليًا بدون كود، أو تطبيق ويب، ويتناول مقال [متى يكون بدون كود أذكى نسخة أولى](/blog/when-no-code-is-the-smart-first-version) الخيارين الأخيرين. ويصعب تبرير البناء الأصلي على منصتين قبل أن تعرف أن الفكرة تعمل، فإذا ثبت الطلب صار الأصلي في المواضع المناسبة أسهل تبريرًا.

عوامل الفريق

البنية المناسبة هي التي يستطيع فريقك صيانتها بعد عامين. وهذه النقاط تهمّ في الغالب أكثر من أي تفصيل تقني:

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

ما تتنازل عنه في النهج متعدد المنصات

يقايض النهج متعدد المنصات بعض المباشرة بجهد مشترك. والكلفة حقيقية، لكنها في تطبيقات الأعمال متواضعة في الغالب. فاعرف القائمة قبل أن تقبلها:

• **طبقة بينك وبين المنصة.** الميزات الجديدة في النظام تصل إلى الإطار بعد وصولها إلى المنصة، وقد تحتاج إلى طبقة وصل أصلية.
• **حزم يصونها غيرك.** حزم الكاميرا والخرائط والدفع يصونها متطوعون أو شركات. اختر الحزم الجيدة الصيانة وراجعها كأي اعتمادية.
• **شيفرة أصلية عند الأطراف.** الميزات غير المعتادة ما زالت تحتاج إلى Swift أو Kotlin، فالمشروع متعدد المنصات لا يخلو تمامًا من الشيفرة الأصلية.
• **إحساس المنصة يحتاج عناية.** الإعدادات الافتراضية متقاربة لا متطابقة، فخصص وقتًا للتصميم والاختبار لكل منصة.
• **جهد الترقية.** كل إصدار جديد من الإطار قد يمس اعتمادياتك، كل عام وفي النهجين. خطط له صيانةً؛ ويسرد مقال [كم تكلفة تطبيق الجوال](/blog/how-much-does-a-mobile-app-cost) التكاليف التي ينساها الناس.
• **فروق الحجم وسرعة البدء.** قد يكون التطبيق أكبر حجمًا أو أبطأ في البدء من تطبيق أصلي رشيق، ويظهر ذلك أكثر على الهواتف الأقدم.

ما تتنازل عنه في النهج الأصلي

• **شيفرتان ومهارتان.** كل ميزة تُصمَّم مرة، وتُبنى مرتين، وتُختبر مرتين، وتُصلَح مرتين، على يد متخصصين في كل منصة.
• **التباعد.** يتباعد التطبيقان تدريجيًا في الميزات والصياغة ما لم يتولَّ أحد مسؤولية التكافؤ بينهما.
• **تعلّم أبطأ.** تغيير الفكرة يستغرق وقتًا أطول حين يحملها تطبيقان، وهذا أكثر ما يهمّ قبل أن تعرف ما الذي ينجح.
• **جهد أكبر لا ضعف.** التصميم والخلفية والواجهة البرمجية والمحتوى وإدارة الإصدار أعمال مشتركة. وتجد طريقتنا في المشاريع الأصلية في صفحة [تطوير تطبيقات iOS وAndroid](/services/mobile-development/ios-android).

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

خيارات وسطى

ليس الاختيار نقيًا دائمًا. وثمة ثلاثة مزيجات شائعة:

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

وأيًّا كان اختيارك، أبقِ قواعد العمل على الخادم خلف [واجهة برمجية API](/glossary/api)، لا مكررة داخل التطبيق. فهذا يجعل كل تغيير لاحق أرخص، بما في ذلك الانتقال من نهج إلى آخر.

أسئلة تجيب عنها قبل أن تختار

مثال افتراضي وليس من أعمالنا: متجر تجزئة يبني تطبيق تسوق وولاء ميزاته عادية ويريد منصتين، فيناسبه النهج متعدد المنصات. وشركة تبني تطبيقًا يقيس الغرف بالكاميرا والواقع المعزز، والكاميرا هي جوهر منتجها، فيناسبها الأصلي لهذا الجزء على الأقل.

اختبر أرخص ما يمكن قبل القرار الكبير

قبل أن تلتزم، ابنِ تجربة صغيرة لأخطر ميزة في المنظومة التي تميل إليها، على هواتف حقيقية وبالعربية والإنجليزية. وكثيرًا ما تحسم أيام قليلة من ذلك جدلًا لا تحسمه أسابيع من الآراء. وفي مشاريعنا ينتهي [سبرنت الاستكشاف](/pricing) بنهج تقني ونموذج أولي قابل للنقر، وهنا يُتخذ هذا القرار بالأدلة لا بالذوق.