React Native DevTools החליף את Flipper כברירת המחדל לדיבאג ב-2026. מדריך מעשי לפתיחה, דיבאג רשת, רכיבים ופרופיילר, כולל טיפים לפרויקטי Expo ו-bare RN.
עודכן: 23 באוגוסט 2026
React Native DevTools הוא כלי הדיבאג הרשמי החדש ב-React Native, שהחליף באופן מלא את Flipper ואת Chrome Remote Debugging הישן החל מגרסה 0.76, ומאוחד ב-Expo SDK 52 ומעלה. הוא בנוי על גבי פרוטוקול Chrome DevTools (CDP) ומחובר ישירות למנוע Hermes, כך שבסביבת פיתוח מודרנית של 2026 אפשר לדבג רכיבים, רשת, קונסולה ופרופיילר מתוך חלון אחד בדפדפן, בלי הרחבות, בלי Flipper, ובלי bridge ישן.
j בטרמינל של Metro, או דרך Dev Menu (Cmd+D באייפון, Cmd+M באנדרואיד).אז בואו נסביר בקצרה: React Native DevTools הוא מעטפת חדשה של Chrome DevTools שמותאמת לדיבאג של אפליקציות React Native. הרעיון פשוט. במקום להריץ את קוד ה-JavaScript שלכם בתוך Chrome (כמו שעשה Remote JS Debugging הישן), הדיבאגר מתחבר ישירות למנוע Hermes שרץ על המכשיר או על הסימולטור, דרך פרוטוקול CDP הסטנדרטי של דפדפן Chrome. זה אומר שהקוד רץ באותה סביבה שבה הוא ירוץ בפרודקשן (אותו JIT/AOT, אותה גישה ל-JSI, אותם timers), ולא בסביבת V8 שונה שגרמה בעבר לבאגים ש"נעלמים כשמכבים דיבאגר".
בכנות, אני עצמי הגעתי ל-React Native מהצד של פיתוח Web, ובעולם ה-Web הרגלנו לאהוב את DevTools של Chrome: Sources, Console, Network, Elements. React Native DevTools מביא בדיוק את אותם tabs, בהתאמה למכשיר. Elements הפך ל-Components של React, Network מציג בקשות שיוצאות מ-fetch/XMLHttpRequest בתוך האפליקציה, ו-Profiler רץ על React tree אמיתי מעל Fabric. אם הגעתם מ-Web כמוני, ההרגשה בבית מיידית. למי שמגיע ממובייל native, זה תרגום ברור של מה שהיה ב-Xcode Instruments ו-Android Studio Profiler לעולם ה-JS. לקריאה על ההקשר הרחב יותר, ראו את המדריך המלא לארכיטקטורה החדשה של React Native.
מבחינת ארכיטקטורה, DevTools מתחבר דרך Metro (השרת המקומי בפורט 8081 כברירת מחדל). Metro חושף endpoint בשם /open-debugger, ולחיצה על j בטרמינל שולחת בקשה שפותחת חלון Chrome חדש עם ה-frontend הרלוונטי. ה-frontend הזה הוא בעצם fork של Chrome DevTools עם כמה כפתורים מוסתרים (למשל CSS Editor, שלא רלוונטי), ותוספת של הלשונית "React" הידועה מהרחבה הישנה של Chrome. לפירוט המלא של הפרוטוקול, שווה להציץ בתיעוד הרשמי של Chrome DevTools Protocol.
לא. Flipper הוסר מהתבנית של React Native החל מגרסה 0.74, ולא נתמך רשמית ב-New Architecture. Meta הפסיקה להוסיף אליו יכולות חדשות, וב-2026 רוב הפלאגינים הרלוונטיים (Layout, Network, AsyncStorage, Redux) עברו למצב "community-maintained" עם עדכונים דלילים. הצוות של React Native החליט להעביר משאבים ל-DevTools החדש כי הוא מבוסס על פרוטוקול סטנדרטי שכל הדפדפנים כבר מדברים בו, במקום stack ייעודי של Meta עם native bridges לכל platform.
מה זה אומר בפועל? אם אתם מתחזקים פרויקט ישן שמשתמש ב-Flipper, הוא עדיין ירוץ כל עוד אתם על Old Architecture ו-RN < 0.76. אבל ברגע שתשדרגו לגרסה חדשה או תפעילו Fabric, החיבור פשוט ייעלם ותצטרכו להסיר את התלות. במקרה של Expo, פרויקטים על SDK 50+ כבר לא כוללים את Flipper בכלל בברירת המחדל. עבור פרויקטים חדשים ב-2026, פשוט אל תתקינו את Flipper. המחיר של תחזוקה של native modules ב-iOS וב-Android עבור פלאגינים לא נתמכים גדול מהתועלת.
יש שלוש דרכים מקבילות להפעיל את הכלי, וכל אחת מהן מתאימה לתרחיש קצת שונה. הנפוצה ביותר, ולדעתי הנוחה, היא דרך Metro:
# בטרמינל שרץ בו npx expo start / npx react-native start
# פשוט הקישו את המקש j
j
# חלון Chrome ייפתח באוטומטית עם DevTools מחוברים לאפליקציההדרך השנייה היא דרך Dev Menu של האפליקציה עצמה. במכשיר או סימולטור, פתחו את התפריט:
Cmd + DCmd + M (או Ctrl + M ב-Windows/Linux)adb shell input keyevent 82 לאנדרואידבתפריט שיפתח בחרו "Open DevTools". הדרך השלישית, שאני משתמשת בה ב-CI ובכלים אוטומטיים, היא לפתוח את ה-URL של Metro ישירות בדפדפן. הכתובת http://localhost:8081/debugger-ui/ מבצעת redirect ל-DevTools החדש. שימו לב שיש להשאיר את המכשיר או הסימולטור פתוח ומחובר, אחרת החיבור נכשל עם השגיאה "No connected devices".
// package.json: script נוח לפתיחת devtools ל-Expo
{
"scripts": {
"dev": "expo start --dev-client",
"dev:debug": "expo start --dev-client --devtools"
}
}אחת השאלות שאני שומעת הכי הרבה ממפתחי web שעוברים ל-RN היא איפה ה-Network tab. עד React Native 0.79, DevTools החדש לא כלל תמיכה מלאה ב-Network, ורוב הצוותים המשיכו להשתמש בפאקג' חיצוני כמו reactotron-react-native כדי לראות בקשות. החל מ-0.79 יש לשונית Network מלאה עם עמודות Method, Status, Size, Time, בדיוק כמו ב-Chrome DevTools לאתר רגיל. היא תופסת את כל הבקשות שיוצאות דרך fetch, XMLHttpRequest, ולכן גם דרך axios (שמתעטף עליהן).
הדבר החשוב לזכור: הלכידה עובדת רק על בקשות מה-JavaScript. אם אתם קוראים API מתוך native module (למשל ב-URLSession של Swift או OkHttp של Kotlin), הבקשה פשוט לא תופיע. במקרים כאלה עדיין נצטרך Charles Proxy, mitmproxy או Proxyman בצד ה-native. ראו את התיעוד הרשמי של React Native לדיבאג להסבר על מגבלות הלכידה.
// דוגמה — כל בקשה כזו תופיע ב-Network tab עם body ו-headers
async function fetchUser(id: string) {
const res = await fetch(`https://api.example.com/users/${id}`, {
method: 'GET',
headers: { Authorization: `Bearer ${token}` },
});
if (!res.ok) throw new Error(`HTTP ${res.status}`);
return res.json();
}
// חשוב: axios interceptors לא ישברו את הלכידה, כי axios משתמש ב-XHR מתחת.
import axios from 'axios';
const api = axios.create({ baseURL: 'https://api.example.com' });
api.interceptors.response.use(
r => r,
e => { console.warn('API error', e?.response?.status); throw e; }
);ב-DevTools החדש אפשר גם ללחוץ על בקשה בודדת ולראות את ה-Response body, את ה-Timing (DNS, connect, TTFB) ואת ה-Cookies שנשלחו. מה שעדיין חסר יחסית ל-Chrome ה"רגיל": simulate slow network. כאן מומלץ להשתמש ב-Network Link Conditioner של iOS או במגבלות רוחב פס של Android Studio.
הלשונית "Components" מציגה את עץ הרכיבים החי של האפליקציה. אני משתמשת בה בעיקר כדי לפתור שני סוגי בעיות: (1) לזהות רכיבים שמקבלים props לא צפויים או stale, (2) לאתר עצי JSX שגדלים לרוחב עם רכיבים לא מזוהים (למשל Anonymous, סימן ל-React.memo ללא displayName). לחיצה על רכיב מציגה את ה-props, state, hooks ו-context ברגע נתון, ואפשר גם לערוך אותם live כדי לבדוק תגובות UI בלי reload.
ה-Profiler הוא כלי חזק שיצא מהצל בשנה האחרונה. הוא רושם flame chart של רנדרים, ומראה איזה רכיב לקח כמה זמן בכל commit. עבור אפליקציית מובייל שבה 16ms זה פר frame, זה החומר שממנו קורצים אופטימיזציות אמיתיות. מפתח שמגיע מעולם ה-web ילמד בקלות את הכלי, כי הוא זהה לגמרי ל-Profiler של React בדפדפן, רק שהמדידות נלקחות מהמכשיר, לא מ-Chrome.
// דוגמה — עוטפים רכיבים כבדים ב-React.memo עם displayName
// כדי שיופיעו בשם קריא ב-Profiler
import { memo } from 'react';
const ExpensiveRow = memo(function ExpensiveRow({ item }) {
// חישוב יקר
return <Row data={item} />;
});
ExpensiveRow.displayName = 'ExpensiveRow';שילוב מנצח ל-list performance: מפעילים Profiler, גוללים ברשימה במשך 3–5 שניות, עוצרים ההקלטה ומסננים לפי "Ranked". הרכיב עם הזמן הכי גבוה זה המועמד הראשון לאופטימיזציה. אם אתם עובדים עם רשימות ארוכות, מומלץ בכל מקרה לעבור לפתרון שנבנה למובייל. ראו את המדריך שלנו על מעבר ל-FlashList v2.
הלשונית Performance של DevTools זהה לזו של Chrome ומקליטה CPU sampling של ה-JS thread שרץ ב-Hermes. אני מפעילה אותה במיוחד כשיש חשד ל-jank בעליית מסך. לוחצת Record, מבצעת את הפעולה במכשיר, עוצרת, ומחפשת "Long Tasks" (בלוקים אדומים) בציר הזמן. זה חושף פונקציות שמעבדות סינכרונית מעל 50ms, סימן ברור שצריך לעבור ל-InteractionManager.runAfterInteractions או ל-startTransition של React 19. הכרתי את הבאג הזה על בשרי בפרויקט אחרון שלי, כשמסך רשימה נראה סופר-מהיר בסימולטור אבל קפא בענק על מכשיר אנדרואיד ישן.
ה-Memory tab מתאים לחיפוש leaks. אתם מריצים snapshot ראשון, מבצעים מעבר בין מסכים 5–6 פעמים, לוחצים "Collect garbage", ומצלמים snapshot שני. אם ההיפ גדל בעקביות, יש רפרנס שלא משתחרר. לרוב מדובר ב-listener שלא נוקה ב-useEffect cleanup, או ב-timer שנשאר פעיל. ה-Retainers view יראה בדיוק מי מחזיק ברפרנס.
אם אתם עובדים עם אנימציות, שווה לזכור ש-Reanimated 4 מריץ worklets על UI thread נפרד, ולכן פרופיילינג של אנימציות דורש כלים אחרים. הרחבנו על כך במאמר על Reanimated 4 עם Worklets ו-CSS.
ב-Expo, החל מ-SDK 52, React Native DevTools מוכלל אוטומטית. אין מה להתקין ואין מה להפעיל ידנית. פקודת npx expo start חושפת את המקש j באותה צורה כמו ב-bare RN, וגם דרך Expo Dev Client (בבניית Development Build) הכפתור "Open JS debugger" בתפריט מוביל ל-DevTools החדש ולא ל-Chrome remote debugging הישן שהוסר סופית ב-SDK 51.
אם אתם עובדים על גרסת Expo Go (עבור פרוטוטיפים ו-quick demos), התמיכה זהה. עבור אפליקציות בייצור עם native modules מותאמים, חובה לעבור ל-Development Build עם EAS Build. החדשות הטובות הן ש-DevTools עובד ב-Development Build אפילו טוב יותר, כי הוא רואה גם JSI bindings של המודולים שלכם. עיינו ב-מדריך הדיבאג הרשמי של Expo להסבר על ההבדלים בין הסביבות.
// app.json: הגדרות דיבאג מומלצות לפרויקט Expo
{
"expo": {
"jsEngine": "hermes",
"developmentClient": {
"silentLaunch": false
},
"plugins": [
["expo-build-properties", {
"android": { "enableProguardInReleaseBuilds": false },
"ios": { "deploymentTarget": "15.1" }
}]
]
}
}מכיוון שאני מתחזקת כמה פרויקטי RN בפרודקשן, ראיתי כמעט כל תסמונת אפשרית של DevTools שלא נפתח. הנה השלוש הנפוצות ביותר ב-2026:
מופיע בדרך כלל כשה-Metro רץ בפורט אחר או שהמכשיר לא רואה את השרת. הפתרון: ודאו ש-http://localhost:8081/status מחזיר "packager-status:running". באנדרואיד, הריצו adb reverse tcp:8081 tcp:8081. במכשיר פיזי ב-iOS, הזינו את ה-IP של המחשב בתפריט Dev Settings.
קרה לי כשהיה מותקן Chrome DevTools Extension ישן של React בפרופיל של המשתמש. הפתרון: לפתוח את הכלי ב-Incognito, או להסיר את ההרחבה. הלשונית React מובנית ב-DevTools החדש, אין צורך בהרחבה.
אם אתם משתמשים ב-source maps אבל ה-breakpoints לא מפעילים, בדקו שב-Metro רצה אופציית --reset-cache אחרי שינוי babel config. באנדרואיד, אם עשיתם build עם R8 מופעל, ה-source maps של Hermes עשויים לא להתאים. הפעילו bundleInDebug=false ב-gradle.properties.
גם כשאני משתמשת ב-DevTools כברירת מחדל, יש שלושה כלים נוספים שאני שומרת קרובים. הראשון הוא Reactotron, עדיין הכלי הנוח ביותר לפרויקטים עם Redux, MobX או Zustand, כי הוא מאפשר לצפות ב-state changes ולבצע time-travel debugging. הוא לא מחליף את DevTools, אלא משלים אותו.
השני הוא Sentry, לדיבאג בפרודקשן. DevTools עוזר לכם בפיתוח, אבל ברגע שהאפליקציה עולה למשתמשים אמיתיים, אתם רוצים source maps שיעלו אוטומטית ל-Sentry דרך EAS Build, כך שכל crash יופיע עם stack trace קריא. השלישי הוא Expo Dev Tools (הדשבורד ב-localhost:19002), שמכיל שרתי logs, שליחה של deep links לבדיקה, וסקירה של הלוגים של Metro במקום אחד. הוא לא מחליף את DevTools, אלא רץ במקביל.
לגבי management של state בפרויקטים חדשים, בהזדמנות זו שווה להעיף מבט בהשוואה בין Zustand ו-Redux Toolkit ב-React Native 2026. בחירת ה-store משפיעה ישירות על ה-workflow של הדיבאג שלכם. ואם אתם רוצים לזרז אחסון מקומי במקביל, קראו על MMKV כחלופה מהירה ל-AsyncStorage. שני הכלים משנים גם את מה שאתם צריכים לראות ב-DevTools עצמו.
React Native DevTools החליף את Flipper החל מגרסה 0.76. הוא מבוסס על פרוטוקול Chrome DevTools ומחובר ישירות ל-Hermes, ומאחד לתוכו את היכולות של Layout Inspector, Console, Network, React Components ו-Profiler שהיו בעבר פזורות בפלאגינים.
ב-2026 הכלי נבנה ותומך רשמית ב-Hermes בלבד. JSC עדיין קיים ב-RN, אבל דיבאג CDP דורש Hermes, שהוא בכל מקרה ברירת המחדל בפרויקטים חדשים ובכל גרסאות Expo מעל SDK 48.
וודאו שהמכשיר והמחשב באותה רשת Wi-Fi. באנדרואיד, הריצו adb reverse tcp:8081 tcp:8081. ב-iOS, הזינו את ה-IP של המחשב בתפריט "Configure Bundler" של Dev Menu, ואז לחצו j בטרמינל של Metro כדי לפתוח DevTools.
לא ישירות. לצפייה בשינויים ב-Redux store צריך את Reactotron או את הרחבת Redux DevTools דרך @redux-devtools/extension. לעומת זאת, hooks של Zustand וכל state מקומי גלויים ב-Components tab של React DevTools המובנה.
ברוב המקרים הן כן מופיעות, כי axios משתמש ב-XMLHttpRequest שתחתיו, ו-DevTools לוכד XHR. אם הן לא מופיעות, ודאו שאתם על React Native 0.79 ומעלה שבה Network Inspector זמין רשמית, ושלא הפעלתם adapter מותאם של axios (למשל http adapter ב-Node) שעוקף את השכבה של RN.