تطوير Swift

SwiftUI مقابل UIKit: ماذا تستخدم؟

يحل SwiftUI وUIKit جوانب مختلفة من مشكلة بناء واجهات iOS. يساعدك فهم نماذجهما على اختيار النهج المناسب بدل التعامل مع القرار وكأنه اختيار نهائي لا يمكن تغييره.

مدونة SwiftBuilder · SwiftUI · UIKit · تطوير iOS
إجابة سريعة

ما الفرق بين SwiftUI وUIKit؟

يستخدم SwiftUI نهجًا تصريحيًا يعتمد على الحالة لبناء الواجهات، بينما يستخدم UIKit نموذجًا أكثر إجرائية يعتمد على الـ Views والـ View Controllers ودوال دورة الحياة والتحديثات المباشرة للواجهة. ويمكن استخدام الإطارين معًا، لذلك يعتمد الاختيار على طبيعة المشروع، وقاعدة الكود الحالية، والواجهات البرمجية المطلوبة، وتعقيد الواجهة التي يتم بناؤها.

↔

نهجان مختلفان لبناء الواجهات

SwiftUI وUIKit هما إطارا واجهات من Apple، لكن كلًا منهما يتعامل مع تطوير الواجهة من منظور مختلف.

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

أما UIKit فيتبع نموذجًا أكثر إجرائية. يعمل المطور مباشرة مع الـ Views والـ View Controllers ودوال دورة الحياة وتغييرات الواجهة.

SwiftUI

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

UIKit

أنشئ الواجهات وأدرها مباشرة من خلال الـ Controllers والكائنات والعمليات الإجرائية.

لماذا يبدو SwiftUI مختلفًا؟

لنفترض أن لدينا حالة بسيطة. في SwiftUI، يمكن أن يؤدي تغيير هذه الحالة إلى إعادة حساب محتوى الـ View. ويركز المطور بشكل أساسي على العلاقة بين الحالة والواجهة.

SwiftUI
struct CounterView: View { @State private var count = 0 var body: some View { VStack { Text("Count: \(count)") Button("Increment") { count += 1 } } } }

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

متى يظل UIKit مناسبًا؟

لا يزال UIKit مهمًا جدًا في التطبيقات الحالية وفي الحالات التي تكون فيها واجهاته البرمجية الناضجة ومنظومته المتكاملة مفيدة.

  • قواعد أكواد كبيرة موجودة مسبقًا ومبنية باستخدام UIKit.
  • الفرق التي تحافظ على معماريات View Controller مستقرة ومستخدمة بالفعل.
  • المكونات أو الـ APIs التي تعتمد بشكل أساسي على UIKit.
  • المشاريع التي قد تؤدي فيها إعادة كتابة واجهة تعمل بالفعل إلى مخاطر غير ضرورية.

SwiftUI مفيد بشكل خاص للواجهات الجديدة

بالنسبة إلى تطبيق Swift جديد، يمكن أن يوفر SwiftUI طريقة واضحة لتركيب الواجهات ونمذجة حالة الـ UI.

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

لا يتعين عليك اختيار واحد فقط

من أهم الأمور التي يجب فهمها أن SwiftUI وUIKit ليسَا متعارضين ولا يستبعد أحدهما الآخر.

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

استضافة SwiftUI داخل UIKit
let controller = UIHostingController( rootView: ProfileView() ) navigationController? .pushViewController( controller, animated: true )

ماذا عن الأداء؟

يجب تقييم الأداء وفق التطبيق الفعلي بدل افتراض أن أحد الإطارين أسرع دائمًا من الآخر.

يمكن أن يكون للمعمارية، وحجم العمل المنفذ، وتدفق البيانات، وسلوك الرسم، وتفاصيل التنفيذ تأثير أكبر من مجرد اختيار SwiftUI أو UIKit.

ماذا يجب أن يتعلم المبتدئ؟

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

بعد ذلك، يظل تعلم UIKit مهمًا. فهو يمنحك القدرة على فهم وتعديل قدر كبير من برمجيات iOS الموجودة بالفعل.

مسار عملي للتعلم:
تعلّم Swift ← تعلّم SwiftUI ← ابنِ مشاريع ← افهم UIKit ← تعلّم كيفية دمجهما معًا.

القرار الحقيقي يتعلق بالتعقيد

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

في تطبيق SwiftUI جديد، قد يكون إدخال UIKit تعقيدًا غير ضروري. وفي تطبيق UIKit ناضج، قد تؤدي إعادة كتابة كل شاشة باستخدام SwiftUI إلى عمل إضافي غير ضروري.

المطور القوي في iOS ليس مقيدًا بإطار واحد. بل يفهم المفاضلات ويمكنه العمل مع كليهما عندما يتطلب المشروع ذلك.

ابنِ باستخدام Swift.

استخدم SwiftBuilder لإنشاء كود Swift وSwiftUI، وتجربة الواجهات، وتطوير تطبيقك بشكل متكرر.

تنزيل SwiftBuilder