AutoGineer
Generated banner for React Native Best Practices
Generated logo for React Native Best Practices

React Native Best Practices

CallstackOfficialPublished by Callstack

  • Skill
  • Guidelines
  • Software development
  • MIT
  • No issues found
Get it from the source

From the author

Provides React Native performance optimization guidelines for FPS, TTI, bundle size, memory leaks, re-renders, and animations. Applies to tasks involving Hermes optimization, JS thread blocking, bridge overhead, FlashList, native modules, or debugging jank and frame drops.
— the description by Callstack

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

This skill provides a structured approach to optimizing React Native applications. It focuses on critical performance metrics including FPS, Time to Interactive (TTI), bundle size, and memory management. The guide emphasizes a data-driven workflow: Measure, Optimize, Re-measure, and Validate, ensuring that performance improvements are based on actual profiling data rather than assumptions. It covers both JavaScript-level optimizations and native-level configurations, providing actionable strategies for common bottlenecks like list rendering, re-renders, and heavy native modules.

What it does

  • Provides a standardized performance measurement and optimization workflow
  • Offers specific guidance for improving FPS and reducing UI re-renders
  • Details techniques for analyzing and reducing JavaScript bundle sizes
  • Outlines strategies for optimizing TTI and native module performance
  • Includes best practices for memory leak detection and management
  • Provides a mapping of common performance problems to specific diagnostic and fix strategies

When to use it

  • When debugging janky UI, frame drops, or slow animations
  • When investigating memory leaks in JS or native code
  • When optimizing app startup time and TTI
  • When attempting to reduce the final application bundle size
  • When profiling and tuning native modules or Turbo Modules
  • During code reviews to ensure performance-conscious implementation

Advantages

  • Promotes a rigorous, evidence-based approach to performance tuning
  • Covers the full stack from React components to native bridge and bundle configuration
  • Provides clear, priority-ordered guidelines for triage
  • Includes specific diagnostic commands for profiling and bundle analysis
  • Helps avoid common pitfalls like premature optimization or incorrect dependency usage

Usage examples

“My React Native app is dropping frames during list scrolling. How should I investigate?”
The agent will guide you to use the FPS and re-render profiling workflow, suggesting the use of react-devtools to identify slow components and recommending the replacement of ScrollView with optimized alternatives like FlashList.
“How can I reduce the size of my React Native iOS bundle?”
The agent will provide steps to analyze the bundle using source-map-explorer, identify heavy dependencies, and apply optimizations such as avoiding barrel imports and enabling native code shrinking.

Install

  1. 1 of its files are not mirrored here, so install it from its source:

    https://github.com/callstackincubator/agent-skills/tree/59e9d17446a248b21d86f078fcd0bd2d36db1ca4/skills/react-native-best-practices

Documentation by Callstack

React Native Best Practices

Overview

Performance optimization guide for React Native applications, covering JavaScript/React, Native (iOS/Android), and bundling optimizations. Based on Callstack's "Ultimate Guide to React Native Optimization".

When to Apply

Reference these guidelines when:

  • Debugging slow/janky UI or animations

  • Investigating memory leaks (JS or native)

  • Optimizing app startup time (TTI)

  • Reducing bundle or app size

  • Writing native modules (Turbo Modules)

  • Profiling React Native performance

  • Reviewing React Native code for performance

Security Notes

  • Treat shell commands in these references as local developer operations. Review them before running, prefer version-pinned tooling, and avoid piping remote scripts directly to a shell.

  • Treat third-party libraries and plugins as dependencies that still require normal supply-chain controls: pin versions, verify provenance, and update through your standard review process.

  • Treat remote chunk loading as first-party artifact delivery only. Prefer app-bundled chunks or signed CI release manifests; hosted chunks must come from trusted HTTPS origins you control and be pinned to the current app release.

Priority-Ordered Guidelines

PriorityCategoryImpactPrefix
1FPS & Re-rendersCRITICALjs-*
2Bundle SizeCRITICALbundle-*
3TTI OptimizationHIGHnative-*, bundle-*
4Native PerformanceHIGHnative-*
5Memory ManagementMEDIUM-HIGHjs-*, native-*
6AnimationsMEDIUMjs-*

Impact labels are triage hints: CRITICAL first, HIGH next, MEDIUM when evidence points there.

Quick Reference

Optimization Workflow

Follow this cycle for any performance issue: Measure → Optimize → Re-measure → Validate

  1. Measure: Capture baseline metrics before changes. For runtime issues, prefer commit timeline, re-render counts, slow components, heaviest-commit breakdown, and startup/TTI when available. Component tree depth or count are optional context, not substitutes. Do not recommend memoization, atomic state, or compiler changes without a measured render or FPS problem.

  2. Optimize: Apply the targeted fix from the relevant reference

  3. Re-measure: Run the same measurement to get updated metrics

  4. Validate: Confirm improvement (e.g., FPS 45→60, TTI 3.2s→1.8s, bundle 2.1MB→1.6MB)

If metrics did not improve, revert and try the next suggested fix.

Review Guardrails

  • Check library versions before suggesting API-specific fixes. Example: FlashList v2 deprecates estimatedItemSize, so do not flag it as missing there.

  • Do not suggest useMemo or useCallback dependency changes unless behavior is demonstrably incorrect or profiling shows wasted work tied to that value.

  • Do not report stale closures speculatively. Show the stale read path, a repro, or profiler evidence before calling it out.

  • When profiling a flow, measure the target interaction itself. Do not treat component tree depth or component count as the main performance evidence.

Critical: FPS & Re-renders

Profile first:

agent-device react-devtools status
agent-device react-devtools wait --connected
agent-device react-devtools profile start
agent-device react-devtools profile stop
agent-device react-devtools profile slow --limit 5
agent-device react-devtools profile rerenders --limit 5
agent-device react-devtools profile timeline --limit 20

Drive the target interaction with normal agent-device commands between profile start and profile stop.

Manual fallback when agent-device is unavailable: open React Native DevTools from Metro (j) or the Dev Menu, use the Profiler tab, and record the same interaction.

For release-build React component profiling, connect @callstack/inspector first so React DevTools can attach to the release app, then run the agent-device react-devtools flow above.

Common fixes:

  • Replace ScrollView with FlatList/FlashList/Legend List for long lists

  • After profiling shows cascading re-renders, use React Compiler for automatic memoization

  • After profiling shows broad store/context updates, use atomic state (Jotai/Zustand) to reduce re-renders

  • Use useDeferredValue for expensive computations

Critical: Bundle Size

Analyze bundle:

npx react-native bundle \
  --entry-file index.js \
  --bundle-output output.js \
  --platform ios \
  --sourcemap-output output.js.map \
  --dev false --minify true

npx source-map-explorer output.js --no-border-checks

Verify improvement after optimization:

# Record baseline size before changes
ls -lh output.js  # e.g., Before: 2.1 MB

# After applying fixes, re-bundle and compare
npx react-native bundle --entry-file index.js --bundle-output output.js \
  --platform ios --dev false --minify true
ls -lh output.js  # e.g., After: 1.6 MB  (24% reduction)

Common fixes:

  • Avoid barrel imports (import directly from source)

  • Remove unnecessary Intl polyfills only after checking Hermes API and method coverage

  • Evaluate tree shaking (Expo SDK 52+ experimental unused import/export removal, or Re.Pack only if already configured)

  • Enable R8 for Android native code shrinking

High: TTI Optimization

Measure TTI:

  • Use react-native-performance for markers

  • Only measure cold starts (exclude warm/hot/prewarm)

Common fixes:

  • For React Native 0.78 and earlier, disable Android JS bundle compression to enable Hermes mmap

  • Use native navigation (react-native-screens)

  • Preload commonly-used expensive screens before navigating to them

High: Native Performance

Profile native:

  • iOS: Xcode Instruments → Time Profiler

  • Android: Android Studio → CPU Profiler

Common fixes:

  • Use background threads for heavy native work

  • Prefer async over sync Turbo Module methods

  • Use C++ for cross-platform performance-critical code

References

Full documentation with code examples in references/:

JavaScript/React (js-*)
FileImpactDescription
js-lists-flatlist-flashlist.mdCRITICALReplace ScrollView with virtualized lists
js-profile-react.mdMEDIUMagent-device react-devtools profiling
js-measure-fps.mdHIGHFPS monitoring and measurement
js-memory-leaks.mdMEDIUMJS memory leak hunting
js-atomic-state.mdHIGHJotai/Zustand patterns
js-concurrent-react.mdHIGHuseDeferredValue, useTransition
js-react-compiler.mdHIGHAutomatic memoization
js-animations-reanimated.mdMEDIUMReanimated worklets
js-bottomsheet.mdHIGHBottom sheet optimization
js-uncontrolled-components.mdHIGHTextInput optimization
Native (native-*)
FileImpactDescription
native-turbo-modules.mdHIGHBuilding fast native modules
native-sdks-over-polyfills.mdHIGHNative vs JS libraries
native-measure-tti.mdHIGHTTI measurement setup
native-threading-model.mdHIGHTurbo Module threads
native-profiling.mdMEDIUMXcode/Android Studio profiling
native-platform-setup.mdMEDIUMiOS/Android tooling guide
native-view-flattening.mdMEDIUMView hierarchy debugging
native-memory-patterns.mdMEDIUMC++/Swift/Kotlin memory
native-memory-leaks.mdMEDIUMNative memory leak hunting
native-android-16kb-alignment.mdCRITICALThird-party library alignment for Google Play
Bundling (bundle-*)
FileImpactDescription
bundle-barrel-exports.mdCRITICALAvoid barrel imports
bundle-analyze-js.mdCRITICALJS bundle visualization
bundle-tree-shaking.mdHIGHDead code elimination
bundle-analyze-app.mdHIGHApp size analysis
bundle-r8-android.mdHIGHAndroid code shrinking
bundle-hermes-mmap.mdHIGHDisable bundle compression
bundle-native-assets.mdHIGHAsset catalog setup
bundle-library-size.mdMEDIUMEvaluate dependencies
bundle-code-splitting.mdMEDIUMRemote chunk loading safeguards

Problem → Skill Mapping

ProblemStart With
App feels slow/jankyjs-measure-fps.md → js-profile-react.md
Too many re-rendersjs-profile-react.md → js-react-compiler.md
Slow startup (TTI)native-measure-tti.md → bundle-analyze-js.md
Large app sizebundle-analyze-app.md → bundle-r8-android.md
Memory growingjs-memory-leaks.md or native-memory-leaks.md
Animation drops framesjs-animations-reanimated.md
Bottom sheet jank/re-rendersjs-bottomsheet.md → js-animations-reanimated.md
List scroll jankjs-lists-flatlist-flashlist.md
TextInput lagjs-uncontrolled-components.md
Native module slownative-turbo-modules.md → native-threading-model.md
Native library alignment issuenative-android-16kb-alignment.md

Attribution

Based on "The Ultimate Guide to React Native Optimization" by Callstack.

Files

references/bundle-code-splitting.md

title: Remote Chunk Loading impact: MEDIUM tags: code-splitting, lazy-loading, chunks, release-artifacts, remote-code

Skill: Remote Chunk Loading

Harden remote JavaScript chunk loading when a React Native app already uses Re.Pack or has an explicit remote-code-loading requirement.

Quick Pattern

Before (static import):

import SettingsScreen from './screens/SettingsScreen';

After (lazy loaded chunk):

const SettingsScreen = React.lazy(() =>
  import(/* webpackChunkName: "settings" */ './screens/SettingsScreen')
);

<Suspense fallback={<Loading />}>
  <SettingsScreen />
</Suspense>

When to Use

Consider code splitting when:

  • Not using Hermes (JSC/V8 benefits more)

  • App size approaches app-store or base-module limits

  • The app already has a micro-frontend architecture

  • Loading features based on user permissions

  • Other bundle-size optimizations are exhausted

  • Remote delivery is an explicit product or release requirement

Do not recommend adopting Re.Pack for ordinary bundle-size work. Keep the default path on Metro/Expo unless remote chunk loading is already present or specifically required.

Note: Hermes already uses memory mapping for efficient bundle reading. Benefits of code splitting are minimal with Hermes or even counterproductive in some cases.

Security Model

Chunks are executable application code. Prefer chunks packaged with the app or resolved from a release manifest produced by your CI. Hosted chunks are acceptable only when they are first-party release artifacts, not arbitrary runtime URLs.

Keep these guardrails in place:

  • Serve chunks only from a first-party, HTTPS-only origin you control

  • Resolve scriptId through a fixed allowlist or signed release manifest

  • If using Re.Pack, enable code signing for remotely hosted chunks and use strict signature verification in production

  • Fail closed if a chunk is missing or unexpected

  • Do not load chunks from user-controlled input, query params, or third-party domains

Prerequisites

  • Project already uses Re.Pack, or remote chunk loading is an explicit requirement approved after measuring simpler alternatives

  • Remote chunks are produced by the same release pipeline as the app

  • Chunk locations come from a fixed allowlist or signed release manifest

If the project does not already use Re.Pack, do not start here. First confirm Metro/Expo bundle analysis, import cleanup, asset cleanup, native app-size work, and store delivery constraints.

Step-by-Step Instructions

1. Create Split Point with React.lazy
// BEFORE: Static import
import SettingsScreen from './screens/SettingsScreen';

// AFTER: Dynamic import (creates split point)
const SettingsScreen = React.lazy(() =>
  import(/* webpackChunkName: "settings" */ './screens/SettingsScreen')
);
2. Wrap with Suspense
import React, { Suspense } from 'react';

const App = () => {
  return (
    <Suspense fallback={<LoadingSpinner />}>
      <SettingsScreen />
    </Suspense>
  );
};
3. Configure Chunk Loading
// index.js (before AppRegistry)
import { ScriptManager, Script } from '@callstack/repack/client';

const RELEASE_CHUNKS = Object.freeze({
  settings: {
    release: '42',
  },
});

ScriptManager.shared.addResolver(async (scriptId) => {
  if (__DEV__) {
    return {
      url: Script.getDevServerURL(scriptId),
      cache: false,
    };
  }

  const chunk = RELEASE_CHUNKS[scriptId];

  if (!chunk) {
    throw new Error(`Unknown chunk: ${scriptId}`);
  }

  return {
    url: Script.getRemoteURL(
      getFirstPartyChunkBaseURL(scriptId, chunk.release)
    ),
    verifyScriptSignature: 'strict',
  };
});

function getFirstPartyChunkBaseURL(scriptId, release) {
  // App-owned helper: read a signed CI manifest and return the first-party
  // base URL without ".chunk.bundle"; Script.getRemoteURL appends it.
  // Do not accept hostnames, paths, or script IDs from runtime input.
  return ReleaseManifest.getChunkBaseURL({ scriptId, release });
}

AppRegistry.registerComponent(appName, () => App);

For app-bundled chunks in a Re.Pack project, configure extraChunks with type: 'local' and resolve those script IDs from the filesystem:

if (LOCAL_CHUNKS.has(scriptId)) {
  return {
    url: Script.getFileSystemURL(scriptId),
    absolute: true,
  };
}
4. Build and Deploy Chunks

Build generates:

  • index.bundle - Main bundle

  • settings.chunk.bundle - Lazy-loaded chunk

Remote chunks are written to build/output/<platform>/remotes by default. Deploy chunks as first-party release artifacts. Prefer app-bundled assets; if hosted, publish them through CI to an app-owned HTTPS origin and keep the allowlist or signed manifest in sync with the app release.

Complete Example

// App.tsx
import React, { Suspense, useState } from 'react';
import { Button, View, ActivityIndicator } from 'react-native';

// Lazy load heavy feature
const HeavyFeature = React.lazy(() =>
  import(/* webpackChunkName: "heavy-feature" */ './HeavyFeature')
);

const App = () => {
  const [showFeature, setShowFeature] = useState(false);
  
  return (
    <View>
      <Button 
        title="Load Feature" 
        onPress={() => setShowFeature(true)} 
      />
      
      {showFeature && (
        <Suspense fallback={<ActivityIndicator />}>
          <HeavyFeature />
        </Suspense>
      )}
    </View>
  );
};

Module Federation

Only use Module Federation when the app already has a micro-frontend architecture and the organizational boundary is worth the runtime trust boundary:

// Host app loads remote module
const RemoteModule = React.lazy(() =>
  import('remote-app/Module')
);

Federation increases the trust boundary. Keep the same first-party origin, release-manifest, code-signing, and allowlist rules as above.

Caching Strategy

import AsyncStorage from '@react-native-async-storage/async-storage';

ScriptManager.shared.setStorage(AsyncStorage);

Set storage before adding resolvers so Re.Pack can cache resolved script locator data. Return cache: false for dev server chunks or any script that should bypass caching.

When NOT to Use

ScenarioWhy Not
Using Hermesmmap already efficient
Small appOverhead not worth it
Simple navigationNative navigation better
Quick iteration neededAdded complexity

Hermes Memory Mapping

Hermes reads bytecode lazily via mmap:

  • Only loads executed code into memory

  • No parse step needed

  • Code splitting provides marginal benefit

Verification

// Check if chunk loaded correctly
ScriptManager.shared.on('loading', (script) => {
  console.log(`Loading: ${script.scriptId}`);
});

ScriptManager.shared.on('loaded', (script) => {
  console.log(`Loaded: ${script.scriptId}`);
});

ScriptManager.shared.on('error', (error) => {
  console.error('Script loading failed:', error);
});

Common Pitfalls

  • Forgetting Suspense: Lazy components need fallback

  • Wrong CDN path: Chunks 404 in production

  • No caching: Re-downloads on every load

  • Too many chunks: Network overhead exceeds savings

  • Untrusted chunk source: JS chunks from third-party or user-controlled origins are equivalent to remote code execution

Related Skills

Requirements and compatibility

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Needs: Needs Node.js

Security

No issues found by our static scan· No issues found

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Published by
Callstack
Publisher
Callstack (Official)
Source
callstackincubator/agent-skills · skills/react-native-best-practices · commit 59e9d17
Licence
MIT License (redistribution allowed)
  • LICENSE (added by AutoGineer from LICENSE)
  • ATTRIBUTION.md (written by AutoGineer)
Synced

AutoGineer is not affiliated with or endorsed by Callstack.

Get it from the source

1 of this skill’s files are not mirrored here, so there is no ZIP. Get the complete skill from its source: callstackincubator/agent-skills