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