מדוע הכנת נכסים ל-iOS שוברת את שחרורי האפליקציה
פריסה אחת יוצאת לפיתוח, ומכאן מתחילה עבודה ידנית: לכל סקאלת גרפיקה — @1x, @2x, @3x — התמונה מיוצאת בנפרד, מקבלת שם חדש וממוינת לתיקיות. המעצב מסר סט אחד, השני הושלם מהזיכרון, השלישי נלקח משחרור קודם — ואף אחד כבר לא יגיד איזה קובץ עדכני ואיזה נותר מאיטרציה קודמת.
אחרי שני שחרורים הכנת נכסים ל-iOS הופכת לארכיאולוגיה: האייקונים יושבים בשלושה מקומות — חלק בקטלוג התמונות, חלק לצד הקוד, חלק בענף ישן.
טעות בסלוט אחד (רסטר למסך גדול הוצב במקום הבסיסי) לא נתפסת לא בסקירה ולא בבדיקות אוטומטיות — היא צפה אצל המשתמש: פריסה שבורה על המסכים, אייקונים מטושטשים, קצוות חתוכים של באנרים. התסמינים מגיעים ממקומות שונים, ואת הסיבה צריך לחפש מחדש בכל שחרור.
המחיר של סכמה כזו מצטבר בשקט: את קטלוג התמונות שהתנפח איש לא מנקה, כפילויות נגררות מגרסה לגרסה, ומשקל האפליקציה גדל בגלל נתונים שהמשתמש כלל לא רואה. גם החזרה לאחור נעשית מורכבת יותר — לא ברור איזה סט גרפיקה תואם לבנייה הקודמת.
זה נסגר במקור אמת אחד: הגרפיקה נשמרת בפורמט מאסטר, הסקאלות הנדרשות נוצרות אוטומטית, ותקינות הסט נבדקת בשלב הבנייה. בהמשך נפרט כיצד לבנות צינור כזה ומה הוא משנה בתהליך השחרור.
מה נותן צינור גרפיקה אחיד באפליקציה
גרפיקה מפוזרת היא מקור תדיר לממשק "צף". המעצב מוסר תמונות במספר סקאלות, חלק נצבע מחדש לאחר אישור, חלק נשאר בגודל אחד בלבד. התוצאה צפויה: בטאבלט הלוגו מתוח, האייקון ברשימה סבוני, וכל תיקון עובר דרך המפתח ובנייה שלא תוכננה.
מקור גרפיקה אחיד מסיר את הענף הזה כולו. מקור וקטורי ומרשם שמות אחד יושבים לצד הקוד, סקאלות הנגזרות והעותקים הרסטריים נוצרים אוטומטית בבנייה — ידנית לא מכינים אף קובץ.
את המקורות מחזיקים ב-Figma עם ספריות רכיבים משותפות: שם הנכס זהה בפריסה ובפרויקט, ופער נראה בבדיקת הפריסה ולא בבדיקת הבנייה.
האפקט ניכר בשתי מטריקות בבת אחת. שלב הבנייה מתקצר מדקות לשניות, כי במקום הוספה ידנית של קבצים פועלת יצירה ושימוש חוזר בנכסים שלא השתנו. משקל האפליקציה יורד ברבע ויותר — כפילויות וסקאלות שאף מסך לא מבקש לא נכנסות לבנייה.
בנפרד נעלם סוג הכשל "הגרפיקה לא תאמה לפריסה". אין מה לבדוק: המקור אחד, והמאושר נכנס לבנייה בלי העברות ידניות.
מהירות הוצאת העדכונים עולה: תיקון אייקון או באנר מפסיק להיות משימה של המפתח — המעצב משנה את המקור, והשחרור הקרוב לוקח אותו בעצמו. גם החזרה לאחור נשארת עובדת: סט הגרפיקה הקודם משוחזר מההיסטוריה בפעולה אחת.
שלוש דרכים להרכיב גרפיקה למסכים שונים
הכנת נכסים ל-iOS מתחילה בבעיה אחת: תמונה אחת צריכה להיראות חדה על מסכים שונים, אך לתפוס נפח שונה. מסך קומפקטי מסתפק בסקאלה הבסיסית, המוגדל צריך צפופה.
אם חותכים סקאלות ידנית ואחר כך מתקנים את המקור, קל לקבל אי-סנכרון: בחלק מהמכשירים האייקון מטושטש, והבנייה הפכה כבדה בעשרות מגה-בייט. נפרט ארבע גישות והמגבלות שלהן.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| חיתוך סקאלות ידני | תמונות בודדות שמשתנות לעיתים רחוקות | תיקון המקור מחייב חיתוך חוזר, ואי-הסנכרון נתפס רק במכשיר |
| סקריפט ליצירת גרפיקה במערכת הבנייה | זרם אחיד של אייקונים ואיורים, ערכות עיצוב | נדרשים מקורות וקטוריים ואדם שמתחזק את הסקריפט; שגיאה שוברת את כל הסקאלות בבת אחת |
| קטלוג תמונות בפרויקט עם יצירה אוטומטית | מסכי האפליקציה ורכיבי ממשק מערכתיים | כל הסקאלות נכנסות לאספקה — משקל הבנייה גדל עם מספר התמונות |
| אספקת תמונות חיצונית | גרפיקת תוכן שמתעדכנת בלי הוצאת גרסה חדשה | תלות ברשת: נדרשים מטמון, תחליף לא מקוון ובקרת זמן טעינה |
בפועל משלבים בין הגישות: את הממשק מרכיבים דרך הקטלוג, זרם אייקונים אחיד נמסר לסקריפט, ותמונות תוכן — לאספקה חיצונית. אז תיקון המקור לא מפעיל עבודה ידנית, ומשקל הבנייה נשאר צפוי.
שלבים לסדר בגרפיקה של האפליקציה
להשליט סדר בגרפיקה זול יותר לא על ידי שינוי שמות קבצים אלא על ידי ספירת מלאי: תחילה קובעים כמה תמונות באמת בשימוש, היכן יושבות כפילויות ולאילו סטים חסרות צפיפויות. ביקורת כזו נותנת נקודת עוגן — אחרי העבודה רואים מה בדיוק השתנה, ולא "נהיה איכשהו נקי יותר".
- ביקורת גרפיקת האפליקציה — עוברים על המסכים ובודקים אילו תמונות נטענות ואילו נותרו ממדורים שנמחקו ושוכבות כנפח מת בבנייה.
- ספירת מלאי של התמונות — מרכזים את מה שנמצא במרשם: ייעוד, מסכים שבהם בשימוש, סט צפיפויות, בעלים. המרשם מיד חושף כפילויות.
- סכמת אחסון וכללי שמות לקבצים — מניחים מקורות ונגזרים בתיקיות כך שהשם יתאר באופן חד-משמעי מסך, רכיב ומצב. ה"icon_final_2" הידני יוצא מהתהליך.
- הגדרת הצינור — סקאלות ופורמטים נוצרים ממקור אחד, וגרסאות מיותרות לא נכנסות לבנייה: גודל חבילת ההתקנה מפסיק לגדול עם כל שחרור.
- בדיקה במכשירים — בודקים צפיפויות על מסכים שונים, בהחלפת ערכת עיצוב ובסיבוב: קצוות מטושטשים וגדלים "מקפצים" נתפסים כאן, ולא אצל המשתמשים.
- העברה לצוות — הנוהל, תבניות השמות ורשימת הבדיקה לקבלה נשארים במאגר, כדי שהפריסה הבאה תעבור את אותו מסלול בלי בירורים.
מכאן התמיכה מתנהלת בצורה צפויה: מסך חדש — אותו מסלול ואותן בדיקות.
מה נשאר בפרויקט ובתיעוד אחרי העבודה
העבודה מסתיימת לא בקטלוג מורכב, אלא בכללים שלפיהם המעצב או המפתח הבא יחזרו על התוצאה בלעדינו. לפרויקט נכנסים מבנה הקטלוג, הנוהלים וההוראות — כל מה שמתאר מאיפה מגיע כל @1x, @2x ו-@3x ומה לעשות בהוספת גרפיקה חדשה.
- מבנה הקטלוג — תיקיות לפי מודולים ומסכים, בנפרד אייקונים, איורים ורקעים. מסך חדש נכנס למקום ידוע, ולא "לצד משהו דומה".
- כללי שמות — לטינית, אותיות קטנות, שם משמעותי בלי תאריכים וגרסאות, סקאלה רק כסיומת. לפי שם הקובץ מיד רואים לאיזה מסך הוא שייך.
- מפת סקאלות — טבלה שבה לכל סט מצוין אילו גדלי מסך הוא מכסה ומה משמש כמקור. ברור איזה קובץ לצייר מחדש, ולא למתוח.
- נוהל עבודה עם תמונות — היכן יושב המקור, מי אחראי על התיקון, באיזה רגע הקטלוג נבנה מחדש ומה נחשב לשינוי מוגמר.
- הוראות למעצבים — כיצד להכין פריסה לייצוא: חיתוך לפי רשת פיקסלים, שקיפות במקום שבו היא נדרשת, מקורות וקטוריים לרכיבים ניתנים להרחבה, שמות שכבות זהים לשמות הקבצים.
- נוהל לפיתוח — כיצד מחברים גרפיקה, מה לעשות כשסקאלה חסרה ומדוע אין לשנות שמות ידנית.
- תיעוד הגרפיקה — פורמטים וייעודם, וכן רשימת פגמים אופייניים: גרפיקה רסטרית מתוחה, שוליים מיותרים, רקע אטום במקום שקוף.
- רשימת בדיקה לקבלה — שלמות הסטים, משקל, התאמת קווים בין סקאלות; לפי הצורך הבדיקה מוטמעת בבנייה ולא מניחה לסט חלקי לעבור.
הארטיפקטים יושבים במאגר הפרויקט לצד הקוד, ולכן תיקון גרפיקה עובר בדיוק כמו תיקון קוד — עם בדיקה והיסטוריה מובנת. אחרי ההעברה צוות הלקוח מוסיף מסכים חדשים בעצמו.
מקרה בוחן: אפליקציה עם סט תמונות שהתנפח
אפליקציה של רשת חנויות עם קטלוג מוצרים ומסכי פרומו: הגרפיקה התעדכנה כל שבועיים, וכל הוצאה החלה בייצוא ידני של תמונות. המעצב מסר פריסות, המפתח סידר את התמונות לשלוש סקאלות, השמות הומצאו תוך כדי, וחלק מהאיורים שוכפלו תחת שמות שונים.
הכנת הגרפיקה אכלה יומיים-שלושה מתוך מחזור של שבועיים, ולבנייה נכנסה מדי פעם הסקאלה הלא נכונה — על מסכים גדולים התמונה יצאה מטושטשת, ולוח הזמנים של השחרור נדחה שוב.
מה שינו
הרכיבו קטלוג תמונות אחיד ב-Xcode: מקור אחד לכל איור, הסקאלות נבנות ממנו, ואת השמות קובעת תבנית ולא הכותב. באנרי הפרומו הועברו לווקטור — במקום שלושה עותקים רסטריים נשאר במאגר קובץ אחד שנפרס לסקאלות הנדרשות בבנייה.
מעל זה הוצבה בדיקה: תמונה בלי סט סקאלות מלא או עם שם כפול עוצרת את הבנייה לפני הסקירה, ולא נוסעת לחנות האפליקציות.
מטריקות לפני ואחרי
הסט הצטמצם מ-620 קבצים ל-390 — הכפילויות נוקו וכבר לא נוצרות. זמן הכנת הגרפיקה ירד מיומיים-שלושה לשלוש-ארבע שעות, ומחזור הוצאת העדכון — משבועיים לשבוע. סוג השגיאה "סקאלה לא נכונה" נעלם מהשחרורים: בעשרת השחרורים האחרונים לא הייתה אף חזרה לאחור בגלל גרפיקה.
מה לעשות אם הנכסים כבר התפזרו בין מאגרים?
התמונה מוכרת: אייקונים ורקעים יושבים במאגר הראשי של האפליקציה, חלקם במאגר נפרד של מערכת העיצוב, ועוד חלק בענפים של מודולים בירושה שאיש לא נגע בהם שנים.
אותו אייקון קיים בשני-שלושה עותקים, וסטי הסקאלות שלהם לא תואמים: במקום אחד יש את כל שלוש הצפיפויות, במקום אחר רק שתיים, ובמקום שלישי את המקור החליפו במתוח.
כל עוד אדם אחד מתקן את הגרפיקה, זה נסבל. ברגע שעל התמונות עובדים שניים, העותקים מתפצלים: בסט אחד עודכן ה-@3x, בשני נשאר @2x ישן, והשלישי איבד את ה-@1x לגמרי. את זה לא תופסת הסקירה, אלא בדיקה במכשיר עם צפיפות המסך המתאימה — או המשתמש שראה סבון והסטה בקצוות.
עוברים לסכמה אחידה בלי לעצור את הפיתוח. תחילה ספירת מלאי: סקריפט עובר על המאגרים והענפים, מחשב חשיש תוכן של כל קובץ ובונה מפה — היכן המקור, היכן העותק, היכן הסט חלקי. אחר כך בוחרים מקור אמת: ככלל זה קטלוג המשאבים של מערכת העיצוב, המחובר כמודול נפרד שכל יעדי האפליקציה בונים.
המיגרציה מתנהלת במנות — מסך או מודול אחד לאיטרציה. בתקופת המעבר הכתובות הקודמות נשארות עובדות: הבנייה לוקחת גרפיקה מהקטלוג החדש, ופניות ישנות נפתרות דרך שכבת תאימות דקה.
לתהליך הבנייה מתווספת בדיקה: הסט חייב להכיל את כל הסקאלות הנדרשות, והתאמה לפי חשיש תוכן מפילה את הבנייה ככפילות.
את נכסי המורשת של הפרויקט מחברים לסכמה המשותפת אחרונים — כשחלקו העיקרי של האפליקציה כבר נבנה ממקור אחד. אחרי זה תיקון אייקון נעשה במקום אחד ומתפזר לכל היעדים, והשאלה "איפה הגרסה העדכנית" מפסיקה לעלות.
ספקות טכניים: סקאלות, משקל, פרטיות
שלוש צפיפויות — @1x, @2x, @3x — מכסות כמעט את כל מגוון המכשירים, אך לא מבטלות החלטות ידניות. אייקונים ולוגואים מוסרים כווקטור, וסטים רסטריים מכינים רק במקום שבו וקטור אינו זמין: תוכן צילומי, טקסטורות, אפקטי שקיפות מורכבים. אחרת בבנייה שוקעים עשרות קבצים שאיש לא בודק על מסכים אמיתיים.
משקל הבנייה גדל באופן לא ליניארי: אם להניח רסטר 3x תחת כל תמונה, החבילה נעשית כבדה הרבה יותר מהר מהקצב שבו גדלה האיכות שהמשתמש רואה.
מדיניות הבחירה מוגדרת פעם אחת ב-Sketch, ומכאן הבדיקות מתנהלות אוטומטית — כפילויות, צפיפויות שאבדו וגרסאות מיושנות נחתכות לפני הבנייה, ולא אחרי השחרור.
האם שלוש צפיפויות מספיקות לכל המסכים?
לרוב — כן. בנפרד בודקים פרופורציות לא שגרתיות, מצב כהה ופונט מערכתי גדול. זו לא סקאלה חדשה, אלא סטים נוספים של בדיקות.
מה עם רישיונות על פונטים וגרפיקה?
פונט בתוך האפליקציה מורשה בנפרד מזה השולחני, וחלק מהמשקלים אין להטמיע. מאמתים את התנאים מול בעל הזכויות לפני הייצוא ורושמים במרשם הנכסים מה ובאיזה אופן מותר להפיץ.
איך מתמודדים עם חומרים חסויים?
עובדים עם ייצוא של השכבה הנדרשת, נתוני בדיקה ופריסות אנונימיות. הגישה ניתנת נקודתית ומבוטלת לאחר ההעברה — המקורות לא יוצאים ממתחם הלקוח.
נדבר על המשימה: איך אנחנו נכנסים לפרויקט שלכם
את השיחה אנחנו מתחילים לא ברשימת שירותים תבניתית, אלא בניתוח המשימה שלכם: אילו מסכים ותרחישים יש באפליקציה, באיזה שלב נמצא בסיס הקוד, מה כבר מוכן ומה עוד צריך לבנות. כך האומדן נשען על היקף העבודה האמיתי, ולא על מספרים ממוצעים בשוק. בהמשך קובעים את סדר העבודות ובאיזה אופן נחזור עם תוכנית ולוחות זמנים ליישום.
כדי להכין אומדן ותוכנית עבודה, אנחנו צריכים מכם:
- הבנת המוצר — ייעוד האפליקציה, הפלטפורמות, העומס הצפוי וקהל היעד.
- חומרים לממשק — פריסות במקור, קטלוג הנכסים, מצבי המסכים, מצב כהה ובהיר, אם הם קיימים.
- גישות — מאגר הקוד, עמדת בדיקה של חלק השרת, חשבון הפרסום ומפתחות החתימה, אם האפליקציה כבר הופצה.
- גבולות אחריות — מה אנחנו סוגרים ומה נשאר בצד שלכם: תמיכה בחלק השרת, תוכן, עיצוב מסכים חדשים.
- מגבלות — לוחות זמנים הקשורים לתאריך, דרישות תאימות לגרסאות האפליקציה שכבר פועלות.
- נקודת קבלה — מי מצדכם מקבל את התוצאה ולפי אילו קריטריונים.
לסיכום הניתוח תקבלו מסמך עם חלוקה לשלבים, תלויות ביניהם, לוחות זמנים בקלנדר וקריטריונים למוכנות בכל בלוק. תארו את המשימה בצורה חופשית — נחזור עם אומדן, תוכנית והצעה לסדר העבודות.