تطوير التطبيقات

أصلي أم متعدد المنصات

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

  • الدرس 2 من 8
  • مبتدئ
  • مجاني، دون تسجيل

عمودان بلا فائز

أصلي

  • كوتلن لأندرويد وسويفت لـiOS
  • قاعدتا شفرة، أي كل ميزة مرتين
  • سقف الأداء والوصول الكامل إلى المنصة
  • صيانة أعلى كلفة، وخاصة من السنة الثانية
  • حين يكون لديك رسم متصل أو عمل متواصل مع العتاد

متعدد المنصات

  • قاعدة شفرة واحدة مشتركة بين أندرويد وiOS
  • بناء مرة واختبار مرة وصيانة مرة
  • سريع بما يكفي للقوائم والنماذج والمحتوى
  • معتمد على طبقة تغلّف قدرات المنصة
  • حين يكون الفريق صغيرا وميزانية الصيانة محدودة

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

آخر مراجعة: تُراجع الحقائق وأسماء الأدوات في هذا الدرس مقابل مصادرها في هذا التاريخ.

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

الأصلي يعني كتابة البرنامج بأدوات نظام التشغيل نفسه ولغته. وتوثيق غوغل صريح: فمنذ ٢٠١٩ أُعلن أن تطوير أندرويد يتجه أكثر فأكثر نحو كوتلن أولا، والصفحة نفسها توصي بأن تبدأ بكوتلن إن أردت بناء تطبيق أندرويد. وفي جهة أبل اللغة هي سويفت. والنتيجة أن تطبيقا واحدا على نظامين هو برنامجان منفصلان.

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

فالخلاف ليس على السرعة بل على عدد المرات التي تؤدي فيها العمل نفسه. فريق على الأصلي يبني كل ميزة مرتين ويختبرها مرتين ويصونها مرتين. وفريق على متعدد المنصات يبنيها مرة ويكتب استثناء حيثما اختلف سلوك المنصة. والكلفة الحقيقية للطريقين في تلك الجملة.

أصلي أم متعدد المنصات: أيهما يناسب مشروعك

الأمور الأربعة التي تغير القرار فعلا

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

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

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

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

السؤال الذي يحسم القرار أكثر من أي مقارنة أطر

هل يقضي البرنامج أكثر وقته في رسم متصل أو عتاد

نعم

الأصلي يستحق كلفته

  • الألعاب ومحرر الصور والواجهة كثيرة الحركة
  • استعمال حي للكاميرا أو الحساسات
  • الأدوات وخدمات الخلفية والاندماج العميق
لا

اختر متعدد المنصات

  • القوائم والنماذج والبحث وشاشات المحتوى
  • تسجيل الدخول والطلبات والرسائل والإشعارات
  • فريق صغير وميزانية صيانة محدودة

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

في السوق الإيرانية، ماذا يعني الوصول إلى المتجرين؟

صفحة غوغل الرسمية المعنونة بالمواقع المدعومة لتسجيل المطور والتاجر تحمل جدولا من ٢١٥ دولة وإقليما. قرأنا تلك الصفحة اليوم: العراق في الجدول، وكلمة إيران لا ترد مرة واحدة في الصفحة كلها. أي أن مسار تسجيل المطور الرسمي لمن هو في إيران غير معرَّف في ذلك الجدول. ولا نقترح سبيلا للالتفاف ولا ندّعي أنه لا سبيل البتة؛ وما نقوله هو ما كتبته وثيقة غوغل نفسها.

فحين يبيع أحدهم النشر في المتجرين بوصفه الميزة الأولى لمتعدد المنصات، وجب تغيير السؤال في السوق الإيرانية. فتطبيق أندرويد هنا يُثبَّت من كافه بازار ومايكت، وأحيانا مباشرة من ملف على الموقع نفسه، أما نسخة iOS فقصة أخرى. وتفصيل ذلك من عمل درس النشر في هذا المسار.

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

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

أين لا يفي متعدد المنصات بالغرض

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

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

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

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

من أين يثبّت مستخدمك التطبيق؟ وفيمَ يقضي التطبيق أكثر وقته، أفي المحتوى والنماذج أم في الكاميرا والرسوم؟ ومن يصونه في السنة الثانية؟ وإن لزمت نسخة iOS غدا، أالميزانية موجودة؟ وما الذي يعرفه الفريق اليوم حقا؟

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

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

أي سؤال يغير الجواب وأيها لا يكلف إلا وقتا

العمود الثاني أهم. فأغلب الاجتماعات التي تنتهي بلا نتيجة أنفقت وقتها كله عليه.

ورقة قرار الحزمةقبل الاجتماع التقني

هذه الأسئلة تغير القرار

  • من أين يثبّت المستخدم التطبيق
  • فيمَ يقضي البرنامج أكثر وقته
  • من يفتح هذه الشفرة في السنة الثانية
  • أنسخة iOS خطة حقيقية أم جملة

هذه الأسئلة لا تكلف إلا وقتا

  • أي إطار عمل أكثر شهرة
  • أيها كان أسرع في اختبارات الإنترنت
  • أيها تستعمله الشركات الكبيرة
  • أيها له مستقبل أفضل

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

المسار السريع مع الذكاء الاصطناعي

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

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

وصفة جاهزة للنسخ

الدور: مستشار تقني مهمته جعل القرار قابلا للإبطال، لا إبداء رأي.

المشروع:
ما يفعله البرنامج: {جملتان}
من أين يثبّت المستخدم: {متجر أو ملف مباشر}
الفريق: {العدد} أفراد، يعرفون: {التقنيات}
ميزانية صيانة السنة الثانية: {قليلة / متوسطة / كبيرة}
نسخة iOS: {خطة مؤكدة / مجرد احتمال / غير لازمة}

أعطِ المخرج في أربعة أقسام بالضبط:
١. التوصية: أصلي أم متعدد المنصات، في جملة واحدة بلا شرح.
٢. ثلاث حقائق لو تغيرت لانقلبت هذه التوصية. جملة لكل واحدة.
٣. ما لا تعرفه عن هذا المشروع وتحتاجه للقرار.
٤. السؤال الذي ينبغي أن أطرحه على الفريق ولم أطرحه بعد.

القواعد: لا تكتب أي رقم عن الأداء أو النسب أو زمن التطوير. ولا تنقل أي اختبار مقارنة. وإن لم يكن لديك شيء للقسم الثالث، فقل إن هذا نفسه يعني أنني لم أعطِ معلومات كافية.

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

الذكاء الاصطناعي في هذا العمل

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

أدوات تساعد فعلا

  • Claude مناسب لمحضر الأقسام الأربعة الذي تطلبه الوصفة أعلاه، وخاصة القسم الثالث حيث عليه أن يقول ما لا يعرفه. وإيران ليست في أي من قائمتَي الدول المدعومة لدى أنثروبيك؛ قرأنا ذلك على صفحتهم لا من قياس شبكي.
  • NotebookLM حين يكون السؤال ما الذي تقوله وثيقة إطار العمل الرسمية بالضبط، تتفوق هذه الأداة على محادثة عادية لأنها تجيب من المصدر الذي أعطيتها إياه فقط. وهكذا يمكن وضع صفحة المنصات المدعومة في فلاتر ووثيقة مكونات React Native جنبا إلى جنب. وتقول مساعدة غوغل نفسها إنها تعمل في المناطق ذاتها التي يعمل فيها تطبيق جيميناي، وإيران ليست في تلك القائمة.
  • Gemini نافع لمتابعة وثائق أندرويد وأبل الطويلة التي تتغير باستمرار. وهذا الدرس نفسه أخذ جملة الاتجاه إلى كوتلن أولا من توثيق أندرويد الرسمي لا من ملخص أحدهم. وتقول صفحة غوغل نفسها إن تطبيق جيميناي على الوب يعمل في أكثر من مئتين وثلاثين دولة وإقليما، وإيران ليست في تلك القائمة.

اين ينقلب ضدك

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

المصادر: Anthropic: reduce hallucinations Anthropic: supported countries Google: where the Gemini web app is available

حدود هذه النصيحة

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

من عملنا نحن

قاس الدرس الأول في هذا المسار على هذا الخادم نفسه أن واجهتنا تعيد ٤٠٣٬١٥٢ بايت لشاشة قائمة من عشرة صفوف بشكلها الافتراضي و٣٬٧٨٠ بايت حين تُسمَّى أربعة حقول، وأن أول بايت فيها يأتي بترويستَي x-flying-press-cache: MISS وcf-cache-status: DYNAMIC، أي بلا أي تخزين مؤقت. ولا يتحرك أي من هذه الأرقام باختيار إطار العمل على الهاتف. وفي أغلب تطبيقات الأعمال الصغيرة هذا هو ما يحدد السرعة، لا ما تدور حوله هذه الصفحة. والأمر الثاني عنا نحن وقابل للفحص: صفحة خدماتنا اتخذت هذا الموقف علنا قبل كتابة هذا الدرس، وهو أن متعدد المنصات هو الخيار الأعقل لتطبيق المحتوى والنماذج وأننا لا نقترح الخيار الأغلى تلقائيا. وكتابته هنا ليست إعلانا؛ بل ليرى أي أحد هل نقول الشيء نفسه حين نبيع وحين نعلّم.

اسئلة متابعة حقيقية

هل يعني متعدد المنصات أن التطبيق سيكون بطيئا؟

في القوائم والنماذج وشاشات المحتوى لا، ولا يرى المستخدم فرقا. ويقول توثيق React Native إن مكوناته مسنودة إلى ويوهات أندرويد وiOS البومية نفسها، ولذلك تبدو التطبيقات وتُحَس وتؤدي مثل أي تطبيق آخر. ويظهر السقف حيث يكون العمل متصلا وثقيلا، كلعبة أو معالجة صورة حية.

إن غيّرت رأيي لاحقا، هل يمكن الانتقال من متعدد المنصات إلى الأصلي؟

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

هل يهم هذا القرار للنشر في المتاجر الإيرانية؟

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