TestFlight: איך לבדוק אפליקציית iPhone לפני שליחה לאפל
מאת Mehdi Azizi
עודכן ב-, 8 דק׳
בודקים פנימיים או חיצוניים, בדיקת בטא, קישור ציבורי ו-builds שתקפים 90 יום: TestFlight בהסבר פשוט, עם רשימת בדיקות לפני השליחה לאפל.
מה זה TestFlight ולמה הוא טוב?
TestFlight הוא השירות של אפל שמאפשר לך להתקין את האפליקציה שלך על מכשירי iPhone אמיתיים לפני שהיא יוצאת ב-App Store. אתה מעלה build ל-App Store Connect, מזמין בודקים, והם מתקינים אותו דרך אפליקציית TestFlight, שזמינה בחינם ב-App Store. יש שני סוגי בודקים: פנימיים, עד 100 חברים בצוות שלך, בלי בדיקה של אפל; וחיצוניים, עד 10,000 אנשים, שמוזמנים במייל או בקישור ציבורי, אחרי בדיקת בטא של ה-build הראשון שלך. כל build זמין לבדיקה 90 יום.
| קריטריון | בודקים פנימיים | בודקים חיצוניים |
|---|---|---|
| מספר מקסימלי | 100 | 10,000 |
| גישה לחשבון שלך | כן, עם תפקיד | לא |
| הזמנה | הוספה לקבוצה הפנימית | מייל או קישור ציבורי |
| בדיקת בטא של אפל | אין | על ה-build הראשון |
| למי | אתה, שותף, מישהו קרוב | חברים, משתמשים ראשונים |
כדי להשתמש ב-TestFlight צריך חשבון Apple Developer בתשלום: השירות לא זמין עם חשבון חינמי. כל המדריך הזה מניח שיש לך חשבון כזה, במסגרת התוכנית הרגילה: תוכנית ה-Enterprise של אפל לא נותנת גישה ל-TestFlight.
באפליקציות שלי, כל build שנשלח דרך EAS Submit עובר ב-TestFlight ובאייפון שלי לפני שהוא נשלח לבדיקה. שם אני מוצא את הבעיות שלא רואים בפיתוח.
להעלות build ל-TestFlight
build הוא גרסה מקומפלת וחתומה של האפליקציה שלך: אם החתימה לא תקינה, אפל דוחה אותו כבר בהעלאה עם ITMS-90034. כדי שהוא יופיע ב-TestFlight, צריך לשלוח אותו ל-App Store Connect. עם Expo זה eas build --platform ios ואז eas submit --platform ios, עם image של build עדכני מספיק כדי להימנע מ-ITMS-90725. לפי התיעוד של Expo, ה-build מופיע ב-TestFlight אחרי שאפל מעבדת אותו, בדרך כלל תוך 10 עד 15 דקות. אפשר לעשות את כל זה מ-PC: המדריך לפרסם אפליקציית iOS בלי Mac מפרט את כל התהליך.
שני פרטים שתוקעים הרבה אנשים בפעם הראשונה:
- מספר ה-build חייב להשתנות בכל העלאה. אפל דוחה שני builds עם אותו מספר לאותה גרסה. עם EAS, תפעיל העלאה אוטומטית של המספר ושכח מזה.
- השאלה על הצפנה. כל עוד לא ענית על השאלה לגבי השימוש בהצפנה, ה-build נשאר תקוע בסטטוס של תאימות חסרה. אפשר לענות עליה כל פעם ב-App Store Connect, או להצהיר עליה פעם אחת בקונפיגורציה של האפליקציה.
בודקים פנימיים: הצוות שלך, בלי לחכות
בודקים פנימיים הם משתמשים בחשבון ה-App Store Connect שלך, עם תפקיד מוגדר. אפל מאפשרת עד 100 כאלה, וכל אחד יכול להתקין את האפליקציה על כמה מכשירים, עד 30.
היתרון הגדול שלהם: אין בדיקת בטא. ברגע שה-build סיים עיבוד, בלי שגיאה אוטומטית כמו ITMS-90717, אתה מוסיף אותו לקבוצה הפנימית והוא זמין. זו הקבוצה הנכונה בשבילך, ובשביל שותף או מישהו קרוב שנתת לו גישה לחשבון.
המגבלה: צריך להוסיף אותם כמשתמשים בחשבון ה-App Store Connect שלך. זה לא מתאים לאנשים זרים.
בודקים חיצוניים ובדיקת בטא
בודקים חיצוניים לא צריכים שום גישה לחשבון שלך. אפשר להזמין עד 10,000 כאלה, במייל או בקישור ציבורי. זו הקבוצה הנכונה לחברים, למשתמשים ראשונים, לקהילה.
בתמורה, אפל בודקת את ה-build לפני שהיא פותחת אותו להם. כשאתה מוסיף את ה-build הראשון של גרסה לקבוצה חיצונית, הוא נשלח לבדיקת בטא. ה-builds הבאים של אותה גרסה לא בהכרח דורשים בדיקה מלאה.
לפני השליחה, App Store Connect מבקש ממך מידע לבדיקה:
- תיאור של הבטא, שאומר לבודקים על מה להסתכל;
- כתובת מייל לפידבק;
- פרטי הקשר שלך, כדי שאפל תוכל לפנות אליך.
בדיקת הבטא היא לא הבדיקה של ה-App Store. build שאושר ב-TestFlight עדיין יכול להידחות בפרסום.
בדיקת הבטא מוודאת שה-build עומד בכללים, אבל הבדיקה הסופית מסתכלת גם על דף האפליקציה, על המנויים, על הטקסטים המשפטיים ועל החוויה המלאה. תזכור את סיבות הדחייה הקלאסיות, שמפורטות ב-למה אפל דוחה אפליקציה.
להזמין בודקים בקישור ציבורי
קישור ציבורי הוא הדרך הכי פשוטה לתת לאנשים שאתה עוד לא מכיר לבדוק את האפליקציה. הנה ההוראות של אפל, עם התוויות של הממשק באנגלית:
- ב-App Store Connect, פתח את האפליקציה ואז את הלשונית TestFlight.
- תחת External Testing, בחר את הקבוצה החיצונית שלך.
- לחץ על Create Public Link.
- בחר Open to Anyone כדי לפתוח את הקישור לכולם, או Filter by Criteria כדי להגביל אותו למכשירים ולגרסאות iOS מסוימים.
- אם תרצה, קבע מגבלת בודקים עם Set Limit.
אחר כך משתפים את הקישור איפה שרוצים: הודעה, רשת חברתית, מייל. האדם מתקין את אפליקציית TestFlight, פותח את הקישור ומאשר את ההזמנה.
שני דברים שכדאי לדעת לפני שמפיצים אותו בהרחבה:
- קבע מגבלה. אם הקישור יסתובב יותר ממה שתכננת, תשמור על שליטה במספר הבודקים.
- בודקים דרך קישור ציבורי הם אנונימיים. App Store Connect מציג עליהם רק תאריך התקנה, סשנים וקריסות. אם אתה רוצה לדעת מי בדק מה, עדיף להזמין במייל.
כמה זמן build של TestFlight תקף?
build נשאר זמין לבודקים 90 יום. אחרי זה הוא פג והבודקים לא יכולים לפתוח אותו יותר. אם הבטא שלך נמשכת יותר זמן, פשוט תעלה build חדש לפני התאריך.
בפועל, תעלה builds חדשים הרבה יותר בתדירות: בכל תיקון חשוב. כל build חדש שנוסף לקבוצה מוצע לבודקים, והם מורידים אותו באפליקציית TestFlight.
לאסוף פידבק מהבודקים
ל-TestFlight יש מערכת פידבק מובנית: הבודק מצלם מסך באפליקציה שלך, יכול לסמן עליו, ושולח לך. אם האפליקציה קורסת, אתה מקבל דוח קריסה, והבודק יכול להוסיף הקשר. הכל מחכה לך ב-App Store Connect.
זה שימושי, אבל זה לא מספיק כדי להבין קריסה ספציפית. באפליקציות שלי אני מוסיף את Sentry, שמדווח על השגיאה עם שורת הקוד הבעייתית, ואת PostHog, שמראה איפה משתמשים נוטשים. שניהם עובדים ב-build של TestFlight בדיוק כמו בפרודקשן.
לבדוק מנויים ב-TestFlight
אם האפליקציה שלך מוכרת מנוי, TestFlight הוא המקום לוודא שהוא באמת עובד. רכישות שנעשות ב-build של TestFlight עוברות בסביבת הבדיקות של אפל: הבודקים שלך לא מחויבים. החידושים מואצים: כל מנוי מתחדש פעם ביום, עד שש פעמים בשבוע, לא משנה מה משך המנוי האמיתי.
תוודא לפחות שהמחירים שמוצגים נכונים, שהרכישה באמת פותחת את האפליקציה, ושכפתור השחזור מוצא את המנוי אחרי התקנה מחדש. אני משתמש ב-RevenueCat כדי לנהל את המנויים באפליקציות שלי; כל ההקמה, מהמוצרים ב-App Store Connect ועד ה-paywall, מתוארת בעמוד מנויים בתוך אפליקציית iOS.
מה לבדוק לפני השליחה לאפל
זו הרשימה שאני עובר עליה לפני כל שליחה לבדיקה. כל סעיף מתאים לסיבת דחייה או לקריסה שאפשר להימנע ממנה.
ההפעלה הראשונה
- מחק את האפליקציה, התקן אותה מחדש מ-TestFlight, פתח אותה. זה מה שהבודק של אפל יעשה.
- עבור על כל ה-onboarding, בלי לדלג על כלום.
- סרב לכל הרשאה (התראות, מצלמה, מיקום) ובדוק שהאפליקציה ממשיכה לעבוד.
הכסף
- ה-paywall מציג את המחירים, את משך המנוי ואת הקישורים לתנאי השימוש ולמדיניות הפרטיות.
- הרכישה עובדת, וגם השחזור.
- כל המוצרים שהוגדרו גלויים לבודק: guideline 2.1 דורשת שרכישות בתוך האפליקציה יהיו שלמות, גלויות ועובדות.
תנאים קשים
- מצב טיסה ורשת איטית: הודעה ברורה, לא מסך לבן.
- ה-iPhone הכי קטן שאתה תומך בו והכי גדול: שום דבר לא חתוך, שום דבר לא מוסתר על ידי המקלדת. מסך חתוך באייפון קטן הוא מה שגרם לדחייה של Solys.
- טקסטים ארוכים, אם האפליקציה מתורגמת.
התיק לבודק
- אם האפליקציה דורשת התחברות, חשבון דמו בהערות לבדיקה, כשה-backend שלך פועל. guideline 2.1 דורשת את זה במפורש.
- הערות לבדיקה שמסבירות בשני משפטים מה האפליקציה עושה ואיפה למצוא את הפיצ'ר המרכזי.
אם בכל זאת האפליקציה נדחתה, העמוד אפליקציה שנדחתה על ידי אפל מסביר איך לענות בלי לבזבז שבוע. ולתמונה הכללית של הפרסום, מדף האפליקציה ועד היציאה, קרא את לפרסם אפליקציה ב-App Store.
טבלת בדיקות למלא על ה-build שלך
הורד את הטבלה עם 16 תרחישים בפורמט CSV. היא מפרידה בין ההכנה, הפעולה שצריך לבצע, התוצאה הצפויה וההוכחה שנצפתה. ייבא אותה ל-Numbers, Excel או Google Sheets, ואז מלא את הגרסה, המכשיר והתוצאה של כל ניסיון.
לאפליקציית יומן קריאה דמיונית, "לשמור עמוד" זה לא מספיק: רשום עמוד 24, סגור את האפליקציה לגמרי, הפעל אותה מחדש ותמצא את הערך. בדיקה שלא בוצעה נשארת "לבדיקה". אם לאפליקציה שלך אין מנוי, סמן "לא רלוונטי" בתרחישי הרכישה, עם הסיבה הזו.
הטבלה היא נקודת התחלה שצריך להתאים, לא הסמכה. תמצא גם את הערות ה-App Review ושאר התבניות החינמיות כדי להסביר לבודק את התהליך שבאמת בדקת.
מ-TestFlight ל-App Store
TestFlight הוא השלב שבו האפליקציה שלך הופכת לאמיתית: היא רצה על iPhone אמיתי, בידיים של אנשים אמיתיים. במסלול של iOS Kit, זה השלב השני: לבנות את הליבה של האפליקציה ולבדוק אותה באייפון שלך עם TestFlight, לפני שמחברים את המנויים ואז מכינים את הפרסום.
אחרי TestFlight מגיעה הבדיקה של אפל: ה-Apple Review Kit מרכז את הצ'קליסט שלי לפני השליחה ואת ההערות לבודק. בעמוד הבית מוצגים ארבעת השלבים כדי ליצור את אפליקציית המובייל שלך עם Claude Code.
אף אחד לא יכול להבטיח לך שאפל תאשר את האפליקציה שלך: אפל מחליטה.
שאלות נפוצות
איך בודקים אפליקציית iPhone עם TestFlight?
שלח build ל-App Store Connect, ואז הוסף אותו לקבוצת בודקים. עם Expo, אתה מקמפל אותו עם EAS Build ושולח אותו עם EAS Submit: הוא מופיע ב-TestFlight אחרי שאפל מעבדת אותו, בדרך כלל תוך 10 עד 15 דקות לפי Expo. הבודקים מתקינים אותו דרך אפליקציית TestFlight, שזמינה בחינם ב-App Store. צריך חשבון Apple Developer בתשלום.
איך יוצרים קישור TestFlight כדי להזמין בודקים?
ב-App Store Connect, פתח את לשונית TestFlight של האפליקציה, בחר את הקבוצה שלך תחת External Testing ולחץ על Create Public Link. בחר Open to Anyone או Filter by Criteria, ואז קבע מגבלה עם Set Limit. בודקים דרך קישור ציבורי נשארים אנונימיים: אם אתה רוצה לדעת מי בדק מה, עדיף להזמין אותם במייל.
האם בדיקת הבטא של TestFlight מחליפה את הבדיקה של ה-App Store?
לא. בדיקת הבטא מוודאת שה-build עומד בכללים, אבל הבדיקה הסופית מסתכלת גם על דף האפליקציה, על דירוג הגיל, על המנויים, על הטקסטים המשפטיים ועל החוויה המלאה. לכן build שאושר ב-TestFlight עדיין יכול להידחות בפרסום. רק בודקים חיצוניים מפעילים בדיקת בטא, על ה-build הראשון של גרסה: בודקים פנימיים לא עוברים שום בדיקה.
כמה בודקים אפשר להזמין ב-TestFlight?
אפשר להזמין עד 100 בודקים פנימיים ועד 10,000 בודקים חיצוניים. הפנימיים הם חברים בחשבון ה-App Store Connect שלך, בלי בדיקת בטא, וכל אחד יכול להתקין את האפליקציה על עד 30 מכשירים. החיצוניים מוזמנים במייל או בקישור ציבורי, אחרי בדיקת בטא של ה-build הראשון. כל build זמין לבדיקה 90 יום.
אפשר לבדוק מנוי ב-TestFlight בלי לשלם?
כן, רכישות שנעשות ב-build של TestFlight עוברות בסביבת הבדיקות של אפל: הבודקים שלך לא מחויבים. החידושים מואצים: כל מנוי מתחדש פעם ביום, עד שש פעמים בשבוע, לא משנה מה משך המנוי האמיתי. תוודא לפחות את המחירים שמוצגים, את פתיחת האפליקציה ואת השחזור אחרי התקנה מחדש. ההקמה המלאה מתוארת ב-מנויים בתוך אפליקציית iOS.
מה צריך לבדוק ב-TestFlight לפני ששולחים את האפליקציה לאפל?
התקן את האפליקציה מחדש מ-TestFlight, כמו שהבודק של אפל יעשה, ועבור על כל ה-onboarding. סרב לכל הרשאה, בדוק את הרכישה והשחזור, ואז נסה מצב טיסה, ואת ה-iPhone הכי קטן והכי גדול שאתה תומך בהם. אם האפליקציה דורשת התחברות, הכן חשבון דמו בהערות לבדיקה, כשה-backend שלך פועל.