Build number ב-App Store Connect: גרסה ומספר build
מאת Mehdi Azizi
פורסם ב-, 8 דק׳
הגרסה היא המספר שהלקוחות שלך רואים, וה-build number מזהה כל העלאה. הצמד חייב להיות ייחודי, ועם Expo, EAS מעלה את מספר ה-build בשבילך.
ה-build number של App Store Connect הוא מספר ה-build: המפתח CFBundleVersion, שמזהה כל העלאה. הגרסה, CFBundleShortVersionString, היא המספר שהלקוחות שלך רואים ב-App Store. אפל דורשת שהצמד של גרסה ומספר build יהיה ייחודי: מספר build משמש פעם אחת בלבד לאותה גרסה.
עם Expo, את הגרסה אתה קובע בעצמך, ו-EAS יכול להעלות את מספר ה-build בכל build של production. המדריך הזה מסביר את שני המספרים, את הכללים של אפל, את השגיאות ITMS-90062 ו-ITMS-90189, ומה לבדוק כשה-build שלך לא מופיע.
אני מפרסם את אפליקציות ה-iOS שלי עם Expo ו-EAS, ביניהן Solys, TradaZen ו-Nolera. ההגדרות שמוצגות בהמשך לקוחות מקובצי ה-eas.json שלהן.
גרסה ומספר build: מה ההבדל?
שני מפתחות ב-Info.plist מזהים את האפליקציה שלך. התיעוד של אפל על CFBundleShortVersionString מתאר אותו כגרסה שהמשתמש רואה: שלושה מספרים שלמים מופרדים בנקודות, כמו 10.14.1. התיעוד על CFBundleVersion מדבר על גרסת ה-build: אחד עד שלושה מספרים שלמים, עם ספרות ונקודות בלבד.
| רכיב | מפתח iOS | מי רואה אותו | שדה Expo |
|---|---|---|---|
| גרסה | CFBundleShortVersionString | הלקוחות שלך | version |
| מספר build | CFBundleVersion | אתה ואפל | ios.buildNumber |
דוגמה בדויה: לגרסה 1.4.0 אתה מעלה את ה-builds 12, 13 ו-14 בזמן הבדיקות, ואז בוחר אחד מהם לבדיקה. העזרה של App Store Connect מסכמת את זה: הגרסה מקשרת את ה-build לדף שלו, ומספר ה-build מזהה אותו בכל המערכת.
כללי ההעלאה של אפל
- הצמד חייב להיות ייחודי. לפי התיעוד של Xcode Cloud, App Store Connect דורש שילוב ייחודי של גרסה ומספר build. לכן אפליקציית iPhone יכולה להתחיל שוב מ-1 בגרסה חדשה. אפליקציית Mac לא: המספר שלה חייב תמיד לעלות.
- גרסה מאושרת נסגרת. ברגע שאפל אישרה את גרסה 1.4.0, אי אפשר להוסיף לה עוד build. הגרסה הבאה חייבת לשאת מספר גבוה יותר.
- כל מספר מושווה כמספר שלם. 1.10 בא אחרי 1.9, כי 10 גדול מ-9. גרסה 1.9 שנשלחת אחרי 1.20 מאושרת תידחה.
הטיפ שלי: תשמור על מספר build שלם שתמיד עולה, בלי לאפס אותו ל-1. איפוס ל-1 מותר ב-iPhone, אבל מספר ייחודי לכל חיי האפליקציה מונע בלבול בין שני builds ב-TestFlight. זה מה שאני רואה באפליקציות שלי במצב remote: המונה ממשיך מגרסה לגרסה.
ניהול גרסה ו-build עם Expo ו-EAS
הדף של Expo על גרסאות, שעודכן ב-25 בספטמבר 2026, מפריד בין התפקידים. הגרסה (version ב-app.json) נשארת באחריותך: אתה משנה אותה כשאתה מכין שחרור חדש. את מספר ה-build (ios.buildNumber) אפשר להפקיד בידי EAS. Expo אגב מציינת ששכחה להעלות אותו היא סיבה נפוצה לדחייה בהעלאה.
הכול מוגדר ב-eas.json:
{
"cli": {
"appVersionSource": "remote"
},
"build": {
"production": {
"autoIncrement": true
}
}
}
"remote": השרתים של EAS שומרים את מספר ה-build. זו ההתנהגות המומלצת מאז EAS CLI 12. המונה מתחיל מהערך שבקונפיגורציה שלך, או מ-1, ואזios.buildNumberמתעלמים ממנו."local": הקונפיגורציה שלך קובעת. עםautoIncrement, EAS משנה אתios.buildNumberבקובץ שלך, ואתה צריך לעשות commit לשינוי בכל build.autoIncrement: הרפרנס של eas.json מקבלtrueאו"buildNumber"עבור ה-build, ו-"version"כדי להעלות את הספרה האחרונה של הגרסה. במצב remote, Expo מציינת ש-"version"לא נתמך.
אצלי, TradaZen ו-Nolera ב-remote. Solys נשארה ב-local: מספר ה-build שלה יושב ב-app.json וכל build של production מעלה אותו בקובץ. שתי השיטות עובדות, אבל מצב remote מבטל את הסיכון של commit שנשכח.
שתי פקודות משלימות את התמונה. eas build:version:set מאתחלת את המונה המרוחק: תכניס את המספר האחרון שנשלח לאפל. eas build:version:sync מעתיקה את הערכים המרוחקים לפרויקט שלך, שימושי אם יום אחד תקמפל עם Xcode. עם EAS Update, מצב remote לא עובד עם מדיניות nativeVersion: Expo ממליצה על appVersion.
ITMS-90062: הגרסה כבר אושרה
ההודעה נראית ככה (מספרים בדויים):
ERROR ITMS-90062: This bundle is invalid. The value for key
CFBundleShortVersionString [1.4.0] in the Info.plist file must
contain a higher version than that of the previously approved
version [1.4.0].
אפל כבר אישרה את גרסה 1.4.0: אי אפשר להוסיף לה עוד build. תעלה את הגרסה ב-app.json, למשל ל-1.4.1, ותריץ build מחדש. לשנות רק את מספר ה-build לא מספיק.
אם השגיאה חוזרת למרות ש-version מעודכן, חפש שדה ios.version. לפי הרפרנס של הקונפיגורציה של Expo, הוא גובר על version ב-iOS. אותו פתרון לשגיאה הקרובה ITMS-90186, "Invalid Pre-Release Train", שמסמנת גרסה שסגורה ל-builds חדשים.
ITMS-90189: Redundant Binary Upload
כאן מספר ה-build הוא הבעיה:
ERROR ITMS-90189: Redundant Binary Upload. You've already uploaded
a build with build number '12' for version number '1.4.0'.
הצמד 1.4.0 (12) כבר קיים אצל אפל. עם Expo, ארבע סיבות חוזרות:
- לפרופיל שבשימוש אין
autoIncrement. אם יצרת פרופיל נפרד ל-TestFlight, כמו זה של Nolera, תוסיף לו את האפשרות. - המונה המרוחק מפגר. עברת ל-
remoteאחרי העלאות ידניות: תריץeas build:version:setעם המספר האחרון שאפל מכירה. - שכחת commit במצב local. ה-build הבא מתחיל מהמספר הישן.
- אתה שולח שוב את אותו בינארי. עם
eas submit, תבחר את ה-build החדש, לא את הישן.
התיקון תמיד אותו דבר: build חדש עם מספר גבוה יותר.
"No builds available": ה-build שלך לא מופיע
ה-build נשלח, אבל הדף שלך לא מציע אותו. תבדוק לפי הסדר הזה.
- הוא עדיין בעיבוד. אפל מעבדת כל build לפני שהיא מציגה אותו ושולחת לך מייל בסוף. Expo מדברת בדרך כלל על 10 עד 15 דקות. לפי אפל, אחרי יותר מ-24 שעות בעיבוד צריך לפתוח פנייה ב-Feedback Assistant.
- הוא מחכה להצהרת ההצפנה שלך. זה הסטטוס Missing Compliance, שמפורט בהמשך.
- הגרסה לא תואמת. build בגרסה 1.4.1 לא ישויך לדף שהוכן לגרסה 1.5.0 ב-App Store Connect. תיישר בין השניים.
- בינתיים יצאה גרסה. לפי העזרה על בחירת build, הרשימה מציגה אז רק builds שנשלחו מאז השחרור הזה.
- הבודק הוא זה שלא רואה אותו. באפליקציית TestFlight, "no builds available" אומר לרוב שה-build לא נמצא באף קבוצה, מחכה לבדיקת בטא או שפג תוקפו. הפירוט נמצא ב-TestFlight לבדיקת אפליקציית ה-iPhone שלך.
הסטטוסים שכדאי להכיר
הסטטוסים שהכי הרבה פעמים מסבירים build חסר, לפי הרשימה של אפל. Processing ו-Failed לא מופיעים בה: אלה סטטוסי העלאה שמתוארים ב-מעקב ה-builds.
| סטטוס | מה זה אומר | התיקון שלך |
|---|---|---|
| Processing | אפל מעבדת את ה-build | לחכות למייל |
| Failed | שגיאה בעיבוד | לקרוא את השגיאה, לשלוח שוב |
| Missing Compliance | הצפנה לא הוצהרה | לענות או Info.plist |
| Invalid Binary | העלאה לא תקינה | לתקן, build חדש |
| Expired | עברו 90 יום | build חדש |
| Ready to Submit | מוכן לבדיקה או ל-review | להוסיף אותו לקבוצה |
להצהיר על הצפנה פעם אחת ולתמיד
בלי המפתח ITSAppUsesNonExemptEncryption, אפל תשאל אותך את שאלות התאימות בכל גרסה חדשה. עם Expo, השדה נקרא ios.config.usesNonExemptEncryption:
{
"expo": {
"ios": {
"config": {
"usesNonExemptEncryption": false
}
}
}
}
false אומר: אין הצפנה, או רק הצפנה פטורה. אפל מבהירה שהצפנה מובנית במערכת, כמו חיבורי HTTPS, פטורה בדרך כלל, ושהתשובה מכסה גם את הספריות שלך. שלוש האפליקציות שלי מצהירות false. תשים false רק אם זה נכון לאפליקציה שלך: ההצהרה מחייבת אותך.
אפשר לשנות את המספר של build שכבר נשלח?
לא. המספר כתוב בתוך הבינארי החתום: כדי לתקן אותו צריך build חדש.
מה שאפשר לשנות זה את ה-build שמשויך לגרסה שלך. אפל מאפשרת build אחד לכל גרסה, אבל אפשר להחליף אותו כמה פעמים שרוצים עד השליחה ל-review:
- פתח את הגרסה ב-App Store Connect, באזור Build.
- רחף מעל ה-build הנוכחי ולחץ על כפתור ההסרה, סימן המינוס.
- לחץ על כפתור ההוספה, סימן הפלוס, בחר את ה-build הנכון ושמור.
הסרת build מגרסה לא מוחקת אותו מהחשבון שלך. אם הגרסה כבר ב-review, קודם תמשוך את ההגשה: ה-review יתחיל מאפס.
לפני ההעלאה הבאה שלך
מספר ה-build הוא רק אחת הבדיקות בהעלאה. ה-image של ה-build יכול לגרום ל-ITMS-90725, ולחתימה יש מלכודות משלה, שמפורטות ב-תעודת מפתח iOS ו-provisioning profile. השרשרת המלאה, מה-build ועד TestFlight, נמצאת ב-לפרסם אפליקציית iOS בלי Mac, וזמני ה-review ב-כמה זמן לוקח אישור ב-App Store. כל השלבים מרוכזים בדף לפרסם אפליקציה ב-App Store.
אם אתה מכין את השחרור הראשון שלך, תעשה את האבחון החינמי: הוא אומר לך מה תקוע בפרויקט שלך ושולח לך את הצ'קליסט שלי נגד דחיות של אפל. כדי לבנות את האפליקציה, לחבר מנויים ולפרסם אותה, ה-iOS & Android Kit מלווה אותך במסלול של ארבעה שלבים עם קוד ההתחלה של האפליקציות שלי, בקצב שלך.
שאלות נפוצות
מה ההבדל בין גרסה ל-build number ב-App Store Connect?
הגרסה היא המספר הציבורי של השחרור שלך, כמו 1.4.0. ה-build number מזהה בינארי מסוים שנשלח לאפל עבור הגרסה הזו. אפשר לשלוח כמה builds לאותה גרסה, כל אחד עם מספר משלו.
צריך לשנות את מספר ה-build בכל העלאה?
כן, לאותה גרסה. אפל דוחה העלאה שנייה עם אותו צמד של גרסה ומספר build, זו השגיאה ITMS-90189. עם EAS, autoIncrement מטפל בזה בכל build של production.
מספר ה-build צריך להתאפס ל-1 בכל גרסה?
זה לא חובה. ב-iPhone, אפל מקבלת מספר נמוך יותר לגרסה חדשה, כי רק הצמד צריך להיות ייחודי. מונה שתמיד עולה נשאר פשוט יותר למעקב.
איך משנים את ה-build number ב-App Store Connect?
אי אפשר לשנות את המספר של build שכבר נשלח. אבל אפשר להחליף את ה-build שמשויך לגרסה שלך, מאזור Build בדף, כל עוד היא לא ב-review. בשביל מספר חדש, תעשה build מחדש.
למה ה-build שלי לא מופיע ב-App Store Connect?
לרוב הוא עדיין בעיבוד או מחכה להצהרת ההצפנה שלך. תבדוק גם שהגרסה שלו תואמת לגרסה שבדף שלך. אחרי יותר מ-24 שעות בעיבוד, אפל מבקשת לפתוח פנייה.

