EAS Update ב-React Native 2026: מדריך OTA מלא (Over-the-Air Updates)

עודכן: 18 בספטמבר 2026

EAS Update הוא שירות ענן של Expo שדוחף עדכוני JavaScript, נכסים (assets) ותצורה לאפליקציית React Native בזמן אמת, בלי לעבור דרך App Store או Google Play. השירות תפס את מקומו של Microsoft CodePush שהופסק סופית בסוף 2024, והפך לסטנדרט דה-פקטו לעדכוני OTA (Over-the-Air) גם ב-Expo וגם ב-Bare React Native. במדריך הזה אסביר איך אני מגדיר, מפרסם ומבצע rollback ל-EAS Update ב-2026, עם runtime versions מבוססי fingerprint שחוסכים המון כאב ראש.

• EAS Update מחליף את CodePush שהוצא משירות ב-15 במרץ 2025, וזמין עבור כל פרויקט React Native, לא רק Expo managed.
• עדכונים נשלחים לפי channels (למשל production, staging) ו-runtime versions. השילוב הוא זה שקובע איזה build יקבל איזה update.
• Fingerprint runtime versions (SDK 52+) מחשבים אוטומטית hash של הקוד ה-native ומונעים unmatched updates שגורמים לקריסות.
• אפשר לדחוף רק שינויי JavaScript, TypeScript, JSON ו-assets. שינויים ב-native code דורשים build חדש והעלאה לחנות.
• Rollout הדרגתי ו-rollback מיידי מתבצעים דרך פקודת eas update:republish או מדשבורד expo.dev.
• ה-tier החינמי מעניק עד 1,000 MAU (Monthly Active Users), ואחריו החיוב לפי שימוש.

מה זה EAS Update ואיך הוא עובד

EAS Update הוא רכיב מתוך Expo Application Services (EAS) שמאפשר לפרסם עדכונים לאפליקציה שכבר הותקנה במכשיר של המשתמש, בלי דרישה להוריד גרסה חדשה מהחנות. השירות עובד באמצעות ספריית expo-updates שנטענת יחד עם ה-JavaScript bundle, בודקת מול שרתי Expo אם קיים update תואם ל-channel ול-runtime version של ה-build, ומורידה אותו ברקע. בהפעלה הבאה של האפליקציה ה-bundle החדש נטען במקום זה שהיה מקומפל ב-native.

הזרימה הבסיסית נראית כך: אני מריץ eas update --branch production --message "Fix crash on login", EAS Update בונה JavaScript bundle חדש עם Metro, מעלה אותו ל-CDN גלובלי, ורושם רשומה חדשה במאגר Updates של הפרויקט. כל מכשיר שמריץ build המחובר ל-channel שממופה ל-branch הזה יקבל את העדכון בהפעלה הבאה, בדרך כלל תוך פחות משנייה על רשתות סלולריות סבירות.

חשוב להבין את ההבדל בין OTA update לבין binary update: OTA משנה רק את שכבת ה-JavaScript ואת ה-assets (תמונות, פונטים, JSON). כל שינוי בקוד ה-native, כמו התקנת ספרייה חדשה שדורשת linking, שינוי ב-Info.plist, או שדרוג SDK של Expo, מחייב build חדש דרך eas build והעלאה חוזרת לחנות.

מוות של CodePush ולמה עוברים ל-EAS Update

Microsoft הכריזה באפריל 2024 על סיום החיים של App Center, כולל שירות CodePush, ו-כיבתה את השירות סופית ב-15 במרץ 2025. הפרויקט הועבר לקוד פתוח תחת microsoft/code-push ב-GitHub, אבל בפועל אין תחזוקה פעילה ואין שרת מנוהל שאפשר להתחבר אליו בלי לפרוס בעצמך. עבור צוותים שהיו מבוססי CodePush, המעבר ל-EAS Update הוא הנתיב הרשמי המומלץ על ידי צוות React Native.

ב-2026 היתרונות של EAS Update על פני CodePush די בולטים. Fingerprint runtime versions מחשבים hash אוטומטי של כל תלות native ומונעים מצב שבו update לא תואם קורס באפליקציה. Preview updates מאפשרים ל-QA לסרוק QR code ולראות שינוי בזמן אמת. וגם, יש תמיכה מלאה ב-New Architecture (Fabric ו-TurboModules) מתוך הקופסה. אם אתם עוברים מ-CodePush, אפשר להשאיר את שני השירותים במקביל בזמן ההגירה, על ידי הוספת שני מודולי updates לפרויקט. עשיתי בדיוק את זה בשני פרויקטים ב-2025, ובאמת החפיפה הצילה אותנו מכמה rollbacks במקרים גבוליים.

להבנה מלאה של הארכיטקטורה שעליה EAS Update מסתמך, כדאי לקרוא את המדריך המלא לארכיטקטורה החדשה של React Native 2026. שינויים מסוימים בארכיטקטורה משפיעים ישירות על ה-fingerprint שמחושב ל-runtime version.

התקנה והגדרה של expo-updates

בפרויקט Expo מנוהל (managed workflow), expo-updates כבר מותקן כברירת מחדל. ההגדרה מתחילה בפקודה יחידה:

npx expo install expo-updates
eas update:configure

הפקודה השנייה מוסיפה אוטומטית את השדות הדרושים ל-app.json, יוצרת קבצי תצורה ל-EAS, ומגדירה projectId ייחודי בפרויקט. תוצאת התצורה נראית בערך כך:

{
  "expo": {
    "name": "MyApp",
    "runtimeVersion": {
      "policy": "fingerprint"
    },
    "updates": {
      "url": "https://u.expo.dev/00000000-0000-0000-0000-000000000000",
      "fallbackToCacheTimeout": 0
    },
    "plugins": ["expo-updates"]
  }
}

השלב הבא הוא ליצור build שיודע לדבר עם EAS Update. משתמשים ב-eas build --profile preview ליצירת internal distribution build שאפשר להתקין ולבדוק, או ב-eas build --profile production ליצירת build שיועלה לחנות. בזמן הבנייה ה-fingerprint מחושב ומוטמע ב-binary; כל update שיפורסם מאוחר יותר חייב להתאים לאותו fingerprint כדי להיטען.

Channels, Branches ו-Runtime Versions

ההיררכיה של EAS Update מבוססת על שלושה מושגים שכדאי להבין ממש טוב: branch הוא סדרה של updates עם היסטוריה (בדומה ל-git branch), channel הוא מזהה שמוטמע ב-build ומצביע ל-branch מסוים, ו-runtime version הוא ה-fingerprint שקובע איזה binary תואם לאיזה update. כדי לפרסם update לפרודקשן, ה-build חייב להיות ב-channel המקושר ל-branch שאליו דוחפים, וה-runtime version חייב להיות זהה. אם משהו לא מסתדר, בדרך כלל אחת משלוש הנקודות האלה שבורה.

הגדרת channels בקובץ eas.json:

{
  "build": {
    "preview": {
      "distribution": "internal",
      "channel": "preview"
    },
    "production": {
      "channel": "production"
    }
  }
}

ניהול branches מרובים

המבנה הנפוץ בצוותים שוקדים על עדכונים תכופים הוא שלוש שכבות: branch production ליציבות מלאה, branch staging לבדיקות QA לפני שחרור, ו-branch development לבדיקות מהירות של PR. אפשר להעביר update בין branches עם eas update:republish --branch staging --destination-branch production. זו הדרך הבטוחה להעלות update שכבר נבדק, בלי לבנות אותו מחדש.

פרסום עדכון OTA לפרודקשן

פרסום update בסיסי הוא פקודה יחידה:

eas update --branch production --message "Fix login button color on dark mode"

הפקודה תבצע bundle של הפרויקט עם Metro, תעלה את התוצר ל-CDN, ותציג את מזהה ה-update. משתמשים שיפתחו את האפליקציה יקבלו את ה-update ברקע בהפעלה הבאה. ברוב המקרים ההורדה שקופה לחלוטין. מפתחים שרוצים לשלוט ב-UX של ההתקנה (למשל להציג הודעה "עדכון חדש זמין") משתמשים ב-hook של expo-updates:

import * as Updates from 'expo-updates';

function useCheckForUpdates() {
  const { isUpdateAvailable, isUpdatePending } = Updates.useUpdates();

  useEffect(() => {
    if (isUpdatePending) {
      Alert.alert(
        'עדכון זמין',
        'האפליקציה תתחיל מחדש כדי להחיל את העדכון',
        [{ text: 'המשך', onPress: () => Updates.reloadAsync() }]
      );
    }
  }, [isUpdatePending]);

  return { isUpdateAvailable };
}

אימות ה-update לפני פרסום

הפקודה eas update --branch preview --auto יוצרת update ומייצרת QR code שאפשר לסרוק עם Expo Go או dev client. זו דרך מהירה לוודא שה-update תקין לפני שדוחפים לפרודקשן. בשילוב עם React Native DevTools לדיבאג אפשר לפתוח את ה-update ולבדוק לוגים ואת ה-network בזמן אמת.

Rollback ו-Rollout הדרגתי

Rollback ב-EAS Update לא מוחק updates. הוא פשוט מפרסם מחדש update ישן יותר כ-update החדש ביותר. הפקודה:

eas update:republish --branch production --group <previous-update-group-id>

מוצאים את מזהה ה-group של ה-update הקודם דרך eas update:list --branch production. תוך שניות, כל המכשירים שיפתחו את האפליקציה יקבלו את הגרסה הישנה. זו יכולת קריטית שכדאי לתרגל לפני שיש באג. באמת, פעם אחת שהייתי צריך לעשות rollback ב-3 לפנות בוקר, גיליתי שאני לא זוכר את התחביר. מאז אני שומר קובץ runbook קצר בכל repo.

Rollout הדרגתי לאחוז מהמשתמשים

מ-2025, EAS Update תומך ב-staged rollouts, כלומר שחרור update לאחוז מסוים מהמשתמשים לפני חשיפה מלאה. זה מאפשר לתפוס באגים בגרסה מסוכנת בלי להשפיע על כלל המשתמשים. דוגמה:

eas update --branch production --message "New checkout flow" --rollout-percentage 10

לאחר מעקב מטריקות למשך יום או יומיים, אפשר להעלות ל-50% ואז ל-100% דרך dashboard או דרך פקודת eas update:edit. במקביל, שילוב עם Sentry או Firebase Crashlytics מאפשר להריץ בדיקת סף על שיעור הקריסות ולעצור rollout אוטומטית אם התקבלה חריגה.

אינטגרציה עם CI/CD

הזרימה הסטנדרטית לצוות של שלושה מפתחים ומעלה מוסיפה שלב "publish update on merge to main" ב-GitHub Actions או GitLab CI. דוגמה ל-workflow מלא:

name: EAS Update
on:
  push:
    branches: [main]

jobs:
  update:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: npm ci
      - uses: expo/expo-github-action@v8
        with:
          eas-version: latest
          token: ${{ secrets.EXPO_TOKEN }}
      - run: eas update --branch production --auto --non-interactive

הדגל --auto מפיק אוטומטית message מתוך commit message של git, ו---non-interactive מונע שאלות אינטראקטיביות. עבור צוותים גדולים כדאי להוסיף שלב אימות שרץ בדיקות (npm test, npm run typecheck) לפני publish, כדי למנוע דחיפת קוד שבור. בפרויקט האחרון שלי הוספתי גם שלב שמתייג את ה-update עם ה-git SHA, וזה עזר מאוד בזמן דיבאג של crash reports.

EAS Update בפרויקט Bare React Native

EAS Update לא דורש שהפרויקט יהיה Expo Managed. הוא עובד גם בפרויקט React Native "בר" שנוצר עם npx @react-native-community/cli init. ההתקנה דורשת קצת יותר עבודה:

npm install expo expo-updates
npx expo install --fix
npx pod-install

לאחר מכן צריך להוסיף ידנית תצורה ל-ios/AppDelegate.mm ול-android/app/src/main/AndroidManifest.xml. ה-מדריך הרשמי של Expo להתקנת expo-updates ב-bare workflow מפרט כל שלב, עם הבדלים בין iOS ו-Android. ב-2026 יש plugin חדש שממכן חלק מהעבודה, אבל התהליך עדיין דורש הבנה של Xcode ו-Gradle.

שילוב עם Firebase או Sentry

אחרי התקנה, כדאי לחבר את מזהה ה-update לדיווחי crash. בקובץ הכניסה של האפליקציה:

import * as Updates from 'expo-updates';
import * as Sentry from '@sentry/react-native';

Sentry.setContext('update', {
  updateId: Updates.updateId,
  channel: Updates.channel,
  runtimeVersion: Updates.runtimeVersion,
});

כשקריסה תדווח, יהיה ברור איזה update גרם לה. חיסכון עצום בזמן דיבאג, אני מבטיח. בפרויקטים גדולים כדאי גם לתייג את ה-EAS Update dashboard עם git commit hash, כדי לקשר בין update לגרסה ב-repository.

שאלות נפוצות

האם CodePush עדיין נתמך ב-2026?

לא. Microsoft כיבתה את שרתי App Center כולל CodePush ב-15 במרץ 2025. הקוד עדיין זמין בתור open source ב-GitHub, אבל אין שירות מנוהל, אין תיעוד עדכני ואין תמיכה רשמית. EAS Update הוא הפתרון הרשמי המומלץ על ידי צוות React Native.

אילו שינויים אפשר לדחוף דרך OTA בלי בדיקת חנות?

כל שינוי שנמצא בשכבת ה-JavaScript, TypeScript, JSON ו-assets (תמונות, פונטים), למשל עדכוני UI, תיקוני באגים בלוגיקה, שינויים בטקסטים ותרגומים. שינויים בקוד native, הוספת ספריות שדורשות linking, או שדרוג SDK של Expo דורשים build חדש והעלאה לחנות.

כמה עולה EAS Update ב-2026?

ה-tier החינמי כולל עד 1,000 MAU (Monthly Active Users). מעבר לזה, ה-Production plan עולה 19$ לחודש וכולל 200,000 MAU, וה-Enterprise plan מציע חיוב לפי שימוש עם SLA. החיוב מחושב לפי מכשירים ייחודיים שביקשו update בחודש נתון, לא לפי מספר ההורדות.

איך מבצעים rollback כאשר update שבור עלה לפרודקשן?

מריצים eas update:list --branch production כדי למצוא את מזהה ה-group של ה-update הקודם התקין, ואז eas update:republish --branch production --group <id>. ה-update הישן יופץ כ-update החדש ביותר תוך שניות, ומשתמשים יקבלו אותו בהפעלה הבאה של האפליקציה.

האם EAS Update עובד עם New Architecture (Fabric ו-TurboModules)?

כן, במלואו. משדרוג ל-SDK 52 ומעלה יש תמיכה מובנית ב-Fabric, TurboModules ובמצב bridgeless. ה-fingerprint runtime version מחשב אוטומטית hash של כל התצורה, כולל דגלי New Architecture, כך שאם משדרגים את הארכיטקטורה של האפליקציה, EAS Update ידע שצריך build חדש ולא ידחוף update לא תואם.

מה ההבדל בין channel ל-branch ב-EAS Update?

Branch הוא סדרה של updates עם היסטוריה, כמו branch ב-git. Channel הוא מזהה שמוטמע ב-binary בזמן build ומצביע ל-branch מסוים. יתרון ההפרדה: אפשר להעביר channel מ-branch אחד לאחר (למשל להצביע production ל-branch hotfix זמנית) בלי לבנות binary חדש.