react-native-popup-menu gives you a menu you can style, control and extend

A provider at the root, a menu wherever you want one

The usage model is two components and one wrapper. Your application is wrapped in a `MenuProvider` at the entry point, and then wherever you want a menu you render a `Menu` containing a `MenuTrigger` and a `MenuOptions` block of `MenuOption` children:

import {
  Menu,
  MenuOptions,
  MenuOption,
  MenuTrigger,
} from 'react-native-popup-menu';

export const YourComponent = () => (
  <View>
    <Text>Hello world!</Text>
    <Menu>
      <MenuTrigger text='Select action' />
      <MenuOptions>
        <MenuOption onSelect={() => alert(`Save`)} text='Save' />
        <MenuOption onSelect={() => alert(`Not called`)} disabled={true} text='Disabled' />
      </MenuOptions>
    </Menu>
  </View>
);

The trigger carries a text label and each option carries an `onSelect` handler, a text label and an optional `disabled` flag, and an option whose children are your own nodes rather than a text string, so you can put a coloured `Text` inside it. The provider is what makes the menu work, and it has to sit above every menu in the tree, which is the usual shape for a context-based component and the main structural constraint the library imposes on your app.

Four ways to present the menu

The mode list is the feature that decides whether the library fits your app. There are multiple modes: animated, not animated, slide in from bottom or popover, and by default opening and closing animations are on. The slide-in mode is the mobile-native gesture, where the options come up from the bottom of the screen, and the popover mode anchors the options to the trigger, which is the desktop pattern. The two demos in the repository show a context menu with slide-in and a popover side by side, which is the right way to think about the choice. The component also handles the Android back button optionally, so a menu that is open can be dismissed with the system back gesture instead of leaving the user tapping outside.

Controlled or uncontrolled, and the lifecycle hooks that go with it

The component can work as a controlled or an uncontrolled component, which is a distinction that matters more in React Native than it does on the web because a menu's open state often has to be synchronised with the rest of your navigation or selection state. An uncontrolled menu opens and closes itself; a controlled one is told what to do. The feature list also mentions different lifecycle hooks, which in practice is what lets a parent know that the menu opened, that it closed, or that an option was chosen, without having to render the options itself. The API documentation in the `doc/` directory covers the details, alongside a separate document on extension points and one with examples.

Extension points are how you change how it looks

The customisation claim is specific: menu options, positioning and animations are all customizable on various levels, and styling is easy. That is what the extension points document is for, and it is the difference between a component you can drop in and one you can adapt. Because the positioning behaviour is a documented extension point rather than a fixed rule, a menu that needs to appear above a keyboard, or inside a modal, or anchored to a different element, is a matter of overriding a position calculation rather than forking the library. The list of things you can change also includes the visual style, and the RTL layout support means a menu in a right-to-left language is not a special case you have to build yourself.

The scope line is explicit: platforms outside it are community work

The README draws a boundary that is worth reading carefully. The component is for Android, iOS and, unofficially, UWP and react-native-web. Then there is a section titled community driven features, listing support for UWP, react-native-web and react-native-desktop, along with TypeScript definitions, followed by an explicit statement that the maintainers thank the community for maintaining features that go over their scope. So the platform coverage you read about is not all first-party work. That is not a criticism, it is how the project stays maintainable, but it does mean that if your target is react-native-web or a desktop build, you are depending on community patches and you should check the issue tracker for that platform before committing.

Version compatibility is the thing to check first

Two tables describe the compatibility, in both directions. The first says what minimum React Native or React version is needed to use a given popup menu version: 0.13 needs 0.55 with React 16.3.1, 0.9 needs 0.40, 0.8 needs 0.38 and 0.7 needs 0.18. The second is the other way round, which React Native or React version needs which popup menu version: React Native 0.81 and above needs 0.19 because of the SafeAreaView deprecation, with the linked issue referenced, and React Native 0.78 with React 19.0 needs 0.18. The project says it keeps compatibility on a best effort basis. The release titles line up with that table, with v0.19.0 removing the deprecated SafeAreaView, v0.18.0 adding compatibility with React 19, and v0.17.0 covering React Native 0.77.

A small library with a plain build

The package manifest shows a straightforward setup. The package is `react-native-popup-menu` at version 0.19.0, the main entry point is `build/rnpm.js`, and the typings are in `src/index.d.ts`, so the TypeScript definitions live with the source rather than being generated. The build is a single Rollup invocation over a Babel config, and the test script is Jest with a test regex for files ending in `-test.js`, coverage collection enabled and a setup file for the jasmine environment. There is an `__mocks__` directory, a `__tests__` directory and an `examples/` directory with its own app, its own package manifest, an `eas.json` for build configuration and a TypeScript configuration, so the example is a real project rather than a snippet. The `src/` directory and the `build/` directory at the top level show that the build output is committed, which is a common choice for packages consumed through npm without a bundler step. The licence is ISC.

Editorial conclusion

Adopt react-native-popup-menu when you need a context menu in a React Native app and want to control how it is positioned and animated rather than accepting the platform default, since the component exposes those as extension points rather than fixed behaviour. Do not adopt it if you need a native Android menu, since this is a JavaScript implementation drawn by React Native, not a platform widget. Verify first which React Native version you are on against the compatibility table, because the 0.19 line exists specifically to handle the SafeAreaView deprecation on React Native 0.81 and above, and check that the peer dependencies of the version you install still match your project's React version.

Frequently asked questions

Official sources

1. instea/react-native-popup-menu on GitHub
2. Issues
3. License: ISC
4. README
5. Releases