قبل أن تختار لغة البرمجة أو إطار العمل، توقف أمام الشاشات الثلاث الأهم في تطبيقك. ابحث عن الشاشة التي يفتحها المستخدم أكثر من غيرها، والشاشة التي يتوقف عندها عند الحاجة الحرجة، والشاشة التي تعتمد على ميزة لا تتوفر إلا على الجهاز نفسه. ثم علّم كل واحدة بإحدى العبارتين: "تحتاج الجهاز" أو "محتوى فقط". هذه التمرين البسيط يكشف ما إذا كان قرارك التقني مبنياً على حاجة حقيقية أم على عادة.
كثيراً ما تبدأ فرق المنتجات بسؤال عن اللغة: هل نكتب بـ Swift وKotlin لكل منصة على حدة، أم نختار Flutter أو React Native لنشارك الكود؟ هذا سؤال مشروع، لكنه يأتي متأخراً. الإجابة الأدق تخرج من تفاصيل الشاشات نفسها. شاشة تعرض قائمة منتجات وتسمح بالبحث والتصفح يمكن أن تُبنى بسهولة في أي إطار عمل متقاطع، لأنها في جوهرها عرض للمحتوى من خادم. أما شاشة تقرأ من حساس البصمة، أو تفتح الكاميرا لمسح مستند، أو تشغّل مهمة في الخلفية تستمر حتى بعد إغلاق التطبيق، فهي تعتمد على إمكانات الجهاز مباشرة، وهنا تصبح الفجوة بين المنصات حقيقية.
السؤال الأول يتعلق بالكاميرا. هل تحتاج الشاشة إلى تحكم دقيق في الكاميرا، مثل التركيز اليدوي، أو معالجة الإطارات في الوقت الفعلي، أو التقاط صور بجودة معينة؟ إن كانت الإجابة نعم، فستجد أن الأطر المتقاطعة تحتاج إلى وحدات إضافية أو كتابة كود خاص بكل منصة، وقد لا يكون الفرق في الكفاءة بقدر ما هو في الصيانة.
السؤال الثاني يتعلق بالبصمة والمصادقة الحيوية. واجهات البصمة تختلف بين iOS وAndroid في طريقة الاستدعاء ومعالجة الأخطاء وتدرج الصلاحيات. التطبيق الذي يعتمد على هذه الميزة بشكل مركزي يحتاج إلى فهم عميق لكل منصة، وإن استخدم إطاراً متقاطعاً فعليه أن يتحقق من أن المكتبة التي يعتمدها تتعامل مع الحالات الحدية بالطريقة المتوقعة.
السؤال الثالث يتعلق بالمهام الخلفية. هنا تتفاوت قيود أنظمة التشغيل بشكل كبير. نظام iOS يفرض حدوداً صارمة على ما يمكن للتطبيق فعله بعد أن ينتقل إلى الخلفية، بينما يتيح Android مرونة أكبر مع قيود متزايدة في الإصدارات الحديثة. إن كان تطبيقك يرفع ملفات كبيرة، أو يزامن بيانات بشكل دوري، أو ينتظر حدثاً ليعمل، فهذه الميزة وحدها قد تحدد أن الكتابة الأصلية أقل مخاطرة.
إن كانت أغلب شاشاتك تعرض بيانات وتتيح التفاعل معها عبر النماذج والقوائم والإشعارات، وكانت الميزات الخاصة بالجهاز محدودة ولا تقع في مسار المستخدم الأساسي، فالإطار المتقاطع غالباً هو الخيار الأنسب. تحصل على قاعدة كود واحدة، وسرعة في التكرار، وفريق أصغر يصون المنتج. الخطر يكمن في أن يتضخم الاستثناء حتى يصبح القاعدة، فتجد نفسك تكتب جسوراً معقدة إلى الجهاز مع كل ميزة جديدة. لذلك راجع التصنيف كل فترة، وسجّل أي شاشة انتقلت من "محتوى فقط" إلى "تحتاج الجهاز".
اطلب من فريقك أن يملأ الجدول بشكل مستقل، ثم قارنوا النتائج. الاختلاف في التصنيف نفسه مفيد، لأنه يكشف الافتراضات المخفية. بعد ذلك، ابنِ نموذجاً أولياً صغيراً لأخطر شاشة من فئة "تحتاج الجهاز" على منصة واحدة، وراقب كم من الوقت تستغرق، وكم من الحالات الحدية تظهر. هذه البيانات أدق بكثير من أي مقارنة نظرية بين الأطر، وهي التي ستحدد لك أين تستثمر وأين توفّر.
