How expo-share-intent receives shared URLs, text and files in an Expo app

The receiving end of sharing, not the sending end

React Native apps usually treat sharing as a one way street: you call a share API and hand text or a URL to the system sheet. expo-share-intent works on the opposite end. It lets a user pick your app from the share sheet of another app on iOS or Android and pass along URLs, text, images, videos and files, then exposes all of it through one JavaScript API that behaves the same on both platforms. The stated aim of the project is identical behaviour between iOS and Android so that a single piece of logic in the main application can handle the incoming payload. The audience is therefore narrow and specific: teams shipping an Expo app that must accept content from elsewhere, such as a link shortener, a media collector, a chat client that handles shared links, or a scanner that receives images. If your app only shares content outbound, this package has nothing to offer you.

The native module hands the payload to your React tree

The mechanism combines native iOS and Android code with an Expo config plugin. The package publishes `expo-module.config.json`, an `app.plugin.js` entry point and a `plugin` directory that the Expo plugin pipeline applies during prebuild. Inside your app you call the `useShareIntent` hook, and it returns four values: `hasShareIntent`, `shareIntent`, `resetShareIntent` and `error`. The `shareIntent` object carries the payload fields, with `shareIntent.text` holding the raw text or web URL and `shareIntent.webUrl` holding a link extracted from that raw text. On iOS the raw value comes from text and weburl content, on Android from text and the wildcard text/* MIME type. For apps with several screens and several providers, `ShareIntentProvider` with `useShareIntentContext` lets deeper components read the same data. The design decision that matters is that the extension redirects the user into the main application rather than running shared code inside a separate extension process, so handling logic lives in one place.

Registering the plugin, the scheme and the content types

Installation is an ordinary package add, followed by configuration in `app.json`.

yarn add expo-share-intent
# or
npm install expo-share-intent

Since Expo 52 the linking package is also required.

expo install expo-linking

The plugin has to be registered in `app.json`.

  "plugins": [
      "expo-share-intent"
  ],

A custom URL scheme gives the share extension a route back into the app.

  "scheme": "my-app"

Only text and URL sharing is active by default, so an app that also expects images or files has to configure the content types it wants. You should see your app appear as a target in the system share sheet once the scheme is registered and the plugin has been applied to the native project.

Expo Go cannot be used, so every build becomes a native build

The project states plainly that Expo Go cannot be used with this package. The reason is structural rather than a policy choice: a share target needs a native share extension registered inside the built binary, and Expo Go ships a fixed binary that cannot be regenerated with your scheme and content types. The cost lands on the team. Every developer needs a local native build instead of a client download, and a continuous integration pipeline needs a development build step. The README also notes that up to version 5.0 the package required a post-install script plus an Xcode patch copied into your `patches` directory, with `patch-package` added and a `postinstall` entry in `package.json`. From Expo 55 with v6.0 and newer that patching step is no longer required, which removes one piece of upgrade friction that older adopters still carry.

The version table is the real upgrade constraint

Versioning is where this package will cost you time. The README keeps a compatibility table that binds an Expo SDK to a minimum major version: SDK 57 needs 8.0+, SDK 56 needs 7.0+, SDK 55 needs 6.0+, SDK 54 needs 5.0+, and legacy rows go back to SDK 49 with 0.2+. The published releases follow that pattern, with v7.0.0 on 2026-06-06, v8.0.0 on 2026-07-03 and v8.0.1 on 2026-07-10, and the last push to the repository on 2026-07-10. The package version therefore tracks the Expo SDK upgrade rather than any feature list. Moving to a new SDK means taking a new major of this package, and the most recent two majors arrived within a month of each other. That is fine for a team that upgrades the SDK on its own schedule and uncomfortable for one that pins a release for months. The three example apps, `example/basic`, `example/expo-router` and `example/react-navigation`, show how the hook behaves under the navigation styles teams tend to use.

Gaps the documentation leaves around reset and concurrent shares

A few holes are worth naming before you commit. There is no documented rollback procedure, so if the extension misbehaves after an upgrade there is no stated path back to a known good native state. The documentation also does not explain what happens when a share arrives while the app is already running and a deep link is in flight, which is exactly the case where a provider based tree and a hook based tree could disagree about which payload is current. The `resetShareIntent` value exists to clear that state, but the ordering rules around it are not spelled out. The alternative to this package is not so much another module as a different amount of work: writing the share extension target and the URL scheme routing by hand on both platforms, then keeping that native code aligned with every SDK bump. expo-share-intent trades that work for a hard dependency on the version table. It ships under the MIT licence, which places no obligation on closed source apps beyond retaining the licence text and copyright notice, though the native extension code carries its own headers that are worth reading.

Editorial conclusion

Adopt expo-share-intent when your Expo app has to receive links, text or files from other apps and you can rebuild native binaries for every SDK bump. Skip it if you are staying inside Expo Go, if you only need outbound sharing, or if you cannot tie your release cycle to the SDK. Before committing, check the compatibility table against the SDK you actually run and decide how you will handle a second share arriving while one is still being processed.

Frequently asked questions

Official sources

1. achorein/expo-share-intent on GitHub
2. Issues
3. License: MIT
4. README
5. Releases