React Native DevTools: Дебъгване на React Native приложения през 2026

Пълно ръководство за React Native DevTools през 2026: как да дебъгвате с Hermes, breakpoints, Network инспектор, Performance Profiler и source maps в продакшън.

React Native DevTools Ръководство 2026

Актуализирано: 21 юни 2026

React Native DevTools са официалните вградени инструменти за дебъгване, които идват с React Native 0.76 и нагоре, и заменят остарелите Flipper и legacy remote debugger. След като съм мигрирал шест продакшън приложения от Flipper през последните осемнайсет месеца, мога да кажа категорично — новият стек, базиран на Chrome DevTools Protocol и Hermes, е значително по-стабилен, по-бърз и най-важното, той е един инструмент, а не зоопарк от плъгини. В това ръководство ще ви покажа как да дебъгвате React Native приложение през 2026 от нула, без излишен церемониал.

  • React Native DevTools са вградени от версия 0.76 и се отварят с натискане на j в Metro терминала или през Dev Menu.
  • Flipper беше официално премахнат от React Native template-а през 2024 и не се поддържа за New Architecture проекти.
  • Новите DevTools работят само с Hermes JavaScript engine и използват Chrome DevTools Protocol (CDP) за комуникация.
  • Network inspector, React Components panel и Performance profiler работят директно върху работещото приложение, без допълнителни нативни зависимости.
  • За Expo проекти DevTools се отварят автоматично от Expo CLI. Не е нужна никаква конфигурация.
  • Source maps за продакшън грешки изискват изрично качване в Sentry, Bugsnag или EAS Insights. Metro не го прави автоматично.

Какво представляват React Native DevTools

React Native DevTools са самостоятелно frontend приложение, базирано на Chrome DevTools, което се свързва директно към Hermes runtime-а на работещото ви приложение чрез Chrome DevTools Protocol. Инструментът е официално поддържан от Meta и е част от стандартния React Native template от версия 0.76 нататък. Не е нужна инсталация на отделен пакет, не е нужно flipper-plugin-* в Podfile, нищо. Един бутон в Dev Menu и сесията започва.

Под капака DevTools използват същите протоколи като браузърния Chrome DevTools, но интерфейсът е специално нагласен за React Native. Това означава, че работят Sources, Console, Network, Performance и Memory панелите от стандартния Chrome DevTools, плюс React-специфичните Components и Profiler панели, които познавате от React DevTools браузърното разширение. Целият комплект е един прозорец.

Важно да се отбележи, че DevTools работят само с Hermes. Ако по някаква причина още използвате JavaScriptCore (JSC), няма да получите breakpoints, Network таб или Profiler. През 2026 това не би трябвало да е проблем, защото Hermes е по подразбиране от React Native 0.70 насам, но виждам стари проекти, които изрично са изключили Hermes за съвместимост с някой стар плъгин. Време е да го включите обратно.

Защо Flipper беше премахнат и какво го замени

Flipper беше отделен desktop клиент, който комуникираше с приложението чрез react-native-flipper мост и плъгини. Звучеше добре на хартия, но на практика създаваше повече проблеми, отколкото решаваше: счупваше се при всяка нова Xcode версия, изискваше специфични версии на Pods, и плъгините се разпадаха при ъпдейт на React Native. През октомври 2024 Meta официално премахна Flipper интеграцията от стандартния template. Детайлите са в RFC за премахването на Flipper.

Замяната не е един нов инструмент, а комбинация. React Native DevTools поемат debugging, network и profiling. react-native-devtools-frontend поема Components и Profiler. LogBox остава за warnings и errors, а за по-специфични нужди (детайлно мрежово прихващане например) се препоръчват инструменти на ниво ОС като Charles Proxy или mitmproxy. Първо звучи като крачка назад, но в практиката е по-чисто. Всеки инструмент прави едно нещо добре.

Ако още имате flipper или react-native-flipper зависимости в проекта си, премахнете ги още днес. Те няма да работят с New Architecture и просто увеличават размера на bundle-а. Честно казано, бих избрал прехода към новите DevTools пред това да чакам, защото с всеки нов React Native release разликата нараства.

Как да отворите React Native DevTools

Има три начина да стартирате DevTools, в зависимост от това как работите:

  1. От Metro терминала: когато Metro bundler върви, натиснете клавиша j. DevTools прозорецът ще се отвори автоматично, ако имате Google Chrome или Microsoft Edge инсталиран.
  2. От Dev Menu: разклатете устройството (или натиснете Cmd+D на iOS симулатора, Cmd+M на Android emulator) и изберете Open DevTools.
  3. Програматично: ако работите с Expo, командата npx expo start предлага j като клавиш по същия начин като Metro.

За проекти с по-комплексен setup, ето минимална конфигурация в metro.config.js, която гарантира, че DevTools ще работят правилно с custom transformers:

// metro.config.js
const { getDefaultConfig } = require('@react-native/metro-config');

const config = getDefaultConfig(__dirname);

// Уверете се, че source maps са включени за DevTools
config.transformer = {
  ...config.transformer,
  getTransformOptions: async () => ({
    transform: {
      experimentalImportSupport: false,
      inlineRequires: true,
    },
  }),
};

// Hermes source maps са нужни за readable stack traces
config.serializer = {
  ...config.serializer,
  getRunModuleStatement: (moduleId) =>
    `__r(${JSON.stringify(moduleId)});`,
};

module.exports = config;

Debug конзола, breakpoints и step-through

След като DevTools са отворени, отидете на Sources таба. Ще видите дървовидна структура на bundle-а. Typescript и JavaScript файловете ви ще са под localhost:8081, после ., после имена на папки от вашия проект. Кликнете на ред в кода, за да поставите breakpoint, точно както в браузърен debug.

Hermes през 2026 поддържа пълен Chrome DevTools Protocol debugger, което означава:

  • Step over / Step into / Step out, които работят на ниво JavaScript, дори в async функции.
  • Conditional breakpoints: десен бутон на breakpoint, въведете израз като userId === 42.
  • Logpoints: breakpoint, който не спира изпълнението, а отпечатва съобщение. Невероятно полезно за дебъгване на event handlers без да пускате console.log навсякъде.
  • Watch expressions, които следят стойности на променливи в реално време.

Console табът работи както в браузъра: console.log, console.table, console.warn и console.error се появяват тук. Едно нещо, което често пропускат разработчиците (а аз самият го пропусках с години), е че можете да изпълнявате произволен JavaScript директно в Console, и този код вижда модулите от вашия bundle. Например за бързо тестване на API hook:

// В DevTools Console:
const store = require('./src/store').default;
store.getState().user;
// => { id: 42, name: 'Maria', role: 'admin' }

// Тригерирайте action ръчно за тестване:
store.dispatch({ type: 'user/logout' });

Това е златна функция за дебъгване на state management. Виждал съм екипи да губят часове в опити да възпроизведат бъг, когато могат просто да го тригерират от конзолата. За по-задълбочено покритие на state дебъгването вижте нашето ръководство за Zustand и TanStack Query.

Инспекция на мрежови заявки

Network табът показва всички fetch и XMLHttpRequest заявки, плюс WebSocket трафик. Колоните са същите като в браузърния Chrome DevTools: Name, Status, Type, Initiator, Size, Time. Кликнете на заявка, за да видите Headers, Payload, Response и Timing.

За debug на специфични заявки често ползвам това в инициализацията на приложението:

// В index.js или App.tsx, само в __DEV__:
if (__DEV__) {
  const originalFetch = global.fetch;
  global.fetch = (...args) => {
    const [url, options] = args;
    console.log('[fetch]', options?.method || 'GET', url);
    return originalFetch(...args).then((response) => {
      console.log('[fetch:done]', response.status, url);
      return response;
    });
  };
}

Това не е заместител на Network таба, но е полезно за бързи проверки. По-важно е, че DevTools Network табът поддържа Preserve log опцията, така че при reload на приложението логовете остават. Включете я веднага щом отворите DevTools, защото при hot reload иначе ще загубите контекст.

За GraphQL заявки (Apollo, Relay, urql), отговорите се появяват в Response таба като raw JSON. Това не е толкова приятно, колкото GraphiQL панел в стария Flipper, но за повечето случаи е достатъчно. Ако дебъгвате GraphQL интензивно, инсталирайте Apollo Client DevTools като отделно разширение. Те работят чрез __APOLLO_CLIENT__ hook и не зависят от Flipper.

Performance profiler и React Profiler

Тук Hermes наистина блести през 2026. Performance табът записва CPU sample profile, който можете да отворите в стандартния Chrome flame chart. За React-специфичен профайлинг отидете на Profiler таба и натиснете record, направете действието, което искате да измерите, и спрете записа.

React Profiler-ът показва commit-и (renders) с цветово кодиране. Зелено за бързи, червено за бавни. За всеки render виждате кои компоненти са се rerender-нали и колко време са отнели. Това е инструмент номер едно за намиране на излишни re-render-и. Типичен workflow:

  1. Започнете запис в Profiler.
  2. Извършете бавното действие (отваряне на screen, scroll през FlatList, въвеждане на текст).
  3. Спрете записа.
  4. Прегледайте flame chart за компоненти с дълга жълто-червена лента.
  5. Кликнете на компонент, за да видите why-did-you-render причина (props change, parent rerender, state change).

За FlatList и анимация-тежки сцени включете и Performance Monitor overlay (Dev Menu, после Show Perf Monitor). Той показва JS thread FPS, UI thread FPS и Views allocated в реално време върху самото приложение. Ако виждате JS FPS под 55 на статичен екран, имате rerender проблем. Ако UI FPS пада при анимация, проблемът е в нативния layer, често Reanimated worklet или твърде много View-ове. За оптимизация на анимации препоръчвам нашето ръководство за Reanimated 4 CSS анимации, което покрива новия CSS engine.

Дебъгване на продакшън грешки и source maps

DevTools работят само в development. За продакшън грешки нямате избор освен да разчитате на crash reporting (Sentry, Bugsnag) плюс качени source maps. Metro не качва source maps автоматично, така че трябва да го направите ръчно или през CI.

За Expo Application Services (EAS) workflow, командата за качване в Sentry е:

# След eas build, source maps са в build артефактите
npx sentry-expo-upload-sourcemaps dist \
  --org=my-org \
  --project=my-app \
  --auth-token=$SENTRY_AUTH_TOKEN

За bare React Native проекти използвайте @sentry/react-native wizard, който добавя build phase в Xcode и Gradle task в Android, които автоматично качват source maps при release build. Документацията е изчерпателна на официалната React Native DevTools страница.

Една често пропускана стъпка: за Hermes bundle source maps трябва да са от типа composed, защото Hermes прави втора трансформация след Metro. Конфигурацията е:

// android/app/build.gradle
project.ext.react = [
    enableHermes: true,
    hermesFlagsRelease: ["-O", "-output-source-map"],
    bundleAssetName: "index.android.bundle",
]

Ако имате обърквания около кое source map да качите, правилото е просто: винаги композираното, което е по-голямо. Ще го намерите като index.android.bundle.map след release build. Самият аз бях изхвърлил грешния map два пъти в първите си release-и с Sentry, докато не научих това.

Чести проблеми при дебъгване

Ето няколко проблема, които срещам редовно при ревюта на проекти през 2026:

DevTools не се свързва с устройството

Най-честата причина е, че Metro работи на друг порт или хост. Проверете localhost:8081 в браузъра. Трябва да видите Metro welcome страница. Ако не я виждате, рестартирайте Metro с npx react-native start --reset-cache.

Breakpoints не работят

Това обикновено е проблем със source maps. Проверете дали inlineRequires е изключен в development и че няма production-only minification в Metro config.

Network табът е празен

Ако използвате axios с custom adapter или библиотека като react-native-blob-util, заявките не минават през XHR и не се виждат в Network таба. Превключете към стандартен fetch за дебъгване или ползвайте proxy на ниво ОС.

Console.log не се появява

Hermes има bug-фикс от 2025 за това, но ако сте на по-стара версия (RN под 0.74), включете --inspect флаг ръчно. Препоръчвам надграждане поне до 0.76 за стабилни DevTools.

Често задавани въпроси

Все още ли се поддържа Flipper в React Native?

Не. Flipper беше официално премахнат от стандартния React Native template през октомври 2024 и не се поддържа с New Architecture (Fabric + TurboModules). Препоръчителната замяна са вградените React Native DevTools от RN 0.76 нататък.

Как да отворя React Native DevTools от Expo проект?

Стартирайте npx expo start и натиснете j в терминала. Експо CLI автоматично отваря DevTools в Chrome или Edge, ако ги имате инсталирани. Алтернативно, разклатете устройството и изберете "Open DevTools" от Dev Menu.

Мога ли да използвам Chrome DevTools с React Native?

Да, всъщност React Native DevTools са базирани на Chrome DevTools Protocol. Те предоставят леко модифицирана версия на Chrome DevTools интерфейса, оптимизирана за React Native. Не можете да използвате remote debugging в Chrome browser-а както преди, защото този подход е премахнат с Hermes.

Защо моите Network заявки не се появяват в DevTools?

Най-вероятно използвате нативна мрежова библиотека, която заобикаля стандартния fetch/XHR (например react-native-blob-util или native URLSession). Network инспекторът прихваща само заявки през стандартните JavaScript fetch и XMLHttpRequest. За пълно прихващане ползвайте Charles Proxy или mitmproxy.

Как да дебъгвам продакшън грешки в React Native?

DevTools работят само в development. За продакшън инсталирайте crash reporter като Sentry или Bugsnag, качете source maps след всеки release build, и използвайте Hermes composed source maps (а не само Metro-те). Това ви дава четими stack traces в reporter-а.

Jake Morrison
За Автора Jake Morrison

React Native lead engineer who's shipped six apps and learned six different lessons. Bullish on the New Architecture.