من UIKit إلى SwiftUI: رحلة 30 يوم لتحويل إطار عمل واجهة المستخدم

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

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

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

أدرك المطورون أن التطبيق يحتاج إلى قرار جرئ: تحويل كلي من نظام UIKit إلى نظام SwiftUI.

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

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

---

هل يصعب التحول من UIKit إلى SwiftUI iOS؟

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

• ملفات XIB
• وحدات التحكم في العرض
• واجهات SwiftUI مغلفة بـ UIKit

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

• دورة حياة التطبيق
• منطق التنقل
• مكونات نظام التصميم
• واجهات قابلة لإعادة الاستخدام
• شاشات الميزات

لم يكن حجم العمل هو التحدي الوحيد، حيث ظهرت أبعاد لتحديات أخرى. منها أن العميل يتوقع استلام مرحلة جديدة من التطبيق خلال مساحة ضيقة من الوقت، مما لا يدع مجالًا للتسويف أو تأجيل التحويل. إما الآن وإما لاحقًا، وهو ما يعني زيادة حجم العمل المطلوب.

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

لم يكن هذا المشروع استثناءً. التحدي الأكبر الذي لازمه هو أنه ينبغي تسليمه ومراجعته في مدة أقل من 30 يوم حتى لا يتعارض مع تسليم المرحلة التالية ويؤخرها. وتمت العملية بنجاح ونُفِّذ أغلب التحول من قبل مهندس واحد فقط.

---

رحلة التحول من UIKit إلى SwiftUI

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

الخطوة الأولى: إثبات المفهوم POC

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

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

تحديد الفكرة وإعداد الأهداف الرئيسية لإثبات المفهوم

التنسيق بين أصحاب المصلحة للاتفاق على نطاق العمل والخطة

وضع خطة عمل للنجاح متضمنة مؤشرات أداء رئيسية وأهداف قابلة للقياس

تعيين المشاركين في المشروع وحصر الموارد اللازمة للتنفيذ

رسم خط زمني دقيق يمكن أن يوضح الجهد المتوقع

بدء تنفيذ خطة إثبات المفهوم لتصبح جاهزة على أرض الواقع

تقييم المؤشرات المبدئية لضمان أن إثبات المفهوم يوفِّر مسار فعَّال وعملي

هذه المرحلة نجحت في إيجاد أجوبة لأهم الأسئلة التقنية المثارة لهذا المشروع وقد تواجه الفريق:

• ما المميزات والتحديات المتوقعة بعد تنفيذ التحوُّل؟
• ما تحديات التنقُل والاستخدام المتوقعة خلال فترة التحوُّل؟
• إلى أي مدى الفريق جاهز للعمل على SwiftUI؟

بالاستفادة من خبرة الفريق العملية مع استخدام UIHostingController، تم الاتفاق على استراتيجية تنقُل واضحة، مع الاعتراف بالتنازلات المعروفة وأخذها في الاعتبار منذ البداية، وتحديد القيم الأهم لهذه المرحلة.

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

الخطوة الثانية: بناء مخطط تحول ذكي

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

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

إصدارات iOS المدعومة: لتجنب تضييع الوقت أو الجهد على خصائص لا تعمل، عيِّن الفريق الحد الأدنى لإصدار iOS المدعوم. تعبر عن احتياجات المستخدم، وهو يضمن توافق تام مع جميع العناصر والمُعدِّلات المطلوبة.

قواعد بِنية SwiftUI: تطلّب الانتقال السلس معيارًا معماريًا واضحًا، لذا وضعنا مبادئنا الاسترشادية الأساسية:

• حافِظ على صغر حجم الواجهات وقابليتها للتركيب

• فضِّل التركيب على هياكل الواجهات الكبيرة والمتداخلة

• استخرج المكونات القابلة لإعادة الاستخدام في المراحل الأولى من دورة التطوير

• اجعل منطق العمل خارج الواجهات تمامًا، وفوِّضه إلى ViewModel مصممة لتخزين وإدارة البيانات المتعلقة بواجهة المستخدم

• تجنّب واجهات SwiftUI المتجانسة التي تحاول التعامل مع مسؤوليات متعددة في آن واحد

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

الخطوة الثالثة: أخطاء الملفات وتعطل التطبيق

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

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

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

أثمر هذا الجهد وتم تجميع المشروع بنجاح.

لكن تبين أن سلامة عملية البناء لم تكن سوى نصف الحقيقة.

نبدأ بالخبر السيء

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

أما عن الخبر الجيد

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

اكتملت عملية النقل بمساعدة النموذج اللغوي الكبير (LLM) خلال يومين فقط. ومع تبقي ثمانية وعشرين يومًا على الموعد النهائي، كان لدى الفريق متسع من الوقت لاستعادة الوظائف المعطلة بشكل منهجي، وفقًا للاشتراطات المتفق عليها ودون ذعر.

الخطوة الرابعة: المعالجة الهيكلية من خلال مصفوفة الأولويات

إصلاح تطبيق معطّل أمر، وإصلاحه بشكل منهجي، دون إضاعة الوقت أو الجهد أو الخروج عن نطاق العمل الأصلي، أمر آخر. أدرك الفريق أن اتباع نهج غير منظم في الحل سيكون مكلفًا تمامًا كالأخطاء نفسها.

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

إجراءات سهلة التنفيذ وعالية التأثير: مكاسب سريعة تُحقق نتائج فورية وملموسة.

سهلة التنفيذ ومنخفضة التأثير: مهام إضافية مفيدة ولكنها غير أساسية.

إجراءات تتطلب جهدًا كبيرًا وعالي التأثير: مهام رئيسية تُحسّن الأداء الوظيفي الأساسي.

تتطلب جهدًا كبيرًا ومنخفضة التأثير: مهام غير مُجزية تستهلك الموارد دون عائد مُناسب.

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

والنتيجة؟ بحلول اليوم الخامس عشر، أي منتصف المدة المحددة بثلاثين يومًا، تم حل معظم المشاكل الوظيفية.

عملية استعادة منظمة، نُفذت في نصف الوقت المتاح. وبذلك، أصبح بالإمكان تخصيص المرحلة الأخيرة لضمان الجودة وتقديم منتج متكامل وعالي الأداء.

الخطوة الخامسة: الاختبار ومراجعة طلب السحب

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

أجرى فريق ضمان الجودة دورة اختبار شاملة، غطت جميع جوانب أداء التطبيق وموثوقيته:

الوظائف

التحقق من أن جميع الخصائص تعمل كما هو مُخطط لها.

الأمان

تحديد ومعالجة الثغرات الأمنية المحتملة.

سهولة الاستخدام

ضمان بقاء تجربة المستخدم سلسة وبديهية بعد التحديث.

التراجع

التأكد من عدم إعادة إدخال أي وظيفة كانت تعمل سابقًا وهي معطلة.

التوافق

التحقق من الأداء المتسق عبر إصدارات iOS والأجهزة المدعومة.

الحمل والأداء

تقييم استقرار التطبيق واستجابته في ظروف الاستخدام الواقعية.

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

ثم، كانت مراجعة طلب سحب، والتي ضمت 1680 ملف، مهمة شاقة بكل المقاييس. وقد أثار طلب السحب عدة جولات من التعليقات من الفريق الهندسي، مما دل على دقة عملية المراجعة بما لا يقل عن جودة عملية النقل نفسها.

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

---

الاستنتاج: لماذا SwiftUI هو الخيار الأمثل؟

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

أثبت SwiftUI أنه الإطار الأمثل لتحقيق هذه الرؤية، وذلك لأسباب تقنية وعملية على حد سواء:

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

التكوين بدلاً من الوراثة: يشجع على تصميم مكونات معيارية قابلة لإعادة الاستخدام، تتوسع بسلاسة مع قاعدة التعليمات البرمجية.

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

تقليل التعليمات البرمجية المتكررة: يعني الكود المُبسط تطويرًا أسرع، وتسهيلًا أكبر في عملية الإعداد، وتقليلًا لفرص ظهور الأخطاء.

التكامل مع الأطر الحديثة: توافق سلس مع أحدث تقنيات Apple، مما يحافظ على توافق التطبيق مع نظام iOS المتطور.

إمكانية العمل عبر منصات متعددة: قاعدة تعليمات برمجية موحدة ومتكاملة، تمتد بسلاسة عبر أنظمة iOS وmacOS وwatchOS وغيرها.

مكّن SwiftUI الفريق من العمل بسرعة مضاعفَة، وتقليل تعقيد واجهة المستخدم، وتقديم قاعدة تعليمات برمجية ليست أبسط فحسب، بل مصممة أيضًا للتوسع في المستقبل.

---

فكرة أخيرة

إذا كان تطبيق شركتك يظهر نفس علامات التطبيق الذي تناولناه في المقال، من تعقيد متزايد، وتراكم الديون التقنية، وقاعدة بيانات صعبة الصيانة، فقد يكون الانتقال إلى SwiftUI هو القرار الأمثل لك.

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