React Native DevTools 2026: Debugovanie po konci Flippera
React Native DevTools nahradili Flipper od verzie 0.76. Ukážem, ako ich otvoriť, používať Performance panel z RN 0.83, profilovať Hermes engine a doplniť stack o Reactotron a Sentry.
React Native DevTools sú od verzie 0.76 predvolený debugger pre React Native aplikácie a v roku 2026 definitívne nahradili Flipper aj starý remote JS debugger. Bežia priamo nad Chrome DevTools Protocol a pripájajú sa na Hermes runtime, takže aplikácia sa správa rovnako s debuggerom aj bez neho. V tomto sprievodcovi ukážem, ako otvoriť DevTools, používať Performance panel z RN 0.83, profilovať Hermes a doplniť stack o Reactotron a Sentry, a to všetko z pohľadu vývojára, ktorý prišiel z webu.
Flipper je od RN 0.74 deprecated a od 0.76 ho oficiálne nahradili React Native DevTools postavené nad Chrome DevTools Protocol.
DevTools otvoríte stlačením klávesu j v termináli s Metrom. Žiadna extra inštalácia, funguje out-of-the-box s Hermes.
Performance panel pridaný v RN 0.83 zobrazuje unifikovaný timeline JS vlákna, React Scheduleru, sieťových volaní a User Timings.
DevTools sa pripájajú priamo na Hermes runtime, takže časovače a Date.now() už neprestavia debugger (problém starého remote debuggera zmizol).
Pre stav a MMKV úložisko sa v roku 2026 stále odporúča Reactotron, pre produkčné chyby Sentry so source mapami.
Chrome chrome://inspect už oficiálne nefunguje. Používajte len zabalený DevTools frontend cez Metro.
Prečo Flipper skončil a čo priniesli DevTools
Ak ste v posledných troch rokoch písali React Native, viete, že Flipper bol dobrý nápad s problematickou realizáciou. Padal v najhorších možných chvíľach, vyžadoval samostatnú desktop aplikáciu, každý plugin sa inštaloval osobitne a s príchodom Novej architektúry (Fabric a TurboModules) prestával držať krok. Meta preto v roku 2024 oznámila jeho koniec ako predvoleného debuggera a od React Native 0.76 ho v šablóne úplne odstránili.
Nástupca, React Native DevTools, nie je nová Electron aplikácia, ale zabalený a mierne prispôsobený frontend Chrome DevTools, ktorý sa cez Chrome DevTools Protocol (CDP) pripája priamo na Hermes runtime bežiaci v aplikácii. Kľúčový rozdiel oproti starému „Debug JS Remotely" je ten, že váš JavaScript beží stále na zariadení, nie v Chrome tabe. To znamená, že Date, setTimeout, requestAnimationFrame a natívne moduly sa správajú identicky s debuggerom aj bez neho, čo bola v ére remote debuggera nekonečná trhlina medzi vývojom a produkciou.
Pre nás, ktorí sme prišli z webu, je to skvelá správa: rovnaké klávesové skratky, rovnaké názvoslovie panelov, rovnaká práca so source mapami. Rozdiel je len v tom, že Sources panel číta index.bundle generovaný Metrom, a nie webpack:// alebo vite:// URL. Ak sa chcete pozrieť na kontext, prečo bol prechod na DevTools možný, odporúčam prejsť aj mojím článkom o novej architektúre React Native. Bez Bridgeless módu a JSI by taká priama CDP integrácia jednoducho nebola realizovateľná.
Ako otvoriť React Native DevTools?
React Native DevTools sa spúšťajú z Metra a nevyžadujú žiadnu inštaláciu navyše. Sú súčasťou react-native od 0.76 a Expo SDK 52+. Postup je rovnaký v holom RN projekte aj v Expo:
Spustite dev server príkazom npx react-native start (alebo npx expo start).
V okne s Metrom stlačte j. Otvorí sa nové okno Chrome (alebo Edge) s DevTools pripojenými na váš Hermes runtime.
Alternatívne otvorte Dev Menu (Cmd+D v iOS simulátore, Ctrl+M alebo Cmd+M v Android emulátore, prípadne zatraste zariadením) a zvoľte Open DevTools.
Ak pracujete v tíme, ktorý ešte migruje z 0.74/0.75, jediný predpoklad je, že aplikácia beží na Hermes. Overte to takto:
// V ľubovoľnom komponente alebo App.tsx
if (typeof HermesInternal === 'object' && HermesInternal !== null) {
console.log('Bežíme na Hermes, DevTools sú k dispozícii');
}
Ak vám j nič neotvorí, najčastejšie príčiny sú tri: nemáte nainštalovaný Google Chrome ani Edge (DevTools potrebujú Chromium engine), používate Safari alebo Firefox ako default browser (nefunguje), alebo Metro beží v inom okne než v tom, kde stláčate klávesu. Zvyčajne to vyrieši npx react-native start --reset-cache a otvorenie Metra vo vlastnom termináli. Osobne som na tento tretí prípad narazil viackrát, keď mi VS Code spustil Metro v integrovanom termináli a ja som stláčal klávesy v inom okne.
Panely React Native DevTools: čo kde nájdete
Na prvý pohľad to vyzerá ako web DevTools. Väčšina panelov je funkčne identická, ale niektoré majú React Native špecifiká, ktoré stoja za vysvetlenie.
Console
Loguje console.log, warning-y z Reactu aj Yellow/Red boxy. Nová vec oproti webu: klikanie na React stack trace vás pošle do Sources panelu na presný riadok komponentu, aj keď je zdroj vo vnútri node_modules. Metro dnes generuje source mapy aj pre závislosti.
Sources
Tu si dávate breakpointy, krokujete cez F10/F11 a inšpektujete zásobník. Pridané v RN 0.83: podpora logpoints (breakpoint, ktorý namiesto zastavenia vypíše hodnotu do konzoly) a lepšie mapovanie TypeScript súborov cez metro-source-map.
Network
Do 0.83 boli requesty len logom, teraz máte plnohodnotný Network panel s headers, payload-om, response body a časovou osou. Fetch aj XMLHttpRequest sa zaznamenávajú automaticky, WebSocket rámce tiež.
Components a Profiler
Klasické React DevTools panely. Profiler v 2026 podporuje concurrent lanes, takže vidíte, čo prišlo z startTransition a čo blokuje UI vlákno. To sa hodí najmä pri zoznamoch. Pozrite si aj môj text o optimalizácii zoznamov s FlashList v2, kde profiler doslova ukazuje, ktoré položky sa zbytočne rerenderujú.
Memory a Performance
Memory panel dokáže snapshot heap-u Hermes engine a diff medzi dvomi snapshotmi. Najrýchlejšia cesta, ako nájsť únik pamäte spôsobený zabudnutým listener-om. Performance panel má samostatnú sekciu nižšie.
Performance Panel v React Native 0.83
Performance Panel je najväčšia zmena, ktorú DevTools priniesli v roku 2026. Predtým ste pri hľadaní pomalých renderov museli sledovať systrace na Androide alebo Time Profiler v Instruments. Teraz máte na jednom timeline JS vlákno, React Scheduler, Network events a vlastné performance.mark().
Workflow je jednoduchý:
Otvorte DevTools cez j v Metre.
Prepnite sa na tab Performance a stlačte kruhové record tlačidlo.
Vykonajte interakciu, ktorá vás trápi: scrollovanie, otvorenie modal, prechod v Expo Router v6 navigácii.
Stlačte stop. Zobrazí sa flame graph s viacerými tracks: Scheduler, Components, Network a User Timings.
Na čo sa v traces zameriavam ako prvé:
JS tasks nad 50 ms. Hermes ich zobrazí ako červené bloky. Kandidáti na useMemo, useCallback alebo presun na InteractionManager.runAfterInteractions.
Blocking lane v Scheduleri. Synchronické setState, ktoré zablokovali frame. Riešenie je zvyčajne obalenie do startTransition.
Nadväzujúce sieťové requesty. Ak vidíte tri fetch-e sériovo za sebou, sú to takmer istí kandidáti na Promise.all.
Vlastné merania sa dajú pridať cez štandardné User Timings API, ktoré funguje identicky ako na webe:
Značky sa objavia v Performance traces ako samostatný track. V mojom poslednom projekte som to používal na tímových review: vývojár nechal bežať scenár a v PR postol screenshot z DevTools, čo je oveľa presvedčivejší dôkaz ako „myslím, že je to rýchlejšie".
Profilovanie Hermes engine a flame graph
Performance Panel je skvelý pre interaktívne debugovanie, ale pre dlhé traces (napr. profilovanie startupu alebo animácie mimo hlavného vlákna) sa oplatí zapnúť Hermes CPU sampling profiler. Beží úplne mimo DevTools a zapisuje .cpuprofile súbor, ktorý sa dá otvoriť v Chrome DevTools Performance tabe.
Zapnutie profileru z JS strany:
// Volajte z Dev Menu action alebo z testu
import { NativeModules } from 'react-native';
const { HermesSamplingProfiler } = NativeModules;
export async function profileStartup(): Promise<string> {
HermesSamplingProfiler.start();
await runStartupScenario();
const filePath = await HermesSamplingProfiler.stop();
console.log('CPU profile uložený do', filePath);
return filePath;
}
Súbor stiahnete cez adb pull alebo Xcode Container Inspector a otvoríte v Chrome DevTools. Uvidíte tri pohľady na tie isté dáta: Chart (flame graph), Heavy (Bottom Up) a Tree (Top Down). Osobne začínam vždy pri Heavy, teda utriedenom zozname funkcií podľa celkového času, kde sa okamžite ukáže, či váš čas žerie JSON.parse, regex, alebo zbytočný re-render.
Detailný popis metodológie je v oficiálnej dokumentácii React Native pre profiling a stojí za prečítanie hlavne kapitola o rozdiele medzi sample-based profilingom (čo dostávate z Hermes) a instrumentation profilingom (čo dáva React Profiler).
Natívne nástroje: Xcode Instruments a Android Studio Profiler
DevTools vám ukážu všetko, čo sa deje v JS vlákne, ale UI thread, GPU vykresľovanie, natívne moduly a batériu musíte profilovať cez platformové nástroje. V roku 2026 sa jednoducho neoplatí hľadať tretiu stranu. Apple aj Google majú kvalitné profilery a JSI traces sa v nich už zobrazujú s čitateľnými menami.
iOS: Instruments
Otvorte projekt v Xcode, Product → Profile (Cmd+I), zvoľte šablónu Time Profiler pre CPU alebo Allocations pre pamäť. V Instruments filtrujte vlákna podľa mena: com.facebook.react.runtime.JavaScript je vaše JS vlákno cez Hermes, com.facebook.react.fabric.UIManager je nový Fabric renderer. Ak vidíte veľký blok v Fabric UIManager, problém je v natívnej vrstve, nie v JS.
Android: Android Studio Profiler
Otvorte android/ zložku ako Android Studio projekt, prepnite build na profileable (v gradle.properties nastavte reactNativeProfileableBuild=true) a spustite Profile with low overhead. Odporúčam začať s taskom Capture System Activities. Dáva Perfetto trace s UI, RenderThread aj JS vláknom, ktoré sa dá otvoriť aj v ui.perfetto.dev a zdieľať s tímom cez URL.
Pri diagnostike jankov na scroll je najspoľahlivejší postup: nahrať Systrace, hľadať Choreographer#doFrame nad 16 ms, a pozrieť, čo v tom čase robí JS vlákno. Ak je JS na tejto úrovni tichý a UI vlákno dlhé, problém je v natívnom rendereri, pravdepodobne v komponente, ktorý neimplementuje shouldComponentUpdate cez Fabric. Presne toto sme naposledy trasovali pri jankujúcom carousel-i a ušetrilo nám to hádam dva dni hľadania.
Reactotron, Sentry a zvyšok 2026 stacku
DevTools nepokryjú všetko. Pre stav aplikácie, MMKV úložisko a Redux akcie stále odporúčam Reactotron, samostatnú desktop aplikáciu, ktorá sa pripája k vášmu bundle-u cez WebSocket a zobrazuje Zustand/Jotai/Redux store v reálnom čase. Konfigurácia je päť riadkov v ReactotronConfig.ts a v produkcii sa importuje ako no-op cez tree-shaking.
Networking v Reactotron vypínam, pretože Network panel v DevTools je teraz plnohodnotný a duplicita len mätie. Zustand plugin je dôvod, prečo Reactotron ešte stále používam. Bližšie k tomu píšem v článku o správe stavu v React Native 2026.
Pre produkčné chyby je štandardom Sentry so zapnutými source mapami. Kľúčové je nahrávať source mapy pri každom EAS builde:
Bez source máp dostanete stack trace v index.android.bundle:1:342198 a nikto to neopraví. So source mapami vidíte súbor, funkciu a číslo riadku v pôvodnom TypeScript kóde. Presne toto ma raz nachytalo pri release builde, keď som zabudol nastaviť SENTRY_AUTH_TOKEN v EAS Secrets a týždeň mi chodili obfuskované stacky. Nastavenie a workflow je detailne popísané v Sentry dokumentácii pre Expo.
Nový hráč v roku 2026 je Radon IDE od Software Mansion, plugin pre VS Code, ktorý má vstavaný iOS simulátor, breakpointy priamo v editore a URL bar pre Expo Router deep links. Zdá sa mi ako správny smer pre vývojárov, ktorí nechcú prepínať medzi troma oknami, ale zatiaľ mu chýba stabilita na Windows a Fabric podpora na niektorých knižniciach. Odporúčam sledovať release notes Radon IDE a skúsiť ho neskôr v roku.
Často kladené otázky
Je Flipper v React Native 2026 ešte použiteľný?
Formálne áno, ale iba na React Native 0.73 a nižšie. Od 0.74 je deprecated a od 0.76 ho tím RN úplne odstránil zo šablóny nových projektov. Meta ani Callstack Flipper aktívne nevyvíjajú, takže s Novou architektúrou (Fabric a TurboModules) narazíte na desiatky nekompatibilných pluginov.
Ako otvorím React Native DevTools bez Metra?
Nedá sa. DevTools sa spúšťajú cez Metro dev server pomocou klávesy j alebo z Dev Menu na zariadení. Ak potrebujete profilovať release build, použite Hermes sampling profiler cez NativeModules.HermesSamplingProfiler.start(), uložte .cpuprofile súbor a otvorte ho v Chrome DevTools Performance tabe.
Prečo mi klávesa „j" v termináli neotvorí DevTools?
Skontrolujte, či máte nainštalovaný Google Chrome alebo Microsoft Edge. DevTools potrebujú Chromium-based browser. Ak máte len Safari alebo Firefox, DevTools sa nespustia. Druhou najčastejšou príčinou je bežiace Metro v inom termináli, než v ktorom stláčate klávesu. Reštart cez npx react-native start --reset-cache spravidla pomôže.
Ako debugujem React Native aplikáciu v produkcii?
DevTools bežia iba v dev buildoch. Pre produkciu použite Sentry, Bugsnag alebo Firebase Crashlytics so zapnutými source mapami. Pri EAS Build nahrajte source mapy cez sentry-expo/upload-sourcemaps hook, bez toho dostanete iba obfuskovaný stack trace, ktorý sa nedá spätne dohľadať.
Aký je rozdiel medzi React Native DevTools a React DevTools?
React DevTools je framework-agnostický browser extension pre React na webe. React Native DevTools je zabalený Chrome DevTools frontend, ktorý cez Chrome DevTools Protocol pripája Hermes runtime a obsahuje React DevTools panely (Components, Profiler) plus mobile-špecifické (Network, Performance, Memory). Skratka: React Native DevTools ⊃ React DevTools.
Sprievodca Expo Modules API v roku 2026: od create-expo-module scaffoldu cez Function/AsyncFunction DSL, Records a Convertibles až po natívne View, config plugin a upgrade playbook pre platform tímy.
Ukážem, ako znížiť React Native cold start zo 4,2 s na 1,6 s pomocou bridgeless módu, Hermes bytecode a inline requires. Reálne merania z 6 produkčných aplikácií, Perfetto trace a konfigurácia pre Expo aj bare projekty.
Praktický pohľad na novú architektúru React Native v roku 2026: Fabric renderer, TurboModules a JSI v praxi, vrátane migrácie z verzie 0.72 a reálnych benchmarkov.