react-native-share: The Native Share Sheet Bridge for React Native Apps

What react-native-share solves for React Native apps

A React Native app that wants to send a photo to WhatsApp, a link to Messages or a PDF to email has two options: build a share UI and talk to each target app's SDK, or hand the payload to the operating system and let it present the installed apps. react-native-share does the second. The package description reads "Social share, sending simple data to other apps," and that is the scope. It is a bridge, not a social network client.

The audience is React Native developers on iOS, Android and, per the repository's topics and top-level entries, Windows. The library exposes a JavaScript entry point (src/index.tsx for React Native, lib/commonjs/index.js for the main field) and native modules under android/, ios/ and windows/. If your product already has a share button and you want it to open the real system sheet, this is the piece you are missing. If you want analytics on which app the user picked, the sheet gives you a result object, but the choice itself belongs to the user and the OS.

How the native bridge and Share.open work

The flow is short. Your JavaScript calls Share.open(options). That call crosses the React Native bridge to a native module. On iOS the module presents a UIActivityViewController; on Android it builds an Intent.ACTION_SEND (the repository topic list includes both intent and bridge). The user sees the familiar share sheet, picks a target, and the promise resolves with a result or rejects with an error.

The README shows the shape of the call:

import Share from 'react-native-share';

Share.open(options)
  .then((res) => {
    console.log(res);
  })
  .catch((err) => {
    console.log(err);
  });

The options object is not spelled out in the README excerpt; the documentation site at react-native-share.github.io is where the project points for Share.open details and for other functions. That matters for a first integration: the README gives you the entry point and the Expo plugin configuration, but the full option surface lives in the docs. The repository also ships an example/ directory with App.js, android/, ios/ and videos/, which is the most reliable place to see a working setup.

One design consequence: because the sheet is native, the apps listed depend on what is installed and on what the platform allows you to query. That is why the Expo plugin asks for explicit ios and android query entries.

Installing react-native-share with npm, yarn or Expo

For a bare React Native project, the README gives two package manager commands. With yarn:

yarn add react-native-share

Or with npm:

npm i react-native-share --save

On iOS you then install the pods. The README says to run npx pod-install or cd ios && pod install, and that Android users can skip this step. After that the README states the library is usable on both platforms.

For Expo, the instruction is different because the native config has to be generated:

npx expo install react-native-share

Then the app config needs the plugin. The README shows app.config.ts or app.json entries with ios and android arrays of query schemes, plus enableBase64ShareAndroid:

{
  "plugins": [
    [
      "react-native-share",
      { "enableBase64ShareAndroid": true }
    ]
  ]
}

The README explains what each key does: the ios array adds LSApplicationQueriesSchemes to Info.plist, the android array adds queries to AndroidManifest.xml, and enableBase64ShareAndroid adds the WRITE_EXTERNAL_STORAGE permission. The README then says to run expo prebuild. Note that enableBase64ShareAndroid pulls in WRITE_EXTERNAL_STORAGE, which is a broad permission on older Android versions; enable it only if you actually pass base64 payloads.

Where react-native-share is the wrong tool

The library does not give you a custom share menu. If your product requirement is a branded sheet with a fixed row of destinations, or a sheet that logs every tap before the user leaves, react-native-share is the wrong layer. The system sheet is owned by iOS and Android; you get a result, not control over the list.

The second limitation is payload handling. Sharing a file on Android means producing a URI the receiving app can read. The README's Expo plugin exposes enableBase64ShareAndroid and the WRITE_EXTERNAL_STORAGE permission, which hints at the friction: base64 and external storage paths exist because file access across app sandboxes is not free. If the target app cannot read your URI, the share fails on the other side, not inside react-native-share, and the error you see may be generic. Test with the actual target app, not just the sheet opening.

The third case is desktop and web. The repository has a windows/ directory and the topic list includes uwp, so Windows is in scope, but the README's install section covers Expo and bare React Native only. There is no documented web path. If your product ships to browsers, this is not the library for that target.

react-native-share compared with a custom share UI

The real alternative is not another package; it is building the share UI yourself and calling each target app's SDK or deep link. That approach buys control: you decide which destinations appear, you can order them, and you can measure selection before the handoff. It costs you maintenance of every integration, and it breaks whenever a target app changes its URL scheme or SDK.

react-native-share takes the opposite trade. You write one call, Share.open, and the platform decides the rest. The README's own framing is "a simple tool for sharing messages and files with other apps," and the word simple is the point. You give up the ability to guarantee a destination exists, and in exchange you stop tracking third-party SDKs.

There is a middle path visible in the repository: the Expo plugin's ios and android arrays let you declare which apps you want to query. That is not a custom UI, but it is a way to make the sheet's behavior more predictable on the platforms where querying requires declaration. If you need a fixed set of destinations and no system sheet, the custom route is still the honest answer.

Maintenance, licence and upgrade cost

The repository is not archived and the last push was on 2026-08-31, which is recent. The release history shows v12.3.1 and v12.3.0 on 2026-05-04, and v12.2.6 on 2026-03-11. The package.json version is 12.3.1, matching the latest release. The project uses semantic-release, and the README carries a semantic-release badge, which means version numbers and changelogs are generated from commit messages rather than hand-written. The repository includes commitlint.config.js and a CHANGELOG.md, consistent with that workflow.

The licence is MIT. In practice that permits commercial use and modification with attribution, but it is your responsibility to confirm the terms and how they interact with the native code you ship. Nothing here is legal advice.

Upgrade cost centers on the native side. The package depends on React Native's bridge, and the README notes that for react-native >= 0.7X and/or the new architecture, the install is the simple yarn add. The repository ships patches/ and patch-package in devDependencies, which suggests the maintainers patch dependencies during development; that is an internal detail, but it is a reminder that a native module can be sensitive to React Native version changes. Pin your version and read CHANGELOG.md before moving across a major.

Editorial conclusion

Adopt react-native-share if your app needs to hand a URL, message or file to whatever apps the user has installed, and you are willing to test on real devices because the share sheet is controlled by the operating system, not the library. Do not adopt it if you need a custom in-app share UI or a fixed set of destinations you control, since the picker is the system's and the user's installed apps determine what appears. Before shipping, verify on a physical Android device that the file:// or content:// URI you pass is readable by the target app, and check whether your Expo config plugin entries match the packages you actually want to query.

Frequently asked questions

Official sources

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