מה באמת כולל תמיכה באפליקציות מובייל?
אנחנו תומכים באפליקציות מובייל לאחר פרסומן ב-App Store וב-Google Play. זה לא רק תיקון באגים — זה ניטור יציבות מתמשך, התאמה לגרסאות מערכת הפעלה חדשות, ותיקונים חמים מהירים כדי לשמור על שביעות רצון המשתמשים. עם ניסיון של 7+ שנים בתמיכה במובייל ויותר מ-200 אפליקציות מתוחזקות, אנחנו מבטיחים שיעור משתמשים ללא קריסות מעל 99.5% ברוב הפרויקטים.
גרסת ה-iOS האחרונה משנה את ההתנהגות של Background App Refresh, עדכון אנדרואיד מרכזי מחמיר את מדיניות שירותי הרקע, ודגמי אייפון חדשים עם יחסי מסך שונים שוברים לייאאוטים מקודדים. כל זה דורש מענה ללא מחזור פיתוח מלא. הגישה שלנו מקצרת את זמן התגובה לקריסות פי 3 בהשוואה לממוצע בתעשייה וחותכת בחצי את הזמן לתיקון בעיות קריטיות.
ניטור קריסות בסביבת ייצור
Firebase Crashlytics שולח התראה כאשר שיעור הקריסות עולה מעל סף מסוים. אבל לא מספיק לקבל התראה — צריך תהליך תגובה. אנחנו מגדירים התראות ב-Slack/Telegram עם ציון המשתמשים המושפעים וקצב ההתפשטות.
המדד שאנחנו בודקים ראשון: שיעור משתמשים ללא קריסות. מתחת ל-99.5% — אות אזהרה. מתחת ל-99% — אירוע חריג. Google Play Console ו-App Store Connect מציגים מדדים משלהם, שמחושבים אחרת מ-Crashlytics — פער הוא דבר נורמלי. לפרשנות נכונה, אנחנו מסתמכים על תיעוד רשמי ומצלבים עם נתוני הקונסולה.
תרחיש טיפוסי: אחרי עדכון מינורי של מערכת ההפעלה, מופיעה קריסה חדשה ב-UISheetPresentationController במכשירים עם הגרסה הזו וגרסת אפליקציה ספציפית. Crashlytics מראה 0.3% משתמשים מושפעים אבל קצב גדילה. טיפול מהיר: בדיקה על מכשיר, איתור הגורם (התנהגות שונה של detents במערכת ההפעלה החדשה), ושחרור תיקון חם.
עבור React Native, אנחנו משתמשים בנוסף ב-Sentry עם breadcrumbs — אפשר לראות אילו פעולות קדמו לקריסה. עבור Flutter — sentry_flutter עם WidgetsFlutterBinding.ensureInitialized() ו-runZonedGuarded.
איך מגיבים מהר לעלייה בשיעור הקריסות?
יישמנו SLA עם זמני תגובה: קריסה קריטית (שיעור קריסות >1%) — תיקון חם תוך 24-48 שעות עד הפרסום, 3-7 ימים עד שהבדיקה של Apple עוברת. Expedited Review זמין לבעיות אבטחה ופונקציונליות קריטיות. עבור אנדרואיד — בדיקה מזורזת דרך Google Play Console. יש לנו 98% הצלחה באישור בדיקות מזורזות.
תיקונים חמים: מה אפשר לעשות בלי פרסום בחנות
App Store לא מאפשרת לשנות קוד בר-הרצה ללא בדיקה (הנחיית בדיקה 2.5.2). אבל יש מנגנונים חוקיים להתערבות מהירה.
Remote Config (Firebase או מותאם אישית) — שינוי התנהגות דרך דגלים ללא עדכון. השבתת תכונה בעייתית, הצגת באנר תחזוקה, שינוי נקודות קצה של URLs — הכל בלי שחרור גרסה. קריטי לניסויי מונטיזציה ולחזרות מהירות.
עדכוני OTA (React Native): react-native-code-push (Microsoft CodePush) או Expo Updates מאפשרים עדכון של ה-JS bundle ללא App Store. מגבלה: רק קוד JS, מודולים native דורשים עדכון מלא. עם זאת, זה נופל תחת מגבלות ההנחיות אם מנצלים לרעה — אי אפשר לשנות פונקציונליות ליבה דרך OTA.
Expo EAS Update — אלטרנטיבה מודרנית ל-CodePush לפרויקטי Expo עם תמיכה בערוצים (production/staging) וחזרה לגרסה קודמת.
למה אנחנו בודקים מול כל גרסת מערכת הפעלה מרכזית?
Apple מכריזה על בטא iOS ביוני (WWDC), והגרסה הסופית יוצאת בספטמבר. זה נותן שלושה חודשים לבדיקות. בפועל, צוותים רבים מתחילים באוגוסט ומקבלים הפתעות ביום ההשקה. אנחנו מתחילים לבדוק מיד אחרי הבטא הראשונה — זה נותן מרווח של 3-4 חודשים. הלקוחות שלנו נמנעים כך מ-90% מהקריסות הקשורות למערכת ההפעלה.
אזורים קריטיים לבדיקה עם כל עדכון מערכת הפעלה מרכזי:
| רכיב | מה משתנה | סיכונים |
|---|---|---|
| Privacy Manifest | נדרש מגרסאות מסוימות של מערכת ההפעלה עבור APIs ספציפיים | דחייה בבדיקה |
מחזור חיים של UIScene |
שינויים בניהול סצנות | סיום משימות רקע |
אנימציות UICollectionView/UITableView |
שינויי אנימציות ברירת מחדל | באגים ויזואליים |
| Swift Concurrency | התנהגות של TaskGroup, async let | מרוצי נתונים |
באנדרואיד באופן דומה: יש לעדכן את target SDK מדי שנה (Google Play דורש targetSdk בגרסה מינימלית פחות אחת). מעבר מ-target SDK אחד למשנהו משנה התנהגות עבור שירותי רקע, מקלטי שידור ו-intents מרומזים.
חוב טכני ותכנון
תמיכה היא לא רק תגובה לבאגים. אנחנו מתכננים חוב טכני לתוך ה-backlog: תלויות מיושנות עם פרצות ידועות (npm audit / bundler-audit), APIs שהוצאו משימוש שיוסרו ב-Xcode הבא, ספריות ללא תחזוקה פעילה.
עדכוני תלויות דרך Dependabot (GitHub) או Renovate יוצרים אוטומטית PRs כשגרסאות חדשות יוצאות. זה לא מבטל בדיקות אבל מונע מצב של "לא עדכנו ספריות שנתיים."
גרסת מערכת הפעלה מינימלית נתמכת — אנחנו בודקים מדי שנה. Apple מפרסמת סטטיסטיקות גרסאות, ול-Google יש לוח מחוונים של הפצת אנדרואיד. העלאת הגרסה המינימלית מסירה לעיתים קרובות כמות משמעותית של קוד עוקף.
תוצרים ולוחות זמנים
| תוצר | תיאור |
|---|---|
| הגדרת ניטור | Crashlytics, Sentry או כלי מותאם אישית משולב עם Slack/Telegram |
| SLA לתגובת אירועים | 24/7 לקריטי, 48 שעות לגבוה |
| תיעוד | קריסות ידועות, פתרונות עוקפים ו-runbooks |
| גישה לקונסולה | App Store Connect, Google Play Console משותפים |
| הדרכת צוות | על Crashlytics, Remote Config ועדכוני OTA |
| דוחות חודשיים | מדדי יציבות, מגמות והמלצות |
לוחות זמנים בקירוב: מחודש אחד (תמיכה בסיסית) ועד 6+ חודשים (תחזוקה מלאה עם פיתוח תכונות). העלות מחושבת באופן פרטני — השאירו פנייה ונכין הצעה מסחרית תוך 24 שעות. אנחנו מציעים גם הערכת פרויקט: צרו קשר ונדייק את הפרטים ב-15 דקות. הזמינו ביקורת מצב נוכחי — נעריך את הפרויקט ונציע את פורמט התמיכה האופטימלי.