AskCleanAskClean

מחיקה בטוחה של Xcode DerivedData ומטמוני מפתחים

AskClean Team · Updated 2026-07-18

DerivedData היא תיקיית העבודה של Xcode לתוצרי בנייה ואינדקסים, והיא יכולה לגדול בשקט לעשרות ג'יגה-בייטים. בטוח למחוק אותה: סוגרים את Xcode, מסירים את התוכן של ~/Library/Developer/Xcode/DerivedData, ו-Xcode בונה הכול מחדש בבנייה הבאה. המדריך הזה מכסה את זה — וגם סימולטורים, ארכיונים ומטמוני חבילות.

מה זה DerivedData ולמה הוא נהיה ענק

DerivedData הוא המקום שבו Xcode שומר כל מה שהוא גוזר מקוד המקור שלכם: אובייקטי בנייה ביניים, מוצרים מקומפלים, מטמוני מודולים, אינדקסי סמלים להשלמת קוד ולקפיצה להגדרה, ויומני בנייה. כברירת מחדל הוא נמצא ב-~/Library/Developer/Xcode/DerivedData, עם תת-תיקייה אחת לכל פרויקט או workspace שפתחתם אי-פעם.

הוא גדל מסיבה מבנית: Xcode יוצר תיקיית DerivedData לכל פרויקט שאתם פותחים — כולל שיבוטים חד-פעמיים שבניתם פעם אחת ולא נגעתם בהם שוב — והוא לעולם לא מוחק אף אחת מהן. כל תיקייה מחזיקה תוצרי בנייה נפרדים לכל תצורה ויעד (Debug ו-Release, סימולטור ומכשיר), כך שפרויקט בינוני בודד יכול לתפוס כמה ג'יגה-בייטים, והתיקייה כולה מגיעה בדרך כלל ל-20-50 GB במחשב פיתוח פעיל.

כל מה שבפנים ניתן לשחזור מעצם הגדרתו — זה בדיוק מה ש"derived" (נגזר) אומר. מחיקת 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 ישנות השאירו מאחור — ולא נוגעת בשום דבר שאתם עדיין יכולים להשתמש בו.

עבור סביבות הריצה עצמן, פתחו ב-Xcode את Settings > Platforms (שנקרא Components בגרסאות Xcode ישנות יותר). תראו כל סביבת סימולטור מותקנת עם הגודל שלה; בחרו ישנה ומחקו אותה. השאירו רק את סביבת הריצה העדכנית ביותר לכל פלטפורמה, אלא אם אתם בודקים באופן פעיל על גרסאות מערכת ישנות.

אפשר גם לגזום מכשירים מדומים בודדים ב-Window > Devices and Simulators: עברו ללשונית Simulators, לחצו לחיצה ימנית על כל מכשיר שאתם אף פעם לא משתמשים בו — ששת דגמי ה-iPhone הכפולים עם נתונים מריצות בדיקה ישנות — ובחרו Delete. הנתונים והאפליקציות השמורים של כל מכשיר נמחקים איתו.

ארכיונים, קובצי תמיכת מכשירים ומטמונים

ארכיונים מצטברים ב-~/Library/Developer/Xcode/Archives בכל פעם שאתם מריצים Product > Archive כדי להפיץ בנייה. כל ארכיון מכיל בניית אפליקציה מלאה בתוספת סמלי הדיבוג dSYM שלה — לרוב 100 MB עד 1 GB כל אחד. לפני שמוחקים, הכירו את המחיר: קובצי ה-dSYM שבפנים הם מה שמאפשר לפענח (symbolicate) דוחות קריסה של אותה בנייה בדיוק. שמרו ארכיונים של גרסאות שעדיין חיות ב-App Store או ב-TestFlight (או ודאו של-App Store Connect יש את ה-dSYM), ומחקו את השאר — המסלול הבטוח ביותר הוא ה-Organizer של 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, וה-checkouts שנפתרו של כל פרויקט חיים גם בתוך תיקיית ה-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