ITMS-90683: איך מתקנים Missing purpose string ב-Expo
מאת Mehdi Azizi
פורסם ב-, 6 דק׳
ITMS-90683 אומר שחסר משפט הסבר ב-Info.plist. מוסיפים את המפתח שמופיע בהודעה תחת ios.infoPlist ב-app.json, ומריצים build חדש.
ITMS-90683 הוא דחייה אוטומטית של Apple: היא מגיעה במייל זמן קצר אחרי שהעלית את ה-build, עוד לפני שבן אדם כלשהו בדק אותו. המשמעות: בקובץ Info.plist שלך חסר המשפט שמסביר למה האפליקציה ניגשת למידע רגיש. התיקון הוא שני צעדים: מוסיפים את המפתח שמופיע בהודעה ל-ios.infoPlist, ומריצים build חדש.
חטפתי את זה ב-Solys, השעון המעורר שלי עם מיני-משחקים, בגלל מידע שהאפליקציה בכלל לא משתמשת בו. הנה מה ההודעה אומרת, למה היא מגיעה, ואיך נמנעים ממנה.
מה אומרת השגיאה ITMS-90683?
הכותרת המלאה של ההודעה היא "ITMS-90683: Missing purpose string in Info.plist". היא אומרת שהקוד של האפליקציה שלך מפנה ל-API שנוגע במידע רגיש (תמונות, מצלמה, מיקרופון, מיקום, אנשי קשר), וש-Info.plist שלך לא מכיל את מפתח התיאור המתאים. ההודעה מציינת את שם המפתח, למשל NSPhotoLibraryUsageDescription.
משפט התיאור הזה נקרא "purpose string". זה הטקסט ש-iOS מציג בחלון בקשת ההרשאה. Apple כותבת את זה בתיעוד שלה על גישה למשאבים מוגנים: App Review דוחה אפליקציות שהקוד שלהן ניגש למשאבים האלה בלי purpose string.
זו לא דחייה של reviewer. הבדיקה אוטומטית ונופלת ברגע שה-build מגיע, לפני שהוא נכנס לבדיקה, בדיוק כמו ITMS-91053 של מניפסט הפרטיות. ה-build נפסל וצריך לשלוח חדש.
למה Apple דוחה כשהאפליקציה שלך לא משתמשת במידע הזה
זה החלק שמפתיע. Apple סורקת את הקוד שנמצא ב-build שלך, לא את מה שהאפליקציה עושה בפועל. אם ספרייה שאתה כולל מכילה הפניה לספריית התמונות, המפתח נדרש, גם אם אף מסך לא מבקש אף פעם גישה לתמונות. ההודעה של Apple אומרת את זה בעצמה: ספרייה או SDK חיצוני יכולים להפנות ל-API האלה, וה-purpose string עדיין חובה.
המקרה שלי, 26 בספטמבר 2026. כשניקיתי את הקונפיגורציה של Solys, הסרתי את המפתח NSPhotoLibraryUsageDescription, כי האפליקציה לא נוגעת באף תמונה. ה-build הבא נדחה עם ITMS-90683. הסיבה: שתי ספריות של Expo שהאפליקציה משתמשת בהן, expo-image ו-expo-file-system, מכילות קוד שמפנה לספריית התמונות. ה-build הקודם עבר, כי המפתח עוד היה שם.
השיעור: לא מסירים מפתח תיאור "כי לא משתמשים בו". מסירים אותו רק כשאף ספרייה ב-build כבר לא מפנה ל-API.
המפתחות הנפוצים ביותר
NSPhotoLibraryUsageDescription: קריאה או כתיבה של תמונות.NSPhotoLibraryAddUsageDescription: הוספת תמונות, בלי קריאה.NSCameraUsageDescription: מצלמה.NSMicrophoneUsageDescription: מיקרופון.NSLocationWhenInUseUsageDescription: מיקום בזמן שימוש.NSContactsUsageDescription: אנשי קשר.NSUserTrackingUsageDescription: מעקב פרסומי (App Tracking Transparency).
Apple מתארת כל מפתח בתיעוד שלה, למשל זה של NSPhotoLibraryUsageDescription: הוא נדרש ברגע שהאפליקציה משתמשת ב-API שקורא מספריית התמונות או כותב אליה.
איך מתקנים ITMS-90683 באפליקציית Expo
- רשום את המפתח שמופיע במייל של Apple. ההודעה נותנת את השם המדויק שלו.
- הוסף אותו לקונפיגורציה שלך, תחת
ios.infoPlist, כמו שמוסבר בתיעוד של Expo על הרשאות:
{
"expo": {
"ios": {
"infoPlist": {
"NSPhotoLibraryUsageDescription": "Solys לא ניגשת לתמונות שלך. ההרשאה הזו אף פעם לא מתבקשת."
}
}
}
}
- תריץ build חדש. Expo מבהירים: שינוי ב-Info.plist לא עובר בעדכון מרחוק, הוא דורש בינארי חדש.
- שלח את ה-build ל-Apple, ואז בחר אותו בגרסה שלך.
מלכודת אם האפליקציה שלך מתורגמת: קובצי השפה מתרגמים מפתח, הם לא מצהירים עליו. המפתח צריך קודם להיות קיים ב-ios.infoPlist (או בקונפיגורציה של הפלאגין הרלוונטי). אחרת האפליקציה עלולה לקרוס בקריאה הראשונה.
איזה משפט לכתוב אם האפליקציה לא משתמשת במידע?
Apple מבקשת תיאור מדויק, שימושי וספציפי. אם האפליקציה באמת משתמשת במידע, תגיד למה הוא משמש, במשפט אחד: "האפליקציה משתמשת במצלמה כדי לסרוק את הברקוד של הכרטיס שלך."
אם המפתח נמצא שם רק בגלל ספרייה, Apple נותנת שני פתרונות: לכתוב את המשפט, או להסיר את הקוד שניגש למידע. כשהקוד הזה מגיע מספרייה, אי אפשר פשוט להסיר אותו. אז ב-Solys כתבתי את האמת: "Solys לא ניגשת לתמונות שלך. ההרשאה הזו אף פעם לא מתבקשת." זו בחירה פרגמטית: ה-build הבא עבר בהגשה, אבל אני לא יכול להבטיח לך ש-Apple תמיד תקבל את המשפט הזה.
איך מאתרים מפתחות חסרים לפני השליחה
מהתיקייה הראשית של הפרויקט, הפקודה הזו מציגה את קובצי הספריות שהקוד ה-iOS שלהן מפנה ל-API הכי מפוקחים:
grep -rlE "PHPhotoLibrary|AVCaptureDevice|CLLocationManager|CNContactStore|EKEventStore|ATTrackingManager" \
node_modules/*/ios node_modules/@*/*/ios
כל שם מתאים לסוג מידע: PHPhotoLibrary לתמונות, AVCaptureDevice למצלמה ולמיקרופון, CLLocationManager למיקום, CNContactStore לאנשי קשר, EKEventStore ליומן, ATTrackingManager למעקב. לכל תוצאה, תוודא שמפתח התיאור המתאים קיים בקונפיגורציה שלך.
הרשת הזו תופסת את המקרים שנתקלתי בהם. היא לא מחליפה את קריאת המייל של Apple, שנשאר הרשימה האמינה היחידה, כמו ב-API הלא ציבוריים של ITMS-90338. מאז הדחייה הזו, הבדיקה הזו רצה אצלי לפני כל build: היא לוקחת כמה שניות, ואילו דחיית ITMS-90683 עולה לך build ואת הזמן לבנות אותו מחדש.
לשלוח את ה-build בלי הפתעות לא נעימות
את ITMS-90683 מתקנים מהר כשיודעים לקרוא אותו, בדיוק כמו ITMS-90725, שנוגע לגרסת Xcode. הדחיות שמגיעות אחר כך, של reviewer, דורשות יותר פרספקטיבה: התהליך נמצא בעמוד אפליקציה שנדחתה על ידי Apple, והסיבות הנפוצות ביותר נמצאות בלמה Apple דוחה אפליקציה.
כדי לבדוק את התיק שלך לפני השליחה, ה-Apple Review Kit מאגד את הצ'קליסט שלי ו-skills של Claude Code שעוברים על הפרויקט שלך. אם השליחה שלך תקועה ואתה רוצה עין אנושית, תזמין איתי שעה: נעבור על הפרויקט שלך בווידאו, על המסך שלך. ואם אתה מכין את ההשקה הראשונה שלך, תעשה את האבחון החינמי: הוא מסדר את השלבים לפי הסדר ושולח לך את הצ'קליסט שלי נגד דחיות של Apple.
שאלות נפוצות
האם ITMS-90683 הוא דחייה של App Review?
לא במובן של reviewer אנושי. זו בדיקה אוטומטית שנעשית על ה-build כשהוא מגיע, לפני שהוא נכנס לבדיקה, כמו ITMS-90717 של האייקון. אף אחד לא פתח את האפליקציה שלך. ה-build נפסל: צריך לתקן את Info.plist ולשלוח חדש.
למה Apple דורשת מפתח למידע שהאפליקציה שלי לא משתמשת בו?
כי Apple סורקת את הקוד שנמצא ב-build, לא את ההתנהגות של האפליקציה. אם ספרייה כלולה מפנה לספריית התמונות או למצלמה, מפתח התיאור נדרש, גם אם אף מסך לא מבקש אף פעם את הגישה הזו.
אפשר לתקן ITMS-90683 בעדכון מרחוק?
לא. המפתח החסר נמצא ב-Info.plist, שהוא חלק מהבינארי. עדכון מרחוק לא משנה את הקובץ הזה: צריך להריץ build חדש ולשלוח אותו ל-Apple.
איפה מוסיפים את NSPhotoLibraryUsageDescription בפרויקט Expo?
בקונפיגורציה של האפליקציה, תחת ios.infoPlist, עם משפט שמתאר את השימוש. חלק מהספריות מציעות גם הגדרה ייעודית בפלאגין שלהן, שיכולה להוסיף מפתחות נוספים, כמו מצב רקע. בשני המקרים, המפתח צריך להיות קיים בקונפיגורציה הבסיסית, לא רק בקובצי התרגום.
צריך להסיר מפתחות תיאור שלא בשימוש?
רק אם אף ספרייה ב-build כבר לא מפנה ל-API הרלוונטי. אחרת השליחה הבאה תידחה עם ITMS-90683. לפני שמסירים מפתח, חפש את שם ה-API בקוד ה-iOS של התלויות שלך.