لماذا وُجِدت سويفت: كيف حلت محل Objective‑C في iOS

ما الذي يغطيه هذا المقال (ولمن هو موجه)

لم تظهر سويفت لمجرد أن Apple أرادت لغة جديدة "للترفيه". بل كانت استجابة لنقاط ألم فعلية في تطوير iOS: بطء التكرار، أنماط غير آمنة يسهل كتابتها عن طريق الخطأ، وتزايد التباين بين تعقيد التطبيقات الحديثة وتصميم أوبجكتيف‑سي الأقدم.

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

ما الذي ستحصل عليه من هذا المقال

ستحصل على خط زمني واضح وخفيف—من إصدارات سويفت المبكرة إلى سلسلة أدوات مستقرة ومتبناة على نطاق واسع—دون الغوص في التفاصيل التافهة. على طول الطريق سنربط التاريخ بتبعات يومية: كيف يكتب المطورون كودًا أكثر أمانًا، كيف تطورت واجهات الـ API، ما الذي تغيّر في سير عمل Xcode، وماذا يعني "سويفت الحديثة" مع ميزات مثل التزامن وSwiftUI.

لمن هذا المقال

• مطوروا iOS الذين يريدون سياقًا لفهم لماذا تبدو سويفت مختلفة (وأين كانت الحواف الحادة).
• قادة التقنية ومديرو الهندسة الذين يقيمون التحديث: تكلفة الهجرة، القابلية للصيانة، والتوظيف.
• فرق المنتج والتسليم التي تحتاج أن تفهم لماذا "إعادة كتابة مقابل هجرة تدريجية" ليست إجابة بنعم/لا بسيطة.
• المتعلمون الذين سمعوا عبارة "Objective‑C ماتت" ويريدون نموذجًا ذهنيًا أدق.

ملاحظة سريعة عن Objective‑C

لا تزال 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 سويفت في المقام الأول

لم تصنع Apple سويفت لأن أوبجكتيف‑سي "معطلة". فقد قادت أوبجكتيف‑سي سنوات من تطبيقات iPhone وMac الناجحة. لكن مع نمو التطبيقات وكبر الفرق وتوسع الـ APIs، أصبحت تكاليف بعض الافتراضات الافتراضية في أوبجكتيف‑سي أكثر وضوحًا—خاصة عند ضرب الأخطاء الصغيرة عبر ملايين أسطر الشيفرة.

افتراضات أكثر أمانًا (مع حواف أقل)

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

تضمّن سويفت ضوابط مضمّنة: تجبرك الـ optionals على التفكير في "هل يمكن أن تختفي هذه القيمة؟"، وتقليل الأنواع القوية من سوء الاستخدام العرضي، وميزات مثل guard، شمولية switch، ومعاملات مجموعة أكثر أمانًا تدفع المزيد من الأخطاء إلى وقت الترجمة بدلًا من الإنتاج.

صياغة حديثة وإمكانات أداء أفضل

حدّثت سويفت أيضًا تجربة كتابة الكود اليومية. صياغة مختصرة، الاستنتاج النوعي، ومكتبة قياسية أغنى تجعل العديد من المهام أوضح مع أقل boilerplate من أنماط header/implementation أو الحيل المعقدة على الجينيريكس.

على مستوى الأداء، صُمِّمت سويفت للسماح بتحسينات مترجم عدوانية (خصوصًا مع أنواع القيمة والجينيريكس). هذا لا يعني أن كل تطبيق سويفت أسرع تلقائيًا من كل تطبيق أوبجكتيف‑سي، لكن يمنح Apple نموذج لغة يمكنه التطور نحو السرعة دون الاعتماد الكبير على سلوك وقت التشغيل الديناميكي.

قابلية التعلم والقراءة والصيانة طويلة الأمد

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

النتيجة: عدد أقل من أخطاء القدمين، واجهات أنظف، ولغة تدعم فرقًا كبيرة تحافظ على التطبيقات لسنوات—دون التظاهر أن أوبجكتيف‑سي لم تكن قادرة على إنجاز المهمة.