ITMS-90034: תיקון Missing or invalid signature

ITMS-90034 מופיעה כשאתה שולח את ה-build שלך ל-App Store Connect. היא אומרת שהאפליקציה שלך, או אחד הרכיבים שלה, לא חתומה בתעודת הגשה של Apple, כלומר בתעודת הפצה תקפה. התיקון: למצוא איזה bundle חתום לא נכון ולמה, ואז לבנות מחדש build חתום ל-App Store.

המדריך הזה מתמקד בשגיאה עצמה. אם המילים תעודה ו-profile עדיין לא ברורות לך, תקרא קודם את תעודת מפתח iOS ו-provisioning profile. כאן תמצא את ההודעה שצריך לקרוא, עץ החלטות, את הפקודות שבודקות את ה-IPA שלך ואת התיקון עם ה-credentials ש-EAS מנהל. בשביל החלק של EAS קראתי את הקוד של EAS CLI 24.10.0 שבוחר את התעודה.

מה המשמעות של שגיאת ITMS-90034?

זו הצורה הקלאסית שלה, עם שמות לדוגמה:

ITMS-90034: Missing or invalid signature. The bundle 'com.example.myapp' at bundle path 'Payload/MyApp.app' is not signed using an Apple submission certificate.

ב-2026, בפורום של Apple, היא מופיעה גם בצורה "Validation failed (409) Missing or invalid signature", ואחריה אותו טקסט ו-"(ID: 90034)".

"תעודת ההגשה" היא תעודת ההפצה. העזרה של Apple על תעודות כותבת את זה במפורש: תעודות פיתוח משמשות להרצת האפליקציה על המכשירים שלך, ותעודות הפצה משמשות להפיץ אותה או לשלוח אותה ל-App Store Connect.

תקרא את הנתיב שמצוטט: הוא מצביע על ה-bundle הבעייתי. Payload/MyApp.app מתייחס לאפליקציה עצמה. נתיב שנגמר ב-.appex מתייחס להרחבה (extension), כמו widget. נתיב ב-.framework מתייחס לספרייה מוטמעת.

זו לא דחייה של reviewer. הבדיקה נופלת בשליחה או בזמן העיבוד של ה-build, לפני TestFlight: ה-build הזה לעולם לא יגיע לבודקים שלך.

עץ ההחלטות: מההודעה לתיקון

כל שורה מתאימה לרמז שאתה קורא בהודעה, בפקודות של הסעיף הבא או בלוגים של EAS. תעבור עליהן לפי הסדר: השורה הראשונה שמתאימה נותנת לך את הכיוון.

מה אתה רואה	סיבה סבירה	תיקון
נתיב ב-.appex	הרחבה חתומה לא נכון	להצהיר על ההרחבה
Signature=adhoc	build לא חתום	build עם profile של store
Apple Development	build פיתוח	build עם profile של store
מופיע ProvisionedDevices	build פנימי (ad hoc)	build עם profile של store
sealed resource	IPA ששונתה אחרי החתימה	לבנות מחדש
EAS: "no longer valid"	תעודה מבוטלת	תעודה חדשה
הכל תקין	תקלה בצד של Apple	לשלוח שוב, ואז לדווח

לבדוק את ה-IPA שלך בארבע פקודות

תוריד את ה-IPA מעמוד ה-build ב-expo.dev, ואז תפתח טרמינל על ה-Mac שלך.

1. מי חתם על האפליקציה?

unzip -q MyApp.ipa -d ipa
codesign -dv --verbose=4 ipa/Payload/*.app 2>&1 | grep -E "^(Identifier|Authority|Signature|TeamIdentifier)="

codesign כותב לפלט השגיאות, ומכאן ה-2>&1. לפי ההערה הטכנית TN3161 של Apple, כל שורת Authority היא חוליה בשרשרת האמון. הראשונה צריכה להתחיל ב-Apple Distribution: או ב-iPhone Distribution:, ואחריה שם הצוות שלך. התווית השנייה שייכת לסוג הישן iOS Distribution: לפי הקוד שלו, EAS CLI 24.10.0 עדיין יוצר תעודות מהסוג הזה. אם אתה רואה Apple Development:, זה build פיתוח. אם אתה רואה Signature=adhoc בלי אף שורת Authority, הבינארי לא חתום באף תעודה.

2. האם האפליקציה שונתה אחרי החתימה?

codesign --verify --deep --strict -vv ipa/Payload/*.app

אתה רוצה לראות valid on disk, ואחריו satisfies its Designated Requirement. TN3161 מפרטת מה הבדיקה הזו מבטיחה: כל הקבצים הצפויים נמצאים, אף קובץ לא נוסף, ואף קובץ לא שונה. על bundle בדיקה שחתמתי ואז שיניתי, הפקודה עונה a sealed resource is missing or invalid, ואז file modified: ואחריו הקובץ ששונה. האופציה --deep משמשת כאן לבדיקה, אף פעם לא לחתימה: בפורום של Apple, מהנדס מצוות התמיכה ממליץ לא להשתמש בה לחתימה.

3. איזה profile מוטמע?

security cms -D -i ipa/Payload/*.app/embedded.mobileprovision -o profil.plist
plutil -extract ProvisionedDevices xml1 -o - profil.plist
plutil -extract ExpirationDate raw profil.plist

אלה הפקודות מ-ההערה TN3125 על profiles. profile של App Store לא מכיל רשימת מכשירים: השורה השנייה צריכה להחזיר Could not extract value. אם היא מציגה מזהי מכשירים, זה profile של ad hoc, של build פנימי. השורה השלישית נותנת את תאריך התפוגה של ה-profile.

4. האם ההרחבות וה-frameworks חתומים באותה צורה?

find ipa/Payload/*.app \( -name "*.appex" -o -name "*.framework" \) \
  -exec sh -c 'echo "$1"; codesign -dvv "$1" 2>&1 | grep -m1 "^Authority="' _ {} \;

כל רכיב צריך להציג את אותה שורת Authority כמו האפליקציה. אם אחד מהם שונה, הוא זה שההודעה מצטטת.

אם אתה רוצה לבדוק לפני השליחה, TN3161 ממליצה על altool, אותה בדיקה כמו הכפתור Validate App של Xcode. הוא דורש מפתח API של App Store Connect, שהקובץ שלו AuthKey_<ID_CLE>.p8 נשמר ב-~/.appstoreconnect/private_keys:

xcrun altool --validate-app -f MyApp.ipa -t ios --api-key <ID_CLE> --api-issuer <ID_EMETTEUR>

לתקן עם EAS, סיבה אחר סיבה

build פנימי או build פיתוח שנשלח ל-Apple

לפי התיעוד של Expo על eas.json, builds עם "distribution": "internal" לא חתומים ל-stores: הם משתמשים ב-profile של ad hoc. רק profile עם הפצת store, ערך ברירת המחדל, מייצר build שאפשר לשלוח. הכי בטוח לשלוח את ה-build שבדיוק בנית, בלי לבחור אותו ידנית:

eas build --platform ios --profile production --auto-submit

אם אתה משתמש ב-eas submit --path, תוודא שהקובץ הוא באמת ה-build האחרון שלך ל-store. בפורום של Apple, צוות אחד גילה שכלי השליחה שלו שלח כל פעם מחדש IPA ישן, שהיה שמור ב-git.

הרחבה שנשכחה

כל הרחבה היא bundle נפרד, עם מזהה משלה ו-profile משלה. בפרויקט Expo עם יצירת קוד native, העמוד של Expo על הרחבות iOS מבקש להצהיר עליהן ב-extra.eas.build.experimental.ios.appExtensions. ככה EAS CLI מכיר אותן לפני ה-build, ויוצר או מאמת את ה-credentials שלהן. רוב הספריות שמוסיפות הרחבה כותבות את ההצהרה הזו בשבילך, דרך ה-plugin שלהן.

Solys, השעון המעורר שלי עם מיני-משחקים, כולל ארבע הרחבות: widget ושלוש הרחבות של Screen Time. כל הארבע מוצהרות בקונפיגורציה שלו, ול-EAS יש profile לכל אחת. הרחבה שנוספה ידנית ב-Xcode, בלי ההצהרה הזו, היא המועמדת המושלמת לנתיב ב-.appex בהודעה.

תעודה מבוטלת או שפג תוקפה

העמוד של Apple על תעודות ברור: אי אפשר יותר לשלוח build שחתום בתעודה שפג תוקפה או שבוטלה. build שכבר נשלח אבל עוד לא הוגש יכול אפילו לעבור ל-Invalid Binary אם התעודה שלו בוטלה.

הקוד של EAS CLI 24.10.0 מראה מתי המקרה הזה עובר בלי שתשים לב:

• build אינטראקטיבי, מחובר ל-Apple: EAS משווה את התעודה שלו לאלה שעדיין תקפות אצל Apple. אם היא כבר לא שם, הוא מציג "Current distribution certificate is no longer valid in Apple Dev Portal" ומציע לך לבחור או ליצור אחת.
• build אינטראקטיבי, בלי חיבור: EAS בודק רק את התאריכים ומתריע שהוא מדלג על האימות מול Apple.
• build לא אינטראקטיבי, ב-CI: EAS מציג "Distribution Certificate is not validated for non-interactive builds" וחותם בכל זאת.

ב-CI, EAS לא בודק מחדש את התעודה עצמה: ביטול יכול להתגלות רק בשליחה. התיקון: תריץ build אינטראקטיבי מחובר לחשבון Apple שלך, או תעבור דרך eas credentials --platform ios, תפריט Build Credentials, ואז "Distribution Certificate: Add a new one to your account". ה-profiles שהכילו את התעודה הישנה הופכים ללא תקפים: EAS בודק אותם ב-build הבא ויוצר אותם מחדש. המגבלות של Apple על מספר התעודות מפורטות ב-מדריך על תעודת מפתח iOS.

בינארי ששונה אחרי החתימה

החתימה אוטמת את הקוד, המשאבים והמטא-דאטה באמצעות hashes, כמו שמסבירה ההערה TN3126 של Apple. לפתוח את ה-IPA כדי לשנות קובץ ואז לדחוס אותה מחדש שובר את האטימה הזו. תעשה את השינוי בקונפיגורציה שלך, ואז תבנה מחדש. לעולם אל תשנה את ה-IPA ש-EAS מייצר.

אותו היגיון חל על קוד שנמצא במקום הלא נכון, למשל בתוך ארכיון .zip: ה-App Store לא יכול לחתום עליו מחדש. Apple מתארת את המיקומים המותרים בעמוד שלה על התוכן של bundle.

credentials מקומיים

אם ה-profile שלך ב-EAS משתמש ב-"credentialsSource": "local", הקובץ credentials.json שלך מצביע על תעודת .p12 ועל profile .mobileprovision. תבדוק את ה-profile עם הפקודות של שלב 3: הוא צריך להיות מסוג App Store ולהכיל את תעודת ההפצה הנוכחית שלך. ותשמור את הקבצים האלה מחוץ ל-repo, כמו מפתחות API של אפליקציית Expo.

כשהכל תקין

נשאר מקרה אחד מתסכל. בפורום של Apple, מפתחים רואים את השגיאה נעלמת כשהם שולחים שוב את אותו build, בלי לשנות כלום. באוגוסט ובספטמבר 2026, שני שרשורים מתארים את ההפך: תעודה ו-profile חדשים, חתימה שנבדקה, וכישלון שממשיך. באחד מהם, מהנדס של Apple ממליץ על דיווח באג עם ה-IPA, ניתוח החתימה והלוגים של Transporter, ואז פנייה ל-App Store Connect.

אז תשלח שוב פעם אחת עם מספר build חדש. אם השגיאה חוזרת למרות שארבע הפקודות שלך נקיות, תדווח עליה ל-Apple עם הפרטים האלה. אל תבטל את התעודה שלך באופן אוטומטי: זה לא פותר שום דבר נוסף וזה הופך את ה-profiles שלך ללא תקפים.

לשלוח את ה-build שלך בלי הפתעות

חתימה נבדקת בשתי דקות לפני השליחה. שאר הבדיקות האוטומטיות דורשות את אותה הקפדה, כמו ITMS-90725 לגרסת Xcode או ITMS-90683 למשפטי ההרשאות. כל המסלול מה-build ועד השליחה, בלי Mac, נמצא ב-לפרסם אפליקציית iOS בלי Mac.

דחיות של reviewer דורשות יותר פרספקטיבה: הדרך מפורטת בעמוד אפליקציה שנדחתה על ידי Apple, והסיבות הנפוצות ביותר נמצאות ב-למה Apple דוחה אפליקציה.

כדי לבדוק את התיק שלך לפני השליחה, ה-Review Kit מאגד את ה-checklist שלי ו-skills של Claude Code שעוברים על הפרויקט שלך. אם השליחה שלך תקועה ואתה רוצה עין אנושית, תקבע איתי שעה: נעבור על הפרויקט שלך בווידאו, על המסך שלך. ואם אתה מכין את ההשקה הראשונה שלך, תעשה את האבחון החינמי שלך: הוא מסדר את השלבים לפי הסדר ושולח לך את ה-checklist שלי נגד דחיות של Apple.

שאלות נפוצות

האם ITMS-90034 היא דחייה של App Review?

לא. זו בדיקה אוטומטית שנעשית בשליחת ה-build, לפני TestFlight ולפני כל review. אף אחד לא פתח את האפליקציה שלך: Apple רק זיהתה שהחתימה שלה לא מגיעה מתעודת הפצה תקפה.

צריך לבטל את תעודת ההפצה שלי כדי לתקן את ITMS-90034?

רק אם היא נפרצה או כבר לא תקפה. ביטול של תעודה שעובדת הופך את ה-profiles שלך ללא תקפים בלי לתקן את הסיבה. תתחיל בלקרוא את החתימה של ה-IPA שלך עם codesign, ואז תתקן את מה שעץ ההחלטות מצביע עליו.

אפשר לתקן את ITMS-90034 עם עדכון מרחוק?

לא. החתימה היא חלק מהבינארי, וה-build שנדחה לעולם לא יהיה שמיש. צריך לייצר בינארי חדש שחתום נכון ולשלוח אותו שוב.

למה השגיאה מצטטת את ה-widget שלי ולא את האפליקציה?

כי ה-widget הוא bundle נפרד, שחתום עם ה-profile שלו. אם לא הצהרת עליו ל-EAS או שהוא נחתם בדרך אחרת, הוא מכשיל את כל השליחה. תצהיר על ההרחבה בקונפיגורציה שלך ותבנה מחדש.

מה לעשות אם codesign אומר שהכל תקין?

תבדוק גם את ה-profile המוטמע ואת כל הרחבה. אם הכל נקי, תשלח שוב פעם אחת עם מספר build חדש. אם השגיאה ממשיכה, תשלח דיווח ל-Apple עם ה-IPA, הפלט של codesign והלוגים של השליחה.