تعرف لماذا ابتكرت Apple سويفت، كيف حلت تدريجيًا محل Objective‑C في تطبيقات iOS، وماذا يعني هذا التحول للأدوات والتوظيف وقواعد الشفرة اليوم.

لم تظهر سويفت لمجرد أن Apple أرادت لغة جديدة "للترفيه". بل كانت استجابة لنقاط ألم فعلية في تطوير iOS: بطء التكرار، أنماط غير آمنة يسهل كتابتها عن طريق الخطأ، وتزايد التباين بين تعقيد التطبيقات الحديثة وتصميم أوبجكتيف‑سي الأقدم.
يجيب هذا المقال عن سؤال عملي: لماذا وُجدت سويفت، كيف أصبحت الافتراضية، ولماذا يؤثر ذلك التاريخ على قاعدة الشفرة وقرارات الفريق اليوم.
ستحصل على خط زمني واضح وخفيف—من إصدارات سويفت المبكرة إلى سلسلة أدوات مستقرة ومتبناة على نطاق واسع—دون الغوص في التفاصيل التافهة. على طول الطريق سنربط التاريخ بتبعات يومية: كيف يكتب المطورون كودًا أكثر أمانًا، كيف تطورت واجهات الـ API، ما الذي تغيّر في سير عمل Xcode، وماذا يعني "سويفت الحديثة" مع ميزات مثل التزامن وSwiftUI.
لا تزال Objective‑C موجودة في العديد من التطبيقات الناجحة، خاصة قواعد الشفرة القديمة وبعض المكتبات. الهدف هنا ليس إثارة الخوف ولكن الوضوح: لم تمحُ سويفت أوبجكتيف‑سي بين ليلة وضحاها؛ بل استبدلتها تدريجيًا عبر التوافق وتحولات النظام الإيكولوجي.
كانت Objective‑C أساس تطوير Apple لعقود. عندما وصل أول SDK للآيفون في 2008، كانت Objective‑C (مع إطارات Cocoa Touch) الطريقة الرئيسية لبناء التطبيقات، تمامًا كما كان الحال مع Mac OS X وCocoa. لو كتبت تطبيقات iOS في تلك السنوات الأولى، فقد تعلمت فعليًا قواعد منصة Apple عبر أوبجكتيف‑سي.
كان في أوبجكتيف‑سي الكثير من المزايا—خصوصًا عند التماشي مع "طريقة Cocoa" لبناء البرمجيات.
كان مبنيًا فوق وقت تشغيل ديناميكي قوي: الرسائل، الاستبطان، الفئات الموسعة (categories)، وmethod swizzling أتاحت أنماطًا مرنة وشعورًا بـ "الإضافة". تقاليد Cocoa مثل delegation، target–action، notifications، وKVC/KVO كانت متكاملة وموثقة جيدًا.
ولا يقل أهمية أن لديها نظامًا إيكولوجيًّا ناضجًا. أطر Apple، المكتبات الخارجية، وسنوات من إجابات Stack Overflow افترضت Objective‑C. الأدوات وواجهات البرمجة بنيت حولها، وكانت الفرق قادرة على توظيف مطورين بمهارات متوقعة.
لم تكن نقاط الألم فلسفية—بل كانت احتكاكات عملية يومية.
قد تكون Objective‑C مطوَّلة، خاصة للمهام "البسيطة". توقيعات الدوال، الأقواس، والـ boilerplate جعلت الشيفرة أطول وأصعب المسح. العديد من الواجهات كشفت عن مفاهيم مُعتمدة على المؤشرات، مما زاد فرصة الأخطاء، خصوصًا قبل انتشار ARC (Automatic Reference Counting).
كانت مشاكل الذاكرة والسلامة مصدر قلق مستمر. حتى مع ARC، ما زلت بحاجة لفهم الملكية، دورات المرجع، وكيف أن القابلية للوجود nullability قد تفاجئك أثناء التشغيل.
وكان التفاعل مع واجهات C شائعًا—وليس دائمًا ممتعًا. جسر أنواع C، التعامل مع Core Foundation، وإدارة "toll‑free bridging" أضافت عبئًا ذهنيًا لا يشعر ككتابة كود تطبيق حديث.
تعتمد قواعد شيفرة iOS القديمة على Objective‑C لأنها مستقرة، مجرّبة، ومكلفة لإعادة كتابتها. كثير من التطبيقات طويلة العمر تتضمن طبقات أوبجكتيف‑سي (أو تبعيات قديمة) لا تزال تقوم بعمل حقيقي—وبشكل موثوق.
لم تصنع Apple سويفت لأن أوبجكتيف‑سي "معطلة". فقد قادت أوبجكتيف‑سي سنوات من تطبيقات iPhone وMac الناجحة. لكن مع نمو التطبيقات وكبر الفرق وتوسع الـ APIs، أصبحت تكاليف بعض الافتراضات الافتراضية في أوبجكتيف‑سي أكثر وضوحًا—خاصة عند ضرب الأخطاء الصغيرة عبر ملايين أسطر الشيفرة.
هدف رئيسي كان جعل الأخطاء الشائعة أصعب في الكتابة. مرونة أوبجكتيف‑سي قوية، لكنها قد تخفي مشاكل حتى وقت التشغيل: إرسال رسائل إلى nil، الالتباس في أنواع id، أو سوء إدارة القابلية للوجود في الواجهات. كثير من هذه المشكلات كانت قابلة للإدارة بالانضباط، الاتفاقيات، ومراجعات جيدة—لكنها كانت مكلفة على نطاق واسع.
تضمّن سويفت ضوابط مضمّنة: تجبرك الـ optionals على التفكير في "هل يمكن أن تختفي هذه القيمة؟"، وتقليل الأنواع القوية من سوء الاستخدام العرضي، وميزات مثل guard، شمولية switch، ومعاملات مجموعة أكثر أمانًا تدفع المزيد من الأخطاء إلى وقت الترجمة بدلًا من الإنتاج.
حدّثت سويفت أيضًا تجربة كتابة الكود اليومية. صياغة مختصرة، الاستنتاج النوعي، ومكتبة قياسية أغنى تجعل العديد من المهام أوضح مع أقل boilerplate من أنماط header/implementation أو الحيل المعقدة على الجينيريكس.
على مستوى الأداء، صُمِّمت سويفت للسماح بتحسينات مترجم عدوانية (خصوصًا مع أنواع القيمة والجينيريكس). هذا لا يعني أن كل تطبيق سويفت أسرع تلقائيًا من كل تطبيق أوبجكتيف‑سي، لكن يمنح Apple نموذج لغة يمكنه التطور نحو السرعة دون الاعتماد الكبير على سلوك وقت التشغيل الديناميكي.
احتاجت Apple أن يكون تطوير iOS قابلًا للوصول للمطورين الجدد ومستدامًا للمنتجات طويلة العمر. تهدف قواعد تسمية واجهات برمجة التطبيقات في سويفت، والإيضاح في مواقع الاستدعاء، والتركيز على أنواع معبرة إلى تقليل "المعرفة القبلية" وجعل قواعد الشيفرة أسهل للقراءة بعد أشهر.
النتيجة: عدد أقل من أخطاء القدمين، واجهات أنظف، ولغة تدعم فرقًا كبيرة تحافظ على التطبيقات لسنوات—دون التظاهر أن أوبجكتيف‑سي لم تكن قادرة على إنجاز المهمة.
تمت صناعة سويفت لتقليل مخاطر تطوير iOS الشائعة (مثل سلوك nil غير المتوقع والأنواع الفضفاضة)، وتحسين قابلية القراءة والصيانة لقاعدة الشفرة الكبيرة، وتمكين تحسينات أقوى من المترجم مع مرور الوقت. لم يكن الهدف القول إن أوبجكتيف‑سي "سيئ"—بل جعل الافتراضات الآمنة والافتراضية أسهل للاستخدام على نطاق واسع.
أصبحت سويفت اللغة الافتراضية تدريجيًا عبر مزيج من العوامل:
هذا جعل "كتابة كود جديد بسويفت" الخيار الأقل مقاومة لمعظم الفرق.
قدّمت سويفت 5 استقرار ABI على منصات Apple، مما يعني أن الشيفرة المترجمة لسويفت يمكن أن تظل متوافقة ثنائيًا عبر إصدارات runtime لسويفت 5 المرافقة للنظام. عمليًا، هذا خفّض الحاجة لتضمين مكتبات سويفت داخل التطبيق، حسّن حجم التطبيقات وموثوقية النشر، وجعل سويفت تبدو أكثر أمانًا للاستخدام في قواعد الشفرة طويلة العمر.
يمكنك المزج بين اللغتين داخل نفس هدف التطبيق:
YourModuleName-Swift.h) يعرّض APIs المتوافقة مع أوبجكتيف‑سي، عادةً باستخدام @objc و/أو الوراثة من NSObject.ليست كل ميزات سويفت مرئية للأوبجكتيف‑سي، لذا خطّط لحدود واضحة بين الطبقات.
الـ optionals (T?) تجعل قيمة "مفقودة" صريحة وتفرض التعامل معها وقت الترجمة (مثل if let، guard، ??). في أوبجكتيف‑سي، إرسال رسالة إلى nil أو التباس القابلية للوجود قد يخفي أخطاء حتى وقت التشغيل. الفائدة العملية هي تقليل حالات الانهيار وأخطاء المنطق المتعلقة بالقيم الفارغة.
الجينيريكس والأنواع الصارمة في سويفت تقلّلان من الcasting وفحوصات النوع في وقت التشغيل (التي كانت شائعة مع id وهياكل غير مكتوبة في أوبجكتيف‑سي). عمليًا تحصل على:
[User] بدلًا من "مصفوفة لأي شيء".نعم—أوبجكتيف‑سي ما يزال منطقيًا عندما تحتاج حقًا للديناميكية في وقت التشغيل (مثل استخدام مكثف لـ KVC/KVO، method swizzling، APIs المبنية على selectors، أو بعض معماريات الإضافات plugin-style). سويفت يمكن أن تتعاون مع هذه الأنماط، لكن الاستعاضة النقية في سويفت قد تتطلب إعادة تصميم بدلاً من ترجمة مباشرة.
نهج عملي هو الهجرة التدريجية:
عامل الهجرة كإدارة مخاطر: استمر في الإصدار مع تقليل عبء الصيانة على المدى الطويل.
المشاكل الشائعة تشمل:
@objc, NSObject, وميزات محدودة).خطّط للحدود وأضف اختبارات قبل تبديل التنفيذ.
على الإطلاق لا. الكثير من التطبيقات في الإنتاج هجينة:
UIHostingController لدمج شاشات SwiftUI داخل UIKit.هذا يتيح للفرق تبنّي SwiftUI حيث يقلل الضرائب مع الاحتفاظ ببنية UIKit الناضجة والمكونات المعقدة.