Debugging React Native Apps in 2026: DevTools, Performance Panel, Radon IDE, and Sentry

Why Debugging in React Native Has Fundamentally Changed

If you've been building React Native apps for any length of time, you remember the pain. Flipper would crash at the worst possible moments. Remote JS debugging broke your timers. The element inspector was unreliable at best. And trying to debug a native crash from JavaScript? That felt like shouting into a void.

Thankfully, that era is over.

The debugging ecosystem in 2026 has matured in ways I honestly didn't expect. React Native DevTools — the official debugger since 0.76 — has grown into a genuinely powerful tool. The new Performance Panel in 0.83 brings browser-grade performance profiling to mobile. Radon IDE embeds the entire debugging experience inside your editor (and it's surprisingly good). Plus, tools like Sentry have made production debugging something you can actually rely on rather than just hope for.

This guide covers the full debugging landscape: from humble console.log and LogBox fundamentals to advanced performance profiling, memory leak detection, native crash diagnosis, and production error monitoring. Whether you're tracking down a rendering bug, investigating a memory leak, or trying to figure out why your app feels sluggish on budget Android devices, you'll find practical, tool-specific guidance here.

React Native DevTools: Your Primary Debugging Hub

React Native DevTools replaced Flipper as the default debugger starting with React Native 0.76. It's built on the Chrome DevTools Protocol and designed specifically for React Native apps running on the Hermes engine. Unlike the old remote debugging approach, DevTools connects directly to the Hermes runtime — which means your app behaves exactly the same whether the debugger is attached or not. No more timing bugs caused by debugging. That alone is a massive improvement.

Getting Started

DevTools requires zero configuration. If you're running React Native 0.76 or later (or a recent Expo SDK), it's already available. To open it:

• Press j in the Metro terminal where your dev server is running
• Or open the Dev Menu on your device (shake gesture or Cmd+D on iOS Simulator / Ctrl+M on Android emulator) and select "Open DevTools"

This launches a Chrome-based debugging interface with several panels: Components, Profiler, Console, Sources, Network, Memory, and — new in 0.83 — Performance.

The Components Panel

The Components panel lets you inspect the rendered React component tree in real time. Honestly, this is often the fastest way to understand what's going on in your UI.

Here's what you can do with it:

• Element selection: Click the "Select element" button (top-left corner), then tap any element in your running app. DevTools jumps directly to that component in the tree
• Props and state inspection: Select any component to view and modify its props and state in the right panel. Changes apply immediately — incredibly useful for testing edge cases without rewriting code
• Re-render highlighting: Open View Settings (gear icon) and enable "Highlight updates when components render." This shows a colored border around components as they re-render, instantly revealing unnecessary renders
• Component search: Use the search bar to filter by component name, which is a lifesaver in large component trees

// Example: A component where re-render highlighting would help
// If this re-renders when only `count` changes, the expensive list
// below will also re-render unnecessarily
function Dashboard({ count, items }) {
  return (
    <View>
      <Text>Count: {count}</Text>
      <ExpensiveList items={items} />
    </View>
  );
}

// Fix: Memoize the expensive child
const MemoizedExpensiveList = React.memo(ExpensiveList);

Console and Sources Panels

The Console panel captures all console.log, console.warn, and console.error output from your JavaScript code. Unlike the Metro terminal, the Console in DevTools also supports advanced methods like console.table and console.dir, which render structured data as browsable objects and tables. It's one of those things you don't realize you're missing until you try it.

The Sources panel gives you a full JavaScript debugger with breakpoints, call stack inspection, watch expressions, and step-through execution. You can set conditional breakpoints (right-click the line gutter), add logpoints that output values without pausing execution, and use the scope pane to inspect local and closure variables at any breakpoint.

// Using console.table for structured debugging
const userSessions = [
  { user: 'Alice', screen: 'Home', duration: 45 },
  { user: 'Bob', screen: 'Profile', duration: 12 },
  { user: 'Carol', screen: 'Settings', duration: 30 },
];
console.table(userSessions);

// Using console.group for organized logging
console.group('API Request: /users');
console.log('Method: GET');
console.log('Headers:', { Authorization: 'Bearer ***' });
console.log('Response status: 200');
console.groupEnd();

Network Panel

The Network panel records all HTTP requests made by your app through fetch(), XMLHttpRequest, and Image loads. For each request, you can inspect:

• Request and response headers
• Request body and response preview (JSON, text, or image)
• Timing information (DNS, connection, waiting, transfer)
• Response size

If you're using Expo, you'll see an "Expo Network" panel with additional request source logging. Worth noting: the Network panel is currently an Expo-enhanced feature, so bare React Native projects may have more limited network inspection. For those projects, intercepting the global fetch or using a library like reactotron for network inspection works well as an alternative.

// Quick network debugging with a fetch interceptor
if (__DEV__) {
  const originalFetch = global.fetch;
  global.fetch = async (...args) => {
    const [url, options] = args;
    console.log(`[FETCH] ${options?.method || 'GET'} ${url}`);
    const start = performance.now();
    try {
      const response = await originalFetch(...args);
      const duration = (performance.now() - start).toFixed(0);
      console.log(`[FETCH] ${response.status} ${url} (${duration}ms)`);
      return response;
    } catch (error) {
      console.error(`[FETCH] FAILED ${url}`, error);
      throw error;
    }
  };
}

The Performance Panel: Deep Profiling in React Native 0.83

React Native 0.83 introduced the Performance Panel, and it's a big deal. This is the tool you reach for when your app feels sluggish and you need to understand exactly where time is being spent. Think of it as bringing Chrome's performance profiling capabilities to mobile development.

What It Shows

The Performance Panel renders a unified timeline that combines multiple tracks:

• JavaScript execution: Function calls, their duration, and call stacks on the JS thread
• React performance tracks: React's internal scheduling — renders, commits, effects, and transitions
• Network events: HTTP requests plotted on the same timeline so you can see how data fetching relates to rendering
• Custom User Timings: Your own performance marks, measured using the standard Web Performance API

Recording a Performance Session

Open DevTools, navigate to the Performance tab, and click the Record button. Interact with your app — navigate between screens, scroll lists, trigger animations, submit forms. When done, click Stop. The panel renders a detailed flame chart of everything that happened during the recording.

The key thing to look for: long tasks on the JS thread. Anything over 16ms on the JavaScript thread can cause frame drops. The flame chart makes it easy to drill into exactly which function calls are eating up time.

React Scheduler Tracking

Since React 19 and the concurrent rendering model, understanding React's internal scheduling has become pretty critical. The Performance Panel breaks the React Scheduler into distinct tracks:

• Blocking: High-priority updates that block the UI until they complete
• Transition: Lower-priority updates that React can interrupt and resume
• Suspense: Components suspended while waiting for data
• Layout Effects: Synchronous effects that run after DOM mutations

This visibility is invaluable. You might discover that a transition update is being treated as blocking, or that a Suspense boundary is triggering a waterfall of sequential data fetches. Without this panel, those kinds of issues are really hard to spot.

Custom User Timings with the Web Performance API

React Native now supports the Web Performance API, so you can add your own performance marks and measures that show up directly in the Performance Panel:

// Mark the start and end of a custom operation
performance.mark('data-fetch-start');

const data = await fetchUserProfile(userId);

performance.mark('data-fetch-end');
performance.measure('User Profile Fetch', 'data-fetch-start', 'data-fetch-end');

// These marks and measures appear in the Performance Panel timeline
// alongside React's own performance tracks

Even more powerful: PerformanceObserver works in production builds, meaning you can collect real-world performance metrics from your live apps:

// Collect performance metrics in production
const observer = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    // Send to your analytics service
    analytics.track('performance_measure', {
      name: entry.name,
      duration: entry.duration,
      startTime: entry.startTime,
    });
  }
});

observer.observe({ type: 'measure', buffered: true });

The React Profiler: Component-Level Render Analysis

While the Performance Panel gives you a system-wide view, the React Profiler (a separate tab in DevTools) focuses specifically on React rendering behavior. It answers the questions you're really asking: how often are my components rendering, and how long does each render take?

Recording and Interpreting Profiles

Navigate to the Profiler tab, click Record, interact with your app, then click Stop. The profiler shows each "commit" — a group of component renders that React batched together. For each commit, you see:

• A flame chart showing the component render tree and time spent in each component
• A ranked chart sorting components by render duration (most expensive first)
• Component-level render counts across the entire profiling session

The ranked chart is particularly useful — I'd say it's where I spend most of my profiler time. It immediately tells you which components are costing the most. If you see a component rendering frequently with a high per-render cost, that's your optimization target.

Common Patterns the Profiler Reveals

// Pattern 1: Inline objects causing unnecessary re-renders
// BAD — creates a new style object every render
function Card({ title }) {
  return (
    <View style={{ padding: 16, backgroundColor: '#fff' }}>
      <Text>{title}</Text>
    </View>
  );
}

// GOOD — stable reference
const styles = StyleSheet.create({
  card: { padding: 16, backgroundColor: '#fff' },
});

function Card({ title }) {
  return (
    <View style={styles.card}>
      <Text>{title}</Text>
    </View>
  );
}

// Pattern 2: Missing memoization on expensive computations
// BAD — recalculates on every render
function OrderSummary({ items }) {
  const total = items.reduce((sum, item) => sum + item.price * item.qty, 0);
  const sortedItems = [...items].sort((a, b) => b.price - a.price);
  // ...
}

// GOOD — only recalculates when items actually change
function OrderSummary({ items }) {
  const total = useMemo(
    () => items.reduce((sum, item) => sum + item.price * item.qty, 0),
    [items]
  );
  const sortedItems = useMemo(
    () => [...items].sort((a, b) => b.price - a.price),
    [items]
  );
  // ...
}

Radon IDE: The Integrated Debugging Experience

Radon IDE, built by Software Mansion (the team behind Reanimated and Gesture Handler), takes a completely different approach to debugging. Instead of a separate browser window, it embeds the entire debugging experience inside VSCode or Cursor. And honestly, once you get used to it, going back to window-switching feels painful.

What Makes Radon Different

Radon runs the iOS Simulator and Android Emulator directly in an editor panel. No separate windows, no context switching. The debugger, element inspector, network inspector, and console are all part of your editor workflow.

Key features for debugging:

• Inline breakpoints and debugger: Set breakpoints directly in your editor. When a breakpoint hits, variable values appear inline next to the code — not in a separate panel
• Network inspector: View all network requests directly in a panel within your editor, with the ability to inspect headers, payloads, and timing
• Re-render highlighting: Radon highlights components that re-render too frequently, making performance issues visually obvious
• Jump to code from logs: Click on a log line, and Radon navigates you to the exact source location. It's a small feature that saves an enormous amount of time
• Router integration: For Expo Router projects, Radon shows your current route and lets you navigate by URL directly from the IDE
• Component preview: Preview individual components in isolation without navigating through your entire app
• Dev tools integration: Built-in support for third-party dev tools like React Query DevTools and Redux DevTools

When to Use Radon vs. React Native DevTools

Radon excels when you want a tightly integrated experience and you're primarily working in VSCode or Cursor. It's particularly strong for rapid iteration — the combination of inline debugging, instant component preview, and embedded simulators means you rarely need to leave your editor.

React Native DevTools is the better choice when you need the full power of the Chrome-style Performance Panel, advanced memory profiling with heap snapshots, or when your team uses different editors. It's also the only option for the new 0.83 Performance Panel features.

Many developers (myself included) use both: Radon for day-to-day development and React Native DevTools when it's time for deep performance analysis.

Memory Leak Detection and Debugging

Memory leaks in React Native are sneaky. Your app works fine for ten minutes, then gradually slows down as the garbage collector struggles with an ever-growing heap. On budget Android devices with limited RAM, this can lead to out-of-memory crashes that are incredibly frustrating to reproduce.

Using the Memory Panel

The Memory tab in React Native DevTools lets you take heap snapshots and allocation timeline reports. Here's the workflow for finding leaks:

1. Navigate to the screen you suspect is leaking
2. Take a heap snapshot (Snapshot 1)
3. Navigate away from the screen and back again several times
4. Take another heap snapshot (Snapshot 2)
5. Use the "Comparison" view to see which objects grew between snapshots

If navigating away and back causes object counts to grow steadily, you've got a leak. The comparison view shows you which constructor names are accumulating, helping you trace back to the responsible component.

Common Leak Sources and Fixes

// Leak Source 1: Missing useEffect cleanup
// BAD — the interval keeps running after unmount
function PollingComponent() {
  const [data, setData] = useState(null);

  useEffect(() => {
    const interval = setInterval(async () => {
      const result = await fetchData();
      setData(result); // setState on unmounted component = leak
    }, 5000);
    // Missing cleanup!
  }, []);

  return <Text>{data?.value}</Text>;
}

// GOOD — properly cleans up
function PollingComponent() {
  const [data, setData] = useState(null);

  useEffect(() => {
    let isActive = true;
    const interval = setInterval(async () => {
      const result = await fetchData();
      if (isActive) setData(result);
    }, 5000);

    return () => {
      isActive = false;
      clearInterval(interval);
    };
  }, []);

  return <Text>{data?.value}</Text>;
}

// Leak Source 2: Event listeners not cleaned up
// BAD
useEffect(() => {
  const subscription = AppState.addEventListener('change', handleAppState);
  // subscription is never removed
}, []);

// GOOD
useEffect(() => {
  const subscription = AppState.addEventListener('change', handleAppState);
  return () => subscription.remove();
}, []);

// Leak Source 3: Closures holding references to large data
// BAD — the closure captures `largeDataSet` indefinitely
function DataProcessor({ largeDataSet }) {
  const processedRef = useRef(null);

  useEffect(() => {
    processedRef.current = () => {
      return largeDataSet.map(transform);
    };
  }, [largeDataSet]);
}

Production Memory Profiling with Hermes

For investigating memory issues in production or release builds, the react-native-release-profiler library from Margelo lets you capture Hermes CPU profiles in release mode. This is critical for diagnosing performance issues that only show up on real devices with real data volumes:

import { startProfiling, stopProfiling } from 'react-native-release-profiler';

// Start profiling when user reports slowness
startProfiling();

// ... user interacts with the app ...

// Stop and get the profile
const profilePath = await stopProfiling();
// Upload profilePath to your backend for analysis
// The .cpuprofile file can be opened in Chrome DevTools

Debugging Native Crashes

Not all crashes happen in JavaScript. Native crashes — segmentation faults, null pointer exceptions in Java, EXC_BAD_ACCESS on iOS — require a different set of tools entirely. These are often the most frustrating bugs to deal with, but knowing the right approach makes them manageable.

iOS: Xcode and Console

When your app crashes with a native error on iOS, Xcode is your primary tool:

1. Open your project's .xcworkspace in Xcode
2. Select your device or simulator as the run target
3. Run the app from Xcode (Product → Run) instead of npx react-native run-ios
4. When the crash occurs, Xcode breaks at the crash point and shows the native stack trace
5. Use the Debug navigator (Cmd+7) to examine the thread state and memory

For crashes that happen outside of Xcode, you can retrieve crash logs from the device via the Console app (Applications → Utilities → Console), or from Xcode's Devices and Simulators window (Window → Devices and Simulators → View Device Logs).

Android: Logcat and Android Studio

For Android native crashes, Logcat is your best friend:

# View all logs from your app (filter by package name)
adb logcat --pid=$(adb shell pidof -s com.yourapp.package)

# Filter for crash-related logs
adb logcat *:E | grep -i "fatal\|crash\|exception"

# View the last crash tombstone
adb shell cat /data/tombstones/tombstone_00

In Android Studio, you can attach the debugger to a running React Native process: go to Run → Attach to Process, then select your app. This gives you native breakpoints, memory inspection, and the full Logcat viewer with filtering by log level and tag.

Symbolication

Native crash stack traces are often unsymbolicated — meaning they show memory addresses instead of function names and line numbers. For release builds, you need the debug symbols (dSYM files on iOS, mapping files on Android) to make crash reports readable. If you're using EAS Build, Expo automatically handles symbol uploads for Sentry and Crashlytics integration, which is one less thing to worry about.

LogBox: Taming Warnings and Errors

LogBox is React Native's in-app error and warning overlay. Red screens indicate errors; yellow screens indicate warnings. While it's tempting to just dismiss warnings, they often flag real issues — deprecated API usage, missing keys in lists, unsafe lifecycle methods.

Don't ignore them. Well, not all of them anyway.

Strategic Warning Suppression

Some warnings come from third-party libraries and genuinely can't be fixed in your code. Suppress those selectively — but never blanket-ignore all warnings:

import { LogBox } from 'react-native';

// Suppress specific known warnings from third-party libraries
LogBox.ignoreLogs([
  'ViewPropTypes will be removed', // Known RN deprecation warning
  'Require cycle:',                // Dependency cycle warnings you've reviewed
]);

// NEVER do this in development — only for demos or screenshots
// LogBox.ignoreAllLogs();

// For more structured suppression, create a dedicated file
// src/utils/suppressWarnings.js
const SUPPRESSED_WARNINGS = [
  // Third-party: react-native-maps v1.x deprecation
  'ViewPropTypes will be removed from React Native',
  // Reviewed and accepted: harmless cycle in navigation setup
  'Require cycle: node_modules/react-navigation',
];

LogBox.ignoreLogs(SUPPRESSED_WARNINGS);

Custom Error Boundaries

For production, you need error boundaries that catch JavaScript errors in the component tree and give users meaningful recovery options instead of a blank screen:

import React from 'react';
import { View, Text, TouchableOpacity, StyleSheet } from 'react-native';

class ErrorBoundary extends React.Component {
  state = { hasError: false, error: null };

  static getDerivedStateFromError(error) {
    return { hasError: true, error };
  }

  componentDidCatch(error, errorInfo) {
    // Report to your error monitoring service
    Sentry.captureException(error, {
      extra: { componentStack: errorInfo.componentStack },
    });
  }

  handleReset = () => {
    this.setState({ hasError: false, error: null });
  };

  render() {
    if (this.state.hasError) {
      return (
        <View style={styles.container}>
          <Text style={styles.title}>Something went wrong</Text>
          <Text style={styles.message}>
            {this.state.error?.message}
          </Text>
          <TouchableOpacity
            style={styles.button}
            onPress={this.handleReset}
          >
            <Text style={styles.buttonText}>Try Again</Text>
          </TouchableOpacity>
        </View>
      );
    }
    return this.props.children;
  }
}

const styles = StyleSheet.create({
  container: { flex: 1, justifyContent: 'center', alignItems: 'center', padding: 20 },
  title: { fontSize: 20, fontWeight: 'bold', marginBottom: 10 },
  message: { fontSize: 14, color: '#666', textAlign: 'center', marginBottom: 20 },
  button: { backgroundColor: '#007AFF', paddingHorizontal: 20, paddingVertical: 10, borderRadius: 8 },
  buttonText: { color: '#fff', fontSize: 16, fontWeight: '600' },
});

Production Error Monitoring with Sentry

Development debugging tools are great, but they can't help with crashes happening on your users' devices. For production, you need an error monitoring service. Sentry is the most widely used option in the React Native ecosystem, with first-class support for both JavaScript and native crashes.

Setting Up Sentry

# Install the Sentry React Native SDK
npx expo install @sentry/react-native

# For bare React Native projects
npm install @sentry/react-native
npx @sentry/wizard -i reactNative

Initialize Sentry early in your app's entry point:

// App.tsx or app/_layout.tsx (Expo Router)
import * as Sentry from '@sentry/react-native';

Sentry.init({
  dsn: 'https://[email protected]/project-id',
  tracesSampleRate: 0.2,  // 20% of transactions for performance monitoring
  profilesSampleRate: 0.1, // 10% of transactions for profiling

  // Only enable debug in development
  debug: __DEV__,

  // Filter out noise
  beforeSend(event) {
    // Don't send events from development
    if (__DEV__) return null;
    return event;
  },
});

// Wrap your root component for automatic performance tracking
export default Sentry.wrap(App);

Adding Context for Better Debugging

Raw stack traces are rarely enough on their own. Add context that helps you actually reproduce issues:

// Set user context when they log in
Sentry.setUser({
  id: user.id,
  email: user.email,
  subscription: user.plan,
});

// Add breadcrumbs for navigation events
export function useNavigationTracking() {
  const navigationRef = useNavigationContainerRef();

  useEffect(() => {
    const unsubscribe = navigationRef.addListener('state', () => {
      const currentRoute = navigationRef.getCurrentRoute();
      Sentry.addBreadcrumb({
        category: 'navigation',
        message: `Navigated to ${currentRoute?.name}`,
        data: { params: currentRoute?.params },
        level: 'info',
      });
    });
    return unsubscribe;
  }, [navigationRef]);
}

// Capture handled errors with extra context
try {
  await submitOrder(orderData);
} catch (error) {
  Sentry.captureException(error, {
    extra: {
      orderData: { ...orderData, creditCard: '[REDACTED]' },
      cartItems: cart.items.length,
      retryCount: attempts,
    },
    tags: {
      flow: 'checkout',
      paymentProvider: orderData.paymentMethod,
    },
  });
  // Show user-facing error
  showToast('Order failed. Please try again.');
}

Source Maps and Symbolication

For Sentry to show readable stack traces from production minified bundles, you need to upload source maps. With Expo and EAS Build, this is mostly automatic:

// app.json or app.config.js
{
  "expo": {
    "plugins": [
      [
        "@sentry/react-native/expo",
        {
          "organization": "your-org",
          "project": "your-project"
        }
      ]
    ]
  }
}

For bare React Native, add the Sentry build phase scripts to your Xcode and Gradle build configs. The @sentry/wizard CLI handles this setup for you.

Debugging Strategies That Actually Work

Tools are only as good as your approach to using them. So, let's walk through some practical debugging strategies organized by the type of problem you're facing.

Strategy 1: Isolating Rendering Issues

1. Enable re-render highlighting in React Native DevTools
2. Interact with the problematic screen and watch for unexpected highlights
3. Use the Profiler's ranked chart to find the most expensive renders
4. Check for inline objects in props, missing React.memo, or unstable references from hooks
5. Verify with the Performance Panel that frame drops correlate with the JS thread, not the UI thread

Strategy 2: Tracking Down State Bugs

1. In the Components panel, navigate to the component with the bug
2. Watch its state and props in the right panel as you interact with the app
3. Set a conditional breakpoint in the Sources panel on the state update: break when value === unexpectedValue
4. Examine the call stack when the breakpoint hits to trace where the bad value came from
5. If using Zustand or Redux, enable their DevTools integration to see every state transition

Strategy 3: Diagnosing Slow Screen Transitions

1. Record a Performance Panel session that includes the slow transition
2. Look at the flame chart during the transition: is the JS thread blocked by a long synchronous operation?
3. Check the React Scheduler tracks: are there blocking updates that should be transitions?
4. Look at the Network track: is a blocking API call delaying the render?
5. If the JS thread is clear but the transition still feels slow, the issue is likely on the native side (animation configuration, view hierarchy complexity)

Strategy 4: Hunting Memory Leaks

1. Open the Memory panel and take a baseline heap snapshot on the home screen
2. Navigate to the suspected screen and back, repeating 5-10 times
3. Take another snapshot and compare — look for steadily growing object counts
4. Focus on objects with your app's constructor names, not framework internals
5. Check every useEffect in the suspected component for missing cleanup functions
6. Verify that event listeners, timers, and subscriptions are properly removed

Building a Debugging-Friendly Codebase

The best debugging experience comes from code that's structured to be debuggable in the first place. Here are a few practices that pay dividends down the road.

Structured Logging

// Create a logger that adds context and can be filtered
const LOG_LEVELS = { debug: 0, info: 1, warn: 2, error: 3 };
const CURRENT_LEVEL = __DEV__ ? LOG_LEVELS.debug : LOG_LEVELS.warn;

export const logger = {
  debug: (tag, message, data) => {
    if (CURRENT_LEVEL <= LOG_LEVELS.debug) {
      console.log(`[${tag}]`, message, data ?? '');
    }
  },
  info: (tag, message, data) => {
    if (CURRENT_LEVEL <= LOG_LEVELS.info) {
      console.log(`[${tag}]`, message, data ?? '');
    }
  },
  warn: (tag, message, data) => {
    if (CURRENT_LEVEL <= LOG_LEVELS.warn) {
      console.warn(`[${tag}]`, message, data ?? '');
    }
  },
  error: (tag, message, error) => {
    console.error(`[${tag}]`, message, error);
    if (!__DEV__) {
      Sentry.captureException(error, { tags: { component: tag } });
    }
  },
};

// Usage
logger.debug('OrderScreen', 'Submitting order', { itemCount: 3 });
logger.error('PaymentService', 'Payment failed', paymentError);

Performance Marks at Key Boundaries

// Add performance marks at screen load boundaries
function ProductDetailScreen({ route }) {
  const { productId } = route.params;

  useEffect(() => {
    performance.mark(`product-detail-mount-${productId}`);

    return () => {
      performance.mark(`product-detail-unmount-${productId}`);
      performance.measure(
        `product-detail-session-${productId}`,
        `product-detail-mount-${productId}`,
        `product-detail-unmount-${productId}`
      );
    };
  }, [productId]);

  // ...
}

Dev-Only Debugging Utilities

// A hook that logs render reasons in development
function useWhyDidYouRender(componentName, props) {
  const prevProps = useRef(props);

  useEffect(() => {
    if (__DEV__) {
      const changes = {};
      for (const key of Object.keys(props)) {
        if (prevProps.current[key] !== props[key]) {
          changes[key] = {
            from: prevProps.current[key],
            to: props[key],
          };
        }
      }
      if (Object.keys(changes).length > 0) {
        console.log(`[WhyRender] ${componentName}`, changes);
      }
      prevProps.current = props;
    }
  });
}

// Usage
function ExpensiveComponent(props) {
  useWhyDidYouRender('ExpensiveComponent', props);
  // ...
}

Putting It All Together: A Debugging Toolkit Checklist

Here's a quick summary of the tools covered and when to reach for each one:

• Console.log + Metro terminal: Quick sanity checks, simple value inspection
• React Native DevTools (Components): Inspecting component tree, live prop/state editing, re-render visualization
• React Native DevTools (Sources): Breakpoints, step-through debugging, conditional breakpoints, watch expressions
• React Native DevTools (Network): HTTP request/response inspection with timing (enhanced in Expo)
• React Native DevTools (Memory): Heap snapshots, allocation timelines, memory leak detection
• React Native DevTools (Performance): Full performance profiling with flame charts, React Scheduler tracking, and custom marks (0.83+)
• React Profiler: Component-level render analysis, render counts, render duration ranking
• Radon IDE: Integrated editor-based debugging, network inspection, re-render highlighting, component preview
• Xcode / Android Studio: Native crash debugging, breakpoints in Objective-C/Swift/Java/Kotlin code
• Logcat / Console.app: Native log inspection and crash log retrieval
• Sentry: Production error monitoring, crash reporting, performance monitoring, session replay
• react-native-release-profiler: Production CPU profiling with Hermes

The React Native debugging story in 2026 is honestly unrecognizable from where it was even two years ago. With React Native DevTools as a stable foundation, the Performance Panel providing deep profiling capabilities, Radon IDE integrating everything into your editor, and mature production monitoring through Sentry, you've got the tools to debug effectively at every stage of development. The key is knowing which tool to reach for — and building your codebase with debuggability in mind from the start.