لماذا نوزع Swift وليس SwiftUI

في كل مؤتمر WWDC منذ عام 2019، تم التركيز بشكل أكبر على SwiftUI، وفي كل مرة نبدأ فيها تطوير تطبيق جديد، نجتمع كفريق واحد لنطرح السؤال نفسه: هل حان الوقت لإدخالها في تطبيقاتنا بعد؟ حتى الآن، كانت الإجابة «لا» بالنسبة للأجزاء المهمة — و«نعم» على الأرجح بالنسبة للأجزاء غير المهمة.

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

ما الذي ينجح

يُعد SwiftUI خيارًا رائعًا حقًّا لشاشات الإعدادات الثابتة، وتصميمات النماذج، وأي شيء تكون فيه شجرة العرض صغيرة وتدفق البيانات أحادي الاتجاه. ونحن نستخدمه. كما نستخدمه أيضًا للمعاينات أثناء التصميم — حيث إن حلقة التكرار فيه أسرع من تلك الموجودة في UIKit.

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

ما الذي لا ينجح (بالنسبة لنا)

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

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

المفاضلات

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

وهناك سؤال مفتوح أيضًا. تعمل تطبيقاتنا iPhone وiPad بالفعل على أجهزة Mac المزودة بشرائح Apple Silicon، كما أننا نخطط لتطوير تطبيقات أصلية لـ Mac. وإذا ساهمت SwiftUI في تسهيل مشاركة كود الواجهة عبر تلك المنصات بشكل ملحوظ، فقد يتغير هذا التقييم.

الأخطاء التي ارتكبناها

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

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