A bottom sheet with zero dependencies and four peer requirements

Zero dependencies and four peers, which is not a contradiction

The manifest's description says zero dependency code, and the peer dependency block immediately below lists four packages, each with a wildcard version: React Native itself, a gesture handler, a reanimated library, and a safe area context library. Those are peer dependencies rather than dependencies, which is the correct classification and explains the wording. A peer dependency is something the consuming application supplies, and the ecosystem's convention is that a component declares what it needs from its host rather than bundling it. So the library installs nothing of its own and requires four things to be present. Three of those four are unremarkable: every React Native project ends up with a gesture handler and a safe area context, and the animation library is the most common choice for interactive transitions. What zero dependencies buys you is exactly the thing you would want from a UI primitive: no version conflicts, no transitive tree, and no question about whether two libraries disagree about a reanimated version. What it costs is that the component inherits the configuration quality of its host. If the gesture handler is set up without a root view, or the animation library's babel plugin is missing, this component will misbehave in ways that look like its own bugs. The wildcard versions in the peer list mean it will not warn you about a mismatch, so the check is on you.

Version ten means there is a migration guide, and that is the real documentation

The readme has one section about versions and it is the most useful one. Everything it points you at is on one hosted site, and that site is also where the installation instructions live:

https://rnas.vercel.app/installation

It says the new version introduces breaking changes and points at a migration guide, and the section heading names the versions being migrated from, which are the pre-one releases. So the library is at major version ten, has been through at least one hard break, and the readme is telling you that jumping from an old major is not a version bump. What that means in practice is that anyone starting today reads the current API and anyone with an existing integration has to read the guide first, and those are two different documents. The readme also has a section on installation that contains no commands at all. It says to check the installation section of the documentation site for detailed instructions, and the documentation section says the same thing with a link. The features, the API reference and everything else live on a hosted site. That is a common pattern for a component library with a demo site, and it is a real trade: a rendered documentation page with live examples is better to read than a markdown file, and it is worse to search, worse to diff, and unavailable if the site goes down. For a library at version ten with an established user base, the API surface is large enough that a single readme cannot hold it, so the structure makes sense. It does mean the repository itself tells you almost nothing, and the feature list you have to evaluate from is the manifest description.

The description is the feature list, and it is a positioning statement

Since the readme is short, the manifest's description and keyword list are where the actual positioning lives. The description says cross platform for Android and iOS with a a flexible API, native performance, and that you can create anything you want inside the sheet. The keywords are more revealing than the prose, because they are the terms a developer would search. There are the obvious ones: sheet, action sheet, bottom sheet, bottom drawer, drawer, modal, dialog, picker. Then there are the ones that describe the technical approach rather than the use case: bottom animated, native, raw bottom sheet, bottom app bar, and the full package name. The raw and native keywords suggest the component is a thin animation primitive rather than a fixed list-of-buttons widget, and the create anything inside it phrasing says the same thing. That is the design decision: instead of exporting a component that renders your options, it exports a container and you put your own view inside. A sheet that takes children is reusable for a share menu, a filter panel, a form, a colour picker, or a confirmation, and a sheet that takes a list of items is a picker and nothing else. If you want the second thing you have a hundred lines to write; if you want the first thing there is no alternative worth the maintenance. The app-bar and web keywords also suggest it is meant to sit in a bottom navigation context rather than only as a modal.

One maintainer, an ask for stars, and a sponsor in the readme

Two paragraphs of the readme are about maintenance rather than code, and they are worth reading because they tell you what to expect. One is a request to star the project if you use it, with the stated reason that maintaining it and addressing issues takes a great deal of time and effort. The other is a sponsor block, a company logo linking to their site, placed above the licence line. So the economics are: one maintainer, a component library with a large API surface, a documentation site, two example applications, and a sponsor. That is a sustainable arrangement for a solo maintainer and it is also a single point of failure, and the release history supports both readings. Three tagged releases appear in the recent list, at three different patch versions of the same major, spaced about a month apart across late 2025 and early 2026, and then nothing for three months before the last push. So maintenance is active but episodic, which is the normal rhythm of a one-person open source project and the reason the documentation site matters more than it would for a team. If you are adopting this in a product, factor in that the migration guide and the API reference live on a site maintained by the same person as the code.

Two example applications, one of them runnable in a browser

The repository carries two example projects and the distinction matters. One is a full application directory with the things a real native project has: an Android and an iOS native folder, a Ruby dependency file for the native build, a bundler configuration, a Metro configuration, a Babel configuration, a Jest configuration and its own tests directory and lock file. That is a bare React Native project with the component wired in, and it is the example that tells you how the component behaves on a device. The other is a smaller directory with a single source file and a name suggesting it is configured for the managed workflow, and the readme links a hosted playground instance of it. That link is the cheapest way to evaluate the component, and it costs nothing but a browser tab. What the readme does not tell you is whether the two examples demonstrate the same API, whether the managed version needs the native modules built into a client, or whether the web target is demonstrated at all. Given that the description claims three platforms and the peer dependencies are all native-oriented, the web claim is the one you should test yourself rather than accept. The example applications are also the only place in the repository where you can see how the component is meant to be composed, since there is no usage snippet in the readme.

Editorial conclusion

Adopt react-native-actions-sheet if your React Native project already has the gesture and animation stack installed, since the component is a zero-dependency layer on top of exactly that stack and adding it should not add a package you did not already have. Do not adopt it if you are starting a project from nothing, because the readme is thin and sends you to a hosted documentation site for installation, and the peer requirements mean a working setup depends on four other libraries being configured correctly. Four things to verify. That you have all four peer dependencies, since a component that needs a gesture handler and a reanimated plugin will silently misbehave rather than fail loudly if either is missing. Which version line you are on, because there is a migration guide from the pre-one releases with breaking changes and the current line is at ten, so a project on the old major is looking at a different library. Whether the web target works for you, since the description says cross platform including web and the peer list is the native stack, which is a combination worth testing rather than assuming. And what the documentation site is, because the readme itself is under two hundred words of instructions and the real API reference is elsewhere. The licence is MIT, version 10.1.2 was released on 2026-01-21, and the last push was on 2026-04-23.

Frequently asked questions

Official sources

1. ammarahm-ed/react-native-actions-sheet on GitHub
2. License: MIT
3. Project website
4. README
5. Releases