שירות המרת SDK ל-iOS: עדכון האפליקציה שלך לעמידה בדרישות App Store

שים לב: כשאתה מגיש את ה-build האחרון שלך ל-App Store, שעה לאחר מכן מגיע אימייל: "ITMS-91053: Missing Privacy Manifest." עם כל גרסת iOS SDK חדשה, אפל מפסיקה תמיכה ב-API ישנים ומציגה דרישות חובה. ללא מיגרציה מתוכננת, אתה מסתכן בחוסר יכולת להגיש עדכונים. אנו נתקלים בתרחישים אלה לעתים קרובות ומציעים מיגרציה מקצה לקצה — כולל ביקורת, עדכון ואחריות.

מה בעצם נשבר כשמחליפים SDK

APIs שהוצאו משימוש הם החלק הנרחב ביותר בעבודה. UIWebView הוסר מאז iOS 15 SDK; אפליקציות שמשתמשות בו מקבלות דחייה עם ITMS-90809. UIAlertView, UIActionSheet, shouldAutorotateToInterfaceOrientation — שיטות אלה כבר לא מתקמפלות ב-iOS 16 SDK. אנו מחפשים בקוד באמצעות Xcode #available ורשימת ה-deprecated מהערות השחרור הספציפיות של ה-SDK.

Privacy Manifest (iOS 17 SDK) — דרישה חדשה מגרסאות אחרונות. כל תלות של צד שלישי והאפליקציה עצמה חייבות לכלול קובץ PrivacyInfo.xcprivacy המצהיר על קטגוריות ה-API שבשימוש (NSPrivacyAccessedAPITypes): NSUserDefaults, NSFileManager, NSProcessInfo, UIDevice.systemBootTime. אם הקובץ חסר, ITMS-91053 מופיע כאזהרה (כיום שגיאה) במהלך ההגשה.

דוגמה PrivacyInfo.xcprivacy:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" ...>
<plist version="1.0">
  <dict>
    <key>NSPrivacyAccessedAPITypes</key>
    <array>
      <dict>
        <key>NSPrivacyAccessedAPIType</key>
        <string>NSPrivacyAccessedAPICategoryUserDefaults</string>
        <key>NSPrivacyAccessedAPITypeReasons</key>
        <array>
          <string>CA92.1</string>
        </array>
      </dict>
    </array>
  </dict>
</plist>

הסיבות חייבות להיות קודים ספציפיים מהתיעוד של אפל. <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" ...> <plist version="1.0"> <dict> <key>NSPrivacyAccessedAPITypes</key> <array> <dict> <key>NSPrivacyAccessedAPIType</key> <string>NSPrivacyAccessedAPICategoryUserDefaults</string> <key>NSPrivacyAccessedAPITypeReasons</key> <array> <string>CA92.1</string> </array> </dict> </array> </dict> </plist> עבור UserDefaults פירושו "אחסון של הגדרות המנוהלות ישירות על ידי המשתמש." אי אפשר פשוט לכתוב כל קוד — יש לבחור מהרשימה המאושרת. אם אף אחד לא מתאים, יש לכתוב לאפל דרך App Review, וזה אתגר בפני עצמו.

Swift Concurrency ו-Sendable — iOS 16+ SDK כולל בדיקות CA92.1 משופרות ובידוד actor. פרויקט שנבנה ללא אזהרות על SDK ישן יפיק עשרות אזהרות כמו Sendable על ה-SDK החדש. עם iOS 17 SDK, חלקן הופכות לשגיאות כאשר Capture of non-Sendable type 'SomeModel' מופעל. על בסיסי קוד גדולים, זהו מאמץ משמעותי.

כיצד אנו מבצעים את המיגרציה

1. ביקורת באמצעות strict concurrency checking: complete

   xcodebuild -workspace MyApp.xcworkspace \
    -scheme MyApp \
    -destination 'generic/platform=iOS' \
    -sdk iphoneos17.0 \
    build 2>&1 | grep -E "error:|warning:" | sort | uniq -c | sort -rn | head -50

   זה מספק תמונה כמותית: כמה שגיאות, אילו קטגוריות, 50 המובילות לפי תדירות. עבור בסיס קוד של 300 אלף שורות שקופץ מ-iOS 14 SDK ל-iOS 17 SDK, תוצאות אופייניות הן 15–40 שגיאות ו-100–300 אזהרות. גישת הביקורת האוטומטית שלנו מהירה פי 10–15 מבדיקת קוד ידנית.

   ניתוח תלויות צד שלישי הבעיה השנייה היא ספריות שלא עודכנו בשנתיים. רשימת הבדיקה שלנו:

   • CocoaPods: xcodebuild לרשימת תלויות מיושנות
   • SPM: בדוק xcodebuild -workspace MyApp.xcworkspace \ -scheme MyApp \ -destination 'generic/platform=iOS' \ -sdk iphoneos17.0 \ build 2>&1 | grep -E "error:|warning:" | sort | uniq -c | sort -rn | head -50 , חפש ספריות ללא תגיות עדכניות ב-GitHub
   • תלויות עם pod outdated מיושן — התנגשויות עם גרסת ה-iOS המינימלית החדשה של האפליקציה

   מקרה מיוחד הוא תלויות ללא Privacy Manifest. אפל דורשת מניפסטים מ-SDK פופולריים (Firebase, Crashlytics, Amplitude, Adjust ואחרים עדכנו את החבילות שלהם). אבל עבור ספריות פחות מוכרות, המניפסט עשוי להיות חסר, מה שמחייב או fork והוספה או הסרת התלות.

   מיגרציה לפי רמות מורכבות

   קטגוריית שינויים	מאמץ
   החלפת Package.resolved → deployment target	בינוני (שינויי delegate API)
   Privacy Manifests לקוד מותאם אישית	נמוך (תצורה)
   Privacy Manifests ל-SDK של צד שלישי	תלוי בתמיכת המפתח
   אזהרות Sendable/actor isolation	גבוה (שינויים ארכיטקטוניים)
   APIs שהוסרו (UIAlertView וכו')	נמוך (החלפה ישירה)

מה כלול בעבודה שלנו

• ביקורת מלאה של בסיס הקוד עם xcodebuild וזיהוי כל ה-APIs החסומים
• תצורת Privacy Manifest לאפליקציה ולכל התלויות
• עדכון SDK של צד שלישי לגרסאות תואמות ל-iOS SDK החדש
• תיקון אזהרות Sendable/actor isolation
• בדיקות על מכשירים אמיתיים עם גרסת ה-iOS החדשה
• תיעוד שינויים והמלצות לתמיכה שוטפת
• אחריות ל-30 יום לאחר המסירה

כיצד אנו בודקים לאחר המיגרציה

בדיקות עשן על מכשיר אמיתי עם ה-iOS החדש הן חובה. סימולטור ומכשיר אמיתי יכולים להתנהג אחרת בעת החלפת SDK, במיוחד בנוגע ל-timeouts של UIWebView, התראות push וביצוע ברקע.

Crashlytics או Firebase Crash Reporting — לאחר השחרור אנו עוקבים אחר חתימות קריסה חדשות ב-24–48 השעות הראשונות. מיגרציית SDK לפעמים מציגה קריסות במקרי קצה שאינם מכוסים בבדיקות.

הערכות לוחות זמנים

לוחות הזמנים תלויים בגודל בסיס הקוד, במספר ה-APIs שהוצאו משימוש ובמצב התלויות:

העלות מחושבת באופן אישי, אבל אתה חוסך בכך שתופס בעיות מוקדם — עלויות מיגרציה תמיד נמוכות מההשלכות של שחרורים חסומים. צור קשר להערכה מדויקת. עם ניסיון במיגרציה של מעל 50 פרויקטים, אנו מבטיחים לקחת בחשבון את כל המלכודות. קבל ייעוץ לבסיס הקוד שלך — נבצע ביקורת ביום אחד.

הנחיות סקירת ה-App Store של אפל