מה ההבדל בין Clean Build Folder למחיקת DerivedData ב-Xcode?
צוות AskClean · עודכן 2026-11-02
Clean Build Folder מנקה את תוצרי הבנייה של ה-scheme שפתוח כרגע. מחיקת DerivedData מאפסת טווח רחב יותר: תוצרי בנייה, וגם אינדקסים, מטמוני מודולים ויומנים. כשהבנייה נכשלת, התחילו ב-Clean Build Folder; כשהאינדקס משובש, מחקו את תיקיית ה-DerivedData של אותו פרויקט בלבד; וכדי לפנות מקום של ממש בדיסק, מחקו את תיקיות ה-DerivedData של פרויקטים שאתם כבר לא בונים.
ההבדל הוא בהיקף, לא ביסודיות
הפקודה Product > Clean Build Folder (Shift-Command-K) פועלת בתוך הפרויקט וה-scheme שפתוחים כרגע. היא מוחקת את התוצרים המהודרים ואת קובצי הביניים של ההקשר הזה, כך שהבנייה הבאה מתחילה מקוד המקור. הטווח שלה הוא פרויקט אחד, והיא משאירה בכוונה את מה שיקר לבנות מחדש.
DerivedData היא תיקייה ראשית שמשותפת לכל הפרויקטים שמשתמשים במיקום ברירת המחדל, ~/Library/Developer/Xcode/DerivedData, ובה תת-תיקייה לכל פרויקט או workspace שפתחתם אי-פעם. מחיקת תת-תיקייה אחת מאפסת בדיוק את אותו פרויקט. מחיקת התיקייה כולה מחייבת את כל הפרויקטים שלכם לעבור בנייה ואינדוקס מחדש בפתיחה הבאה.
לכן לא נכון לתאר את השתיים כ“ניקוי קל” מול “ניקוי עמוק”. Clean Build Folder היא פעולה צרה וזולה; מחיקת DerivedData רחבה יותר ועולה לכם באינדקס. הבחירה הנכונה תלויה רק בשאלה אם מה שנשבר נמצא בתוך תוצרי הבנייה או מחוץ להם.
כשהבנייה נכשלת, התחילו בצעד המצומצם
אם הכשל הופיע מיד אחרי מעבר ל-branch אחר, שינוי בתצורת הבנייה או עריכה של קובצי משאבים, עצרו את האפליקציה שרצה והשתמשו קודם ב-Clean Build Folder. זה האיפוס הזול ביותר שיש: הוא שומר על האינדקס ומחזיר אתכם לעבודה אחרי בנייה אחת, בלי עוד כמה דקות של אינדוקס.
עברו למחיקת תיקיית ה-DerivedData של אותו פרויקט כשהתסמינים לא באמת קשורים לתוצרי הבנייה: Xcode מציג שגיאות בקוד שכבר תיקנתם, Jump to Definition מוביל למקום הלא נכון, או שהשלמת הקוד הפסיקה לזהות את הטיפוסים שהגדרתם. אלה תסמינים של האינדקס, ו-Clean Build Folder לא נוגעת באינדקס.
יש מקרה אחד שכדאי להכיר, כי בדרך כלל הוא ההסבר לכך ש“ניקיתי וזה לא עזר” הופך ל“מחקתי את DerivedData וזה עזר”: מטמון המודולים המהודרים מראש (ModuleCache.noindex) נמצא בשורש של DerivedData, ולא בתוך תת-התיקייה של פרויקט כלשהו. Clean Build Folder אף פעם לא מגיעה אליו. כשמטמון המודולים מתיישן אחרי החלפת SDK או toolchain, רק מחיקה שלו מעלימה את השגיאה.
אף אחת מהפעולות לא מתקנת באג אמיתי בקוד או בתלויות. אם אותה שגיאה בדיוק חוזרת גם אחרי בנייה נקייה, הפסיקו לנקות וקראו את הודעת המהדר: הסיבה נמצאת בהגדרות הפרויקט, ב-Package.resolved, ב-SDK שנבחר או בקוד עצמו.
אף אחת מהן אינה שיטה לפינוי מקום בדיסק
Clean Build Folder היא כלי לאבחון תקלות, שבמקרה גם משחרר קצת מקום. היא יכולה לפנות מקום של הפרויקט הנוכחי, אבל תוצרי הבנייה של כל שאר הפרויקטים, כל האינדקסים ומטמון המודולים נשארים בדיוק במקומם. מי שמריץ אותה כדי לפנות מקום בדיסק מחפש במקום הלא נכון.
אם המטרה היא באמת מקום פנוי, פעלו בכיוון ההפוך: מדדו קודם את תת-התיקיות של DerivedData, ואז מחקו את אלה של פרויקטים שלא פתחתם כבר חודשים. שם נמצאות בדרך כלל עשרות הג'יגה-בייטים — מאגרים ששכפלתם, בניתם פעם אחת ולא חזרתם אליהם.
אל תתחילו ב-rm -rf. ב-Finder אפשר להעביר את התיקיות שבחרתם לפח האשפה, ומשם אפשר לשחזר אותן עד שתרוקנו אותו — הבדל שמתברר כחשוב בפעם הראשונה שמוחקים תיקייה של פרויקט שדווקא נבנה באותו רגע. המסוף משתלם לאוטומציה, אבל רק אחרי שווידאתם את הנתיב המדויק.
בדקו את התוצאה במקום לסמוך על מספר
רשמו את הגודל של DerivedData לפני כל פעולה, בצעו רק אחת משתי האפשרויות ואז מדדו שוב. אחרי Clean Build Folder, בנו את ה-scheme הנוכחי. אחרי מחיקת תיקיית DerivedData, פתחו את Xcode והמתינו עד שהבנייה הראשונה וסבב האינדוקס יסתיימו.
הסדר הזה מפריד בין המקום שפיניתם לבין המחיר ששילמתם כדי לפנות אותו. אין מספר אחיד שאפשר לצפות לו: התוצאה תלויה בכמה פרויקטים, תצורות וארכיטקטורות נבנו ב-Mac הספציפי הזה.
באיזו פעולה לבחור
| מצב | מה לעשות | עלות השחזור |
|---|---|---|
| הבנייה נכשלת ב-scheme הנוכחי | Product > Clean Build Folder | בנייה מחדש אחת של הפרויקט הזה. האינדקסים של כל הפרויקטים נשמרים. |
| שגיאות שכבר תוקנו ממשיכות להופיע, Jump to Definition לא עובד | ~/Library/Developer/Xcode/DerivedData/<project> | בנייה מלאה ואינדוקס מחדש — לאותו פרויקט בלבד. |
| השגיאות נשארות גם אחרי Clean Build Folder, בעקבות החלפת SDK | ~/Library/Developer/Xcode/DerivedData/ModuleCache.noindex | המודולים מהודרים מחדש בבנייה הבאה. Clean Build Folder לא מגיעה לתיקייה הזו. |
| אתם באמת צריכים מקום בדיסק | ~/Library/Developer/Xcode/DerivedData | מחקו את תת-התיקיות הגדולות של פרויקטים נטושים; הם ייבנו מחדש כשתפתחו אותם שוב. |
| סביבות הרצה ישנות של הסימולטור | Xcode Settings > Components | קטגוריה נפרדת לגמרי. אף אחת משתי הפעולות לא נוגעת בה. |
הטבלה מתארת היקף, לא מספר מובטח של ג'יגה-בייטים. מדדו את ה-Mac שלכם לפני ואחרי.
שאלות נפוצות
האם Clean Build Folder מוחקת את DerivedData?
לא. היא מנקה את תוצרי הבנייה של הפרויקט וה-scheme שפתוחים. זה לא שקול למחיקת תיקיית DerivedData המשותפת, שמכילה גם את האינדקסים, את מטמון המודולים ואת היומנים של כל הפרויקטים.
האם בטוח למחוק את תיקיית ה-DerivedData של פרויקט אחד?
כן. כל מה שבתוכה נגזר מקוד המקור שלכם, ו-Xcode יוצר אותו מחדש. הקוד והיסטוריית ה-git לא נפגעים. המחיר היחיד: הבנייה הראשונה אחרי המחיקה היא בנייה מלאה, ואחריה סבב אינדוקס.
האם צריך לצאת מ-Xcode לפני כן?
כשמוחקים את DerivedData ידנית — כן: כך מנגנון האינדוקס לא יחזיק קבצים פתוחים ולא ייצור אותם מחדש בזמן שאתם מוחקים. לפקודה המובנית Clean Build Folder — לא; Xcode מבצע אותה בעצמו.
למה השגיאה עדיין מופיעה אחרי הניקוי?
סביר שהמטמון מעולם לא היה הסיבה. בדקו את הודעת המהדר, את הגדרות ה-scheme, את גרסאות התלויות, את Package.resolved, את ה-SDK שנבחר ואת מה שבאמת השתנה ב-branch הנוכחי.
למה מחיקת DerivedData פתרה בעיה ש-Clean Build Folder לא פתרה?
בדרך כלל בגלל מטמון המודולים המהודרים מראש. ModuleCache.noindex נמצא בשורש של DerivedData ולא בתוך תת-התיקייה של פרויקט, ולכן Clean Build Folder לא מגיעה אליו — ומחיקת DerivedData כן.
מקורות