AskCleanAskClean

احذف Xcode DerivedData وذاكرات المطوّرين المؤقتة بأمان

AskClean Team · Updated 2026-07-18

DerivedData هو مجلد المسودات في Xcode لنواتج البناء والفهارس، وقد يتضخم بصمت إلى عشرات الغيغابايتات. وحذفه آمن: أنهِ Xcode، وأزل محتويات ~/Library/Developer/Xcode/DerivedData، وسيعيد Xcode بناء كل شيء عند البناء التالي. يغطي هذا الدليل ذلك، إضافةً إلى المحاكيات والأرشيفات وذاكرات الحزم.

ما هو DerivedData ولماذا يتضخم

DerivedData هو المكان الذي يحفظ فيه Xcode كل ما يشتقّه من شفرتك المصدرية: كائنات البناء الوسيطة، والنواتج المُصرَّفة، وذاكرات الوحدات المؤقتة، وفهارس الرموز لإكمال الكود والقفز إلى التعريف، وسجلات البناء. ويقع افتراضيًا في ~/Library/Developer/Xcode/DerivedData، بمجلد فرعي واحد لكل مشروع أو مساحة عمل فتحتها يومًا.

وينمو لسبب بنيوي: ينشئ Xcode مجلد DerivedData لكل مشروع تفتحه — بما في ذلك النسخ المستنسخة العابرة التي بنيتها مرة ولم تلمسها مجددًا — ولا يحذف أيًا منها أبدًا. ويحوي كل مجلد نواتج بناء منفصلة لكل تكوين ووجهة (Debug وRelease، محاكٍ وجهاز)، فقد يشغل مشروع متوسط الحجم واحد عدة غيغابايتات، ويبلغ المجلد بمجمله عادةً 20-50 GB على جهاز تطوير عامل.

كل ما فيه قابل لإعادة الإنشاء بحكم التعريف — فهذا معنى «مشتق». حذف DerivedData لا يمس أبدًا شفرتك المصدرية ولا إعدادات مشروعك ولا أي شيء خاضع لإدارة الإصدارات. الكلفة الوحيدة هي الوقت: البناء التالي لكل مشروع بناء نظيف كامل، والفهرسة تعمل مجددًا في الخلفية لبضع دقائق.

احذف DerivedData

هناك ثلاث طرق لفعل ذلك، وكلها تنتهي إلى النتيجة نفسها. أمر Clean Build Folder في Xcode (Product > Clean Build Folder أو Command-Shift-K) لا يمسح إلا نواتج بناء المشروع المفتوح حاليًا — مفيد لإصلاح بناء غريب، لكنه بالكاد يحرّك مؤشر مساحة القرص. لاسترداد مساحة حقيقية، احذف مجلدات DerivedData نفسها.

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

  1. أنهِ Xcode أولًا. حذف DerivedData وXcode يعمل قد يترك مفهرِسه في حالة اضطراب، والملفات التي يفتحها Xcode قد لا تُحذف حذفًا نظيفًا.
  2. اعثر على المجلد: في Xcode، افتح Settings > Locations وانقر السهم الصغير بجوار مسار DerivedData لإظهاره في Finder. أو في Finder اضغط Command-Shift-G وأدخل ~/Library/Developer/Xcode/DerivedData مباشرة.
  3. رتّب مجلدات المشاريع الفرعية بحسب الحجم، وحدد ما تريد التخلص منه (أو Command-A لتحديدها كلها)، وانقلها إلى سلة المهملات. سلة المهملات أولًا هي العادة الأسلم — تستعيد فورًا إن غيّرت رأيك.
  4. من Terminal بدلًا من ذلك: الأمر rm -rf ~/Library/Developer/Xcode/DerivedData يحذف كل شيء دفعة واحدة. وهو أسرع من Finder مع المجلدات الضخمة جدًا، لكن اقرأ الملاحظة أدناه قبل استخدامه.
  5. أعد فتح Xcode وابنِ. توقّع أن يستغرق أول بناء لكل مشروع وقتًا أطول ملحوظًا، وأن ترى "Indexing" يعمل في شريط النشاط لبرهة — وكلاهما كلفة لمرة واحدة.

احذر مع rm -rf: فهو يتجاوز سلة المهملات ويحذف نهائيًا دون تراجع. اكتب المسار بدقة تامة، ولا تشغّله أبدًا بـ sudo لهذه المهمة، وإن لم تكن مرتاحًا في Terminal، فطريق Finder يؤدي المهمة نفسها بشكل قابل للتراجع.

امسح بيئات تشغيل المحاكي القديمة

المحاكيات عادةً ثاني أكبر مستهلك لمساحة المطوّرين بعد DerivedData. كل بيئة تشغيل iOS أو watchOS أو tvOS نزّلتها يومًا تشغل 5-8 GB، وكل جهاز محاكى يحتفظ بمجلد بياناته الخاص تحت ~/Library/Developer/CoreSimulator/Devices. وإن كنت قد مررت ببضع ترقيات لـ Xcode، فلديك على الأرجح بيئات تشغيل لإصدارات iOS توقفت عن استهدافها منذ سنين.

المكسب الأسرع هو أمر التنظيف المدمج: شغّل xcrun simctl delete unavailable في Terminal. فهو يحذف كل جهاز محاكٍ لم تعد بيئة تشغيله مثبتة — الأيتام التي خلّفتها إصدارات Xcode القديمة — ولا يمس شيئًا ما زال بإمكانك استخدامه.

أما بيئات التشغيل نفسها، فافتح Settings > Platforms في Xcode (كانت تُسمى Components في إصدارات Xcode الأقدم). سترى كل بيئة تشغيل محاكٍ مثبتة مع حجمها؛ حدد قديمة واحذفها. لا تُبقِ إلا أحدث بيئة تشغيل لكل منصة ما لم تختبر فعليًا على إصدارات أنظمة أقدم.

يمكنك أيضًا تشذيب الأجهزة المحاكاة فرادى في Window > Devices and Simulators: انتقل إلى تبويب Simulators، وانقر بالزر الأيمن أي جهاز لا تستخدمه أبدًا — نماذج iPhone الستة المكررة ببيانات من جولات اختبار قديمة — واختر Delete. وتذهب معه بياناته المحفوظة وتطبيقاته.

الأرشيفات وملفات دعم الأجهزة والذاكرات المؤقتة

تتراكم الأرشيفات في ~/Library/Developer/Xcode/Archives في كل مرة تشغّل Product > Archive لتوزيع نسخة. يحوي كل أرشيف نسخة كاملة من التطبيق مع رموز التصحيح dSYM الخاصة بها، وغالبًا ما يبلغ 100 MB إلى 1 GB للواحد. قبل الحذف، اعرف المقايضة: رموز dSYM بداخله هي ما يتيح لك فك رموز تقارير الأعطال لتلك النسخة بعينها. أبقِ أرشيفات الإصدارات التي ما زالت حية على App Store أو TestFlight (أو تأكد أن App Store Connect يحتفظ برموز dSYM)، واحذف البقية — والطريق الأسلم هو منظّم Xcode (Window > Organizer > Archives) حيث تراجعها وتحذفها بسياقها.

iOS DeviceSupport، في ~/Library/Developer/Xcode/iOS DeviceSupport، يحوي رموز تصحيح ينسخها Xcode من كل جهاز iPhone أو iPad فعلي وصّلته يومًا — مجلد لكل إصدار iOS، بحجم 2-5 GB عادةً لكل واحد. ومجلدات إصدارات iOS التي لا يعمل بها أي من أجهزتك بعد الآن عبء ميت خالص: احذفها، وإن وصّلت يومًا جهازًا بذلك الإصدار مجددًا، فسيعيد Xcode نسخ الرموز ببساطة (سترى "Preparing debugger support" مرة واحدة). وتوجد مجلدات شقيقة لأجهزة watchOS وtvOS أيضًا.

يحتفظ Xcode كذلك بذاكراته المؤقتة الخاصة تحت ~/Library/Caches/com.apple.dt.Xcode، وتحتفظ المحاكيات بذاكراتها في ~/Library/Developer/CoreSimulator/Caches — وكلاهما آمن المسح حين لا يكون Xcode وتطبيق المحاكي قيد التشغيل، وكلاهما يُعاد بناؤه عند الطلب.

ذاكرات مديري الحزم (SwiftPM وCocoaPods وnpm وHomebrew)

يحتفظ مديرو الحزم بكل تبعية نزّلوها يومًا لتكون عمليات التثبيت المستقبلية سريعة. وهذه هندسة جيدة ونظافة قرص سيئة: الذاكرات لا تفعل إلا أن تنمو، وعلى جهاز شهد بضع سنين من المشاريع تتراكم بصمت إلى 10-20 GB. وكلها آمنة المسح — أسوأ الاحتمالات أن يعيد التثبيت التالي تنزيل الحزم.

يخزّن Swift Package Manager الحزم المنزَّلة مؤقتًا في ~/Library/Caches/org.swift.swiftpm، كما تقيم النسخ المستخرجة المحسومة لكل مشروع داخل مجلد DerivedData الخاص به — فمسح DerivedData يمسح تلك أصلًا. أما الذاكرة المشتركة فتحذفها من Finder، أو بـ rm -rf على ذلك المسار.

يحتفظ CocoaPods بحزم pods المنزَّلة في ~/Library/Caches/CocoaPods. والطريقة النظيفة لإفراغها هي الأمر المدمج: pod cache clean --all. مجلدات Pods في مشاريعك لا تُمسّ؛ ذاكرة التنزيل وحدها هي التي تذهب.

تقيم ذاكرة npm في ~/.npm وقد تبلغ غيغابايتات عديدة على جهاز مكثّف الاستخدام لـ JavaScript. شغّل npm cache clean --force لإفراغها (يصرّ npm على العلم لأن الذاكرة ذاتية الإصلاح ولا تحتاج عادةً إلى تنظيف — ومع ذلك يبقى حذفها آمنًا تمامًا). ومستخدمو pnpm يمكنهم تشغيل pnpm store prune بدلًا من ذلك.

يكدّس Homebrew التنزيلات القديمة وإصدارات الحزم المتقادمة. الأمر brew cleanup يزيل الإصدارات المتقادمة والتنزيلات الراكدة؛ وbrew cleanup --prune=all يفرغ أيضًا ذاكرة التنزيل بأكملها. شغّل brew cleanup -n أولًا إن أردت قائمة تجريبية بما سيذهب.

أتمِت الأمر

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

يعامل AskClean ملفات المطوّرين كفئات من الدرجة الأولى: فحص واحد يفصّل Xcode DerivedData لكل مشروع، وبيئات تشغيل المحاكي القديمة (تُقرأ عبر simctl مع الاحتفاظ بالأحدث لكل منصة)، وملفات دعم الأجهزة، وذاكرات مديري الحزم لـ npm وSwiftPM وcargo وuv وغيرها. كما يلتقط مستهلكي المساحة الأحدث — ذاكرات نماذج Hugging Face وOllama — التي يسردها لكل نموذج ويتركها غير محددة افتراضيًا.

كل عنصر يأتي مع شرح — ما هو، وهل يمكن إعادة بنائه، وما كلفة حذفه — ولا شيء يُنفَّذ قبل أن تؤكده. المحذوفات تذهب إلى سلة المهملات فتصبح النقرة الخاطئة على بُعد سحبة واحدة من التراجع، وشفرتك المصدرية ومستنداتك وصورك لا تُمسّ أبدًا. إنها قائمة التحقق نفسها الواردة في هذا الدليل، ناقص ساعة العمل في Terminal.

FAQ

هل حذف DerivedData آمن؟

نعم — إنه من أكثر عمليات الحذف الكبيرة أمانًا على جهاز Mac. لا يحوي DerivedData إلا ملفات يولّدها Xcode من مصدرك: نواتج البناء وذاكرات الوحدات المؤقتة والفهارس والسجلات. أما شفرتك وملفات مشروعك وتاريخ git فتقيم في مكان آخر ولا تتأثر أبدًا. العاقبة الوحيدة أن البناء التالي لكل مشروع إعادة بناء كاملة، والفهرسة تعمل من جديد.

كم مرة ينبغي أن أمسح DerivedData؟

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

هل سيصبح Xcode أبطأ بعد حذف DerivedData؟

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

وماذا عن ~/Library/Developer/CoreSimulator — هل يمكنني حذفه؟

ليس على عماها — فهو يحوي محاكياتك المثبتة حاليًا وبياناتها، وحذفه بالجملة يعطّلها حتى تعيد تثبيت بيئات التشغيل. شذّبه بالطريقة الصحيحة بدلًا من ذلك: شغّل xcrun simctl delete unavailable للأجهزة اليتيمة، وأزل بيئات التشغيل القديمة في Settings > Platforms بـ Xcode، واحذف الأجهزة غير المستخدمة في Devices and Simulators، وامسح يدويًا المجلد الفرعي Caches وحده.

هل يؤدي Clean Build Folder الغرض نفسه؟

لا. أمر Product > Clean Build Folder (Command-Shift-K) يمسح نواتج بناء المشروع الحالي فقط، ويُبقي الفهارس وذاكرات الوحدات المؤقتة ومجلدات كل مشروع آخر في مكانها. إنه أداة لاستكشاف مشاكل البناء لا أداة لمساحة القرص — واسترداد مساحة حقيقية يعني حذف مجلدات DerivedData نفسها.

Sources