Debugging & Performance Optimization

Seeing what your app is doing

When something is slow or buggy, you need to see what is happening, not guess. React Native ships with a debugger: shake the phone (or press a shortcut in the simulator) to open the dev menu, then open the React DevTools and the JS debugger. There you can read console.log output, inspect the component tree, and use the Profiler to see which components re-render and how long they take. (Older projects used a separate tool called Flipper; the built-in DevTools have largely replaced it.)

The single most common performance problem is wasted re-renders: a component redrawing when nothing it shows actually changed. A re-render is React running a component again to update the screen — usually good, but if it happens needlessly on a heavy component or a long list, the app stutters.

Cutting wasted re-renders

Three tools, used together, stop most wasted work. Here is what each one is for:

The idea, in plain terms: memo wraps a child so it only re-renders when its props really change. But a function prop is recreated on every parent render, which would defeat memo — so you wrap that function in useCallback to keep it stable. Here is the pattern:

import { memo, useCallback, useState } from 'react';
import { Text, Button, View } from 'react-native';

// Child only re-renders if its props change, thanks to memo
const Row = memo(function Row({ label, onPress }) {
  console.log('rendering', label);
  return <Button title={label} onPress={onPress} />;
});

export default function App() {
  const [count, setCount] = useState(0);

  // Stable function — not recreated each render, so memo keeps working
  const handlePress = useCallback(() => console.log('pressed'), []);

  return (
    <View>
      <Text>{count}</Text>
      <Button title="Re-render parent" onPress={() => setCount(count + 1)} />
      <Row label="I should not re-render" onPress={handlePress} />
    </View>
  );
}

Tuning a FlatList

Long lists are the other big performance area. FlatList is already efficient, but a few props help with thousands of rows or heavy item content:

• Give every item a stable keyExtractor so rows are reused, not rebuilt.
• If all rows are the same height, add getItemLayout so the list can jump without measuring each row.
• Wrap the row component in React.memo so unchanged rows do not re-render while scrolling.
• Tune initialNumToRender (how many rows to draw first) and windowSize (how much off-screen to keep ready) for a smoother first paint.

A word on the New Architecture

You may see "New Architecture", "Fabric" and "TurboModules" in job posts. In plain terms: React Native rebuilt how JavaScript talks to the native side to make it faster and smoother. Fabric is the new rendering system; TurboModules is the faster way native modules load. As an app developer you mostly do not change your code for it — modern Expo enables it for you. You just need to know what it is and that newer Expo versions use it by default.

A debugging workflow, step by step

When an app feels slow, work through it in this order rather than guessing:

1. Open the dev menu (shake the device or the simulator shortcut) and launch the React DevTools Profiler.
2. Record while you do the slow action, then look at which components re-rendered and how long they took.
3. If a heavy component re-renders when its data did not change, wrap it in React.memo and stabilise any function props with useCallback.
4. If a calculation is expensive and runs every render, wrap it in useMemo so it only recomputes when its inputs change.
5. If a long list janks while scrolling, apply the FlatList tips above (keyExtractor, memo rows, getItemLayout).
6. Re-profile to confirm the wasted renders are gone — measure, do not assume.