Storybook for React Native, components without the app

The component, without the application around it

The package description is the whole pitch. Storybook for React Native is an open source tool for developing UI components in isolation, and the README says the same thing in a sentence. You can design and develop individual React Native components without running your app, which sounds obvious and turns out to be the reason a lot of teams do not iterate on UI as quickly as they would like. The interface is still the device, which is the point, since a React Native component that is not running on a real device is not the thing you are going to ship. The project is part of the Storybook family and the homepage is storybook.js.org, with a separate documentation site for this package at storybookjs.github.io/react-native/docs/intro/. The README also carries a version note, that it documents v10, with the v9 documentation linked separately, and that a new docs site is being built.

One command to set up, then wrap the bundler

For a new project there are two templates, one for Expo and one for the React Native CLI.

# With NPM
npx create-expo-app --template expo-template-storybook AwesomeStorybook

npx @react-native-community/cli init MyApp --template react-native-template-storybook

For an existing project the command is npm create storybook@latest, which sets up the project with the dependencies and the configuration files. The second step is to wrap your bundler configuration with the withStorybook function, and the wrapper does the work of detecting whether you are on Metro or Re.Pack, handling entry point swapping, story generation and optional WebSocket setup.

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

const config = getDefaultConfig(__dirname);

module.exports = withStorybook(config);

No changes to App.tsx are needed, and the switch is an environment variable. With STORYBOOK_ENABLED=true and expo start, the wrapper swaps your entry point for Storybook's, and when the variable is not set the app runs normally with zero Storybook code in the bundle. For projects that prefer to wire it up themselves, there is a manual setup guide.

Stories are Component Story Format files

The story format is CSF, and the example is the usual one, a default export carrying the component and the metadata, and a named export per story.

import type { Meta, StoryObj } from '@storybook/react-native';
import { MyButton } from './Button';

const meta = {
  component: MyButton,
} satisfies Meta<typeof MyButton>;

export default meta;

type Story = StoryObj<typeof meta>;

export const Basic: Story = {
  args: {
    text: 'Hello World',
    color: 'purple',
  },
};

The location of the story files is set in the main.ts config file in the .rnstorybook folder, where the stories glob and the device addons are declared.

// .rnstorybook/main.ts
import type { StorybookConfig } from '@storybook/react-native';

const main: StorybookConfig = {
  stories: ['../components/**/*.stories.?(ts|tsx|js|jsx)'],
  deviceAddons: ['@storybook/addon-ondevice-controls', '@storybook/addon-ondevice-actions'],
};

Decorators and parameters can be attached to the default export or to an individual story, and the global versions go into preview.tsx in the same .rnstorybook folder. The parameters example shows a backgrounds list of named values, and the preview example shows a global decorator with a background set, which is how a device build gets a consistent look across every story.

Addons that render on the device itself

The addon model is the part that differs from web Storybook, and the difference is in the name. These are on-device addons, and the README explains that they can render with the device user interface that you see on the phone, rather than in a browser side panel. The list in the README covers @storybook/addon-ondevice-controls, which lets you adjust your component props in real time, @storybook/addon-ondevice-actions, which mocks onPress calls with actions that log information in the actions tab, @storybook/addon-ondevice-notes, which adds Markdown to your stories to document their usage, and @storybook/addon-ondevice-backgrounds, which changes the background behind the component. The CLI installs some basic addons for you, such as controls and actions. The reasoning is straightforward. On a phone there is no side panel to draw in, so the inspector has to live on the device, and that constraint is why the addon set looks different from the web one.

Metro, Re.Pack and Expo Router each need a different path

Three setups are documented separately, and the differences are practical rather than cosmetic. For projects using Re.Pack, which is the Rspack and Webpack route, there is a full Re.Pack Setup guide and a RepackStorybookStarter project to look at. For Expo Router projects you have two choices, entry point swapping, which the README recommends, or creating a dedicated Storybook route, with a separate Expo Router Setup guide for the details. Reanimated users need the package in the project and the plugin in the Babel configuration.

// babel.config.js
plugins: ['react-native-reanimated/plugin'],

The repository also carries the documents that make those guides short. MANUAL_SETUP.md is the manual path for people who do not want the wrapper, PORTABLE_STORIES.md covers the portable stories story, MIGRATION.md has the guide for moving from version 9 to version 10, and ROADMAP.md and RELEASES.md record what is planned and what shipped. The v9 to v10 migration is the one to read before an upgrade, since the v9 documentation is still linked for people who have not moved yet.

A pnpm monorepo with examples as first class citizens

The repository is a pnpm workspace and the examples are part of it, which is a good sign for a project that has to support several bundler setups. The examples/ directory holds expo-example, expo-new-wrapper-example, expo-router-example and repack-example, and the root scripts can launch them, with an example script and an example:lite script that filter to the expo-example package, and an example-new-wrapper script for the new wrapper example. The root package.json is a private @storybook/root package with the workspace scripts, and the check script chains type checking, linting, format checking, the expo-example check and the tests. There are also the publishing scripts, a canary publish through changesets, and a repo:lint script that runs sherif to find unsynchronised similar dependencies, which is the kind of check a monorepo with many packages needs. Alongside that are the .changeset/ directory for release notes, a .claude-plugin/ directory and a .mcp.json, an AGENTS.md, a CLAUDE.md and a MAINTAINERS.md, plus .claude/, .zed/ and .vscode/ directories, an e2e/ directory, tests/, skills/ and docs/.

Version alignment, the next line, and the licence

The releases come fast and the branches are in flux. The tags are v10.6.2 on 2026-10-11, v10.7.0 on 2026-10-13 and v11.0.0-next.0 the same day, and the default branch is next, which tells you the v11 line is where the work is happening. The repository is not archived and the last push was on 2026-10-15. The note that matters most for an adopter is the dependency alignment warning, which says to make sure your Storybook dependencies are aligned to the same major version or you will see broken behaviour. That is the kind of instruction that saves a morning, because a mixed v10 and v11 install is exactly the kind of mistake a team makes when a pre-release is published alongside a stable line. The licence is MIT, in the LICENSE file, which is the permissive grant the Storybook family uses for its open source packages, and the project is run under the Storybook organisation with the main site at storybook.js.org and the React Native documentation on its own site.

Editorial conclusion

Storybook for React Native fits a team building a React Native application with a large component library, or anyone who wants to iterate on a single component without launching the whole app and navigating to it. It does not fit a project with a handful of screens and no component library, since the setup cost is only worth paying once there is something to catalogue. Verify three things before adopting it: that every Storybook dependency in your project is on the same major version, since the README warns that a mismatch produces broken behaviour, that your bundler is one of the supported paths, either Metro or Re.Pack, since the wrapper auto-detects between them, and that the version you install matches the documentation you read, since the v10 and v11 lines are documented separately and this repository's README covers v10 while the default branch is next.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. storybookjs/react-native on GitHub