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

מה זה DerivedData ולמה היא תופחת כל כך
DerivedData היא התיקייה שבה Xcode שומר את כל מה שהוא מפיק מקוד המקור שלכם: קובצי ביניים של הבנייה, תוצרים מהודרים, מטמוני מודולים, אינדקסי סמלים להשלמת קוד ולמעבר להגדרה (Jump to Definition), ויומני בנייה. כברירת מחדל היא נמצאת ב-~/Library/Developer/Xcode/DerivedData, עם תת-תיקייה לכל פרויקט או workspace שפתחתם אי-פעם.
היא גדלה מסיבה מבנית: Xcode יוצר תיקיית DerivedData לכל פרויקט שאתם פותחים — כולל מאגרים ששכפלתם, בניתם פעם אחת ולא חזרתם אליהם — ואינו מוחק אותן מיוזמתו. כל תיקייה מחזיקה תוצרי בנייה נפרדים לכל תצורה ויעד (Debug ו-Release, סימולטור ומכשיר), ולכן מדדו את תת-התיקיות של הפרויקטים במקום לנחש כמה מקום יתפנה אצלכם.
כל מה שבתוכה אפשר ליצור מחדש, מעצם ההגדרה — זה בדיוק פירוש המילה “derived” (נגזר). מחיקת DerivedData אף פעם לא נוגעת בקוד המקור, בהגדרות הפרויקט או בשום דבר שנמצא בניהול גרסאות. המחיר היחיד הוא זמן: הבנייה הבאה של כל פרויקט תהיה בנייה נקייה מלאה, והאינדוקס ירוץ שוב ברקע במשך כמה דקות.
איך למחוק את DerivedData
הפקודה Clean Build Folder של Xcode (Product > Clean Build Folder, או Shift-Command-K) מנקה תוצרי בנייה רק של הפרויקט שפתוח כרגע — שימושית לתיקון בנייה שמתנהגת מוזר, אבל כמעט לא משפיעה על המקום בדיסק. כדי לפנות מקום של ממש, מחקו את תיקיות ה-DerivedData עצמן: אפשר להגיע אליהן מהגדרות Locations של Xcode, לפתוח את התיקייה ב-Finder או למחוק אותן במסוף. שלוש הדרכים מובילות לאותה תוצאה.
מחיקה לפי פרויקט היא האפשרות המדויקת: השאירו את DerivedData של שניים-שלושה הפרויקטים שאתם בונים מדי יום, ומחקו את התיקיות של כל השאר. מחיקת הכול היא האפשרות המהירה, וגם היא בסדר — פשוט תשלמו את מחיר הבנייה המלאה מחדש בכל הפרויקטים בבת אחת.
- צאו קודם מ-Xcode. מחיקת DerivedData בזמן ש-Xcode פועל עלולה לבלבל את מנגנון האינדוקס, וקבצים ש-Xcode מחזיק פתוחים עלולים לא להימחק כמו שצריך.
- אתרו את התיקייה: ב-Xcode פתחו Settings > Locations ולחצו על החץ הקטן שליד הנתיב של DerivedData כדי להציג אותו ב-Finder. לחלופין, ב-Finder הקישו Command-Shift-G והזינו ישירות ~/Library/Developer/Xcode/DerivedData.
- מיינו את תת-התיקיות של הפרויקטים לפי גודל, בחרו את אלה שתרצו למחוק (או Command-A כדי לבחור את כולן) והעבירו אותן לפח האשפה. העברה לפח האשפה היא ההרגל הבטוח יותר — אם תתחרטו, אפשר לשחזר מיד.
- לחלופין, במסוף: הפקודה rm -rf ~/Library/Developer/Xcode/DerivedData מוחקת הכול בבת אחת. זה מהיר יותר מ-Finder בתיקיות גדולות מאוד, אבל קראו את ההערה שלמטה לפני השימוש.
- פתחו שוב את Xcode ובנו. הבנייה הראשונה של כל פרויקט תימשך זמן רב יותר באופן ניכר, וההודעה “Indexing” תוצג בסרגל הפעילות לזמן מה — שתיהן עלויות חד-פעמיות.
היזהרו עם rm -rf: הפקודה עוקפת את פח האשפה ומוחקת לצמיתות, בלי אפשרות לבטל. הקלידו את הנתיב במדויק, אל תריצו אותה עם sudo למשימה הזו, ואם אינכם מרגישים בנוח במסוף — מחיקה ב-Finder עושה את אותה עבודה ומשאירה אפשרות לשחזר.
ניקוי סביבות הרצה ישנות של הסימולטור
סימולטורים הם לעיתים קרובות עוד קטגוריה גדולה באחסון של מפתחים. כל סביבת הרצה של iOS, watchOS או tvOS שהורדתם תופסת מקום משלה, וכל מכשיר מדומה שומר נתונים תחת ~/Library/Developer/CoreSimulator/Devices. אם עברתם כמה שדרוגים של Xcode, בדקו אם נשארו סביבות הרצה של גרסאות מערכת שכבר יצאו ממטריצת הבדיקות שלכם.
הצעד המהיר ביותר הוא פקודת הניקוי המובנית: הריצו במסוף xcrun simctl delete unavailable. הפקודה מוחקת כל מכשיר סימולטור שמסומן unavailable (לא זמין) — בעיקר מכשירים יתומים שנשארו אחרי הסרת סביבות הרצה וגרסאות Xcode ישנות — יחד עם האפליקציות והנתונים שבתוכם. עברו קודם על הרשימה עם xcrun simctl list devices, במיוחד אם מותקנת אצלכם יותר מגרסה אחת של Xcode.
את סביבות ההרצה עצמן הסירו ב-Xcode: פתחו Settings > Components (ב-Xcode 14–15 החלונית נקראת Platforms). שם מוצגת כל סביבת הרצה מותקנת עם הגודל שלה; בחרו סביבה ישנה ומחקו אותה. השאירו רק את סביבת ההרצה העדכנית לכל פלטפורמה, אלא אם אתם בודקים באופן פעיל בגרסאות מערכת ישנות יותר.
אפשר גם למחוק מכשירים מדומים בודדים ב-Window > Devices and Simulators: עברו ללשונית Simulators, לחצו לחיצה ימנית על מכשיר שאינכם משתמשים בו — למשל שישה דגמי iPhone כפולים עם נתונים מהרצות בדיקה ישנות — ובחרו Delete. הנתונים והאפליקציות שבמכשיר נמחקים יחד איתו.
Archives, קובצי DeviceSupport ומטמונים
Archives מצטברים ב-~/Library/Developer/Xcode/Archives בכל פעם שאתם מריצים Product > Archive כדי להפיץ build. כל archive מכיל build מלא של האפליקציה ואת סמלי ניפוי השגיאות (dSYM) שלו — לרוב 100 MB עד 1 GB כל אחד. לפני שמוחקים, הבינו מה המחיר: קובצי ה-dSYM שבתוכם הם שמאפשרים לפענח (symbolicate) דוחות קריסה של אותו build בדיוק. שמרו archives של גרסאות שעדיין זמינות ב-App Store או ב-TestFlight (או ודאו שה-dSYM נמצאים ב-App Store Connect), ומחקו את השאר. הדרך הבטוחה ביותר היא ה-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 ואפליקציית Simulator סגורים, ואל תגעו בקובצי מטמון של CoreSimulator שאינכם מזהים.
מטמוני מנהלי חבילות (SwiftPM, CocoaPods, npm, Homebrew)
מנהלי חבילות שומרים תלויות שהורדו כדי שהתקנות עתידיות יהיו מהירות. זה שימושי, אבל במחשב שעבר שנים של פרויקטים זו עלולה להפוך לקטגוריה גדולה בדיסק. אפשר ליצור את מטמוני ההורדות האלה מחדש, אבל ההתקנה הבאה תצטרך להוריד שוב את החבילות.
Swift Package Manager שומר חבילות שהורדו ב-~/Library/Caches/org.swift.swiftpm, ועותקי ה-checkout של התלויות שנפתרו בכל פרויקט נמצאים גם בתוך תיקיית ה-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 מסירה גרסאות מיושנות והורדות ישנות (וכשמריצים אותה בלי שמות של חבילות, גם תלויות שאף חבילה כבר לא צריכה, אלא אם HOMEBREW_NO_AUTOREMOVE מוגדר), ו-brew cleanup --prune=all מרוקנת גם את כל מטמון ההורדות. אם תרצו לראות קודם רשימה של מה שיימחק בלי למחוק דבר (dry run), הריצו brew cleanup -n.
אוטומציה של הניקוי
כל מה שלמעלה עובד, אבל זבל פיתוח חוזר כל הזמן: DerivedData מתמלאת שוב אחרי שבוע של עבודה רגילה, המטמונים מתמלאים מחדש, וכל עדכון של Xcode משאיר אחריו עוד סביבת הרצה. אם אינכם רוצים לחזור על שישה תהליכים ידניים בכל חודש, זה החלק ששווה להפוך לאוטומטי — עם כלי שמסביר את השיקולים שלו במקום למחוק בשקט הכול בבת אחת.
AskClean מתייחס לקובצי פיתוח כקטגוריות בפני עצמן: סריקה אחת מפרטת את Xcode DerivedData לפי פרויקט, סביבות הרצה ישנות של הסימולטור (נקראות דרך simctl, והעדכנית ביותר לכל פלטפורמה נשמרת), קובצי DeviceSupport ומטמוני מנהלי חבילות של npm, SwiftPM, cargo, uv ועוד. הוא מזהה גם את צרכני המקום החדשים — מודלי AI מקומיים: מודלי Hugging Face מוצגים אחד-אחד, וספריית המודלים של Ollama מוצגת כפריט אחד. כולם לא מסומנים כברירת מחדל.
כל פריט מגיע עם הסבר — מה הוא, אם אפשר לבנות אותו מחדש ומה המחיר של מחיקתו — ושום דבר לא מתבצע לפני שאישרתם. פריטים שאישרתם נמחקים לצמיתות ולא מועברים לפח האשפה, לכן בדקו כל בחירה לפני האישור. בקוד המקור ובספריית התמונות שלכם AskClean לא נוגע לעולם. זו אותה רשימת בדיקה כמו במדריך הזה, בלי שעה של עבודה במסוף.
מה אפשר לבנות מחדש — ומה לא
זו טבלה של גבולות המחיקה, לא הבטחה לחיסכון מסוים במקום. מדדו את ה-Mac שלכם לפני כל פעולה ואחריה — סקריפט הבדיקה לקריאה בלבד שבמדריך אחסון הסימולטורים של Xcode מציג את התיקיות האלה בלי לשנות דבר.
| קטגוריה | מיקום ברירת המחדל | מה קורה אחרי המחיקה |
|---|---|---|
| DerivedData | ~/Library/Developer/Xcode/DerivedData | נבנית ומאונדקסת מחדש; קוד המקור והיסטוריית ה-git לא נפגעים. |
| מכשירי סימולטור | ~/Library/Developer/CoreSimulator/Devices | האפליקציות ונתוני הבדיקה של המכשירים המדומים שנבחרו אובדים; מחקו דרך simctl או Xcode. |
| Archives | ~/Library/Developer/Xcode/Archives | עלולים להימחק קובצי dSYM שנחוצים לפענוח דוחות קריסה; בדקו קודם ב-Organizer. |
| DeviceSupport | ~/Library/Developer/Xcode/iOS DeviceSupport | סמלי ניפוי השגיאות מועתקים שוב כשמחברים מכשיר עם אותה גרסת מערכת. |
שאלות נפוצות
האם בטוח למחוק את DerivedData?
כן — זו אחת המחיקות הגדולות הבטוחות ביותר ב-Mac. DerivedData מכילה רק קבצים ש-Xcode מפיק מקוד המקור: תוצרי בנייה, מטמוני מודולים, אינדקסים ויומנים. הקוד, קובצי הפרויקט והיסטוריית ה-git שלכם נמצאים במקום אחר ואינם מושפעים. ההשלכה היחידה: הבנייה הבאה של כל פרויקט תהיה בנייה מלאה, והאינדוקס ירוץ שוב.
באיזו תדירות כדאי לנקות את DerivedData?
אין לוח זמנים מחייב — נקו כשהיא גדלה מספיק כדי שזה ישנה משהו, ואצל רוב המפתחים הפעילים זה בערך פעם בחודש-חודשיים. שני מצבים תמיד מצדיקים ניקוי: כשצריך מקום בדיסק בדחיפות, וכשפרויקט מציג שגיאות בנייה לא מוסברות או השלמת קוד לא עדכנית — אז מחיקת DerivedData היא צעד התיקון הראשון המקובל.
האם Xcode יהיה איטי יותר אחרי מחיקת DerivedData?
באופן זמני, כן. הבנייה הראשונה של כל פרויקט היא בנייה נקייה, שעשויה להימשך פי כמה מבנייה מצטברת, והאינדוקס ברקע צריך כמה דקות עד שהשלמת הקוד והחיפוש יחזרו לפעול במלואם. אחרי הסבב הראשון הביצועים יהיו בדיוק כמו קודם — DerivedData מכילה מטמונים, לא שיפורי ביצועים שאובדים לתמיד.
ומה עם ~/Library/Developer/CoreSimulator — אפשר למחוק אותה?
לא בלי בדיקה — היא מחזיקה את הסימולטורים המותקנים כרגע ואת הנתונים שלהם, ומחיקה גורפת שלה תשבית אותם עד שתתקינו מחדש סביבות הרצה. במקום זאת, נקו אותה בצורה מסודרת: הריצו xcrun simctl delete unavailable למכשירים יתומים (האפליקציות והנתונים שבהם יימחקו יחד איתם), הסירו סביבות הרצה ישנות ב-Settings > Components של Xcode, מחקו מכשירים שאינם בשימוש ב-Devices and Simulators, ונקו ידנית רק את תת-התיקייה Caches, כש-Xcode ו-Simulator סגורים.
האם Clean Build Folder עושה אותו דבר?
לא. Product > Clean Build Folder (Shift-Command-K) מנקה תוצרי בנייה של הפרויקט הנוכחי בלבד, ומשאירה במקומם את האינדקסים, את מטמוני המודולים ואת התיקיות של כל שאר הפרויקטים. זה כלי לפתרון תקלות בנייה, לא כלי לפינוי מקום — כדי לפנות מקום של ממש צריך למחוק את תיקיות ה-DerivedData עצמן.
מקורות