To add a share sheet to an app you hand the system what to share, and it draws the rest.

What you control, and what the system keeps

Apple describes UIActivityViewController as a view controller you use to offer standard services from your app. The system provides the standard ones: copying to the pasteboard, posting to social sites, sending by mail or by SMS. Your app is responsible for configuring, presenting and dismissing it, and configuring it means naming the data objects the controller should act on. Apps can also define custom services. Nothing on that list is layout.

One presentation rule is not a suggestion. Apple's documentation says you must present the view controller using the appropriate means for the current device: a popover on iPad, modally on iPhone. In practice a tablet build has to give the panel an anchor, which is why a share button that behaves on a phone can fall over on an iPad. React Native exposes exactly that as an anchor option.

What you are left with is real but small. The payload, a handful of options, the ability to hide activities you do not want, and the anchor. You cannot reorder the sheet, restyle it, or count on a given app being installed. Interface copy that says tap WhatsApp will be wrong for a good share of your users, so write the button as share and let the system fill in the rest.

Apple, UIActivityViewController: what your app configures, and the iPad popover rule

What each platform lets you change

On Android you create an intent with the action ACTION_SEND, set the most specific MIME type for what you are sending, then pass that intent to Intent.createChooser so the Sharesheet always appears. Google's guidance about the alternative is blunt. Do not display your app's own list of share targets, and do not create your own variations of the sheet. The system sheet ranks and suggests targets using information about app and user activity that only the system has, so a hand built row of icons is worse at the one job it exists for.

The customisation you do get is bounded, and worth knowing before you promise anyone a design. From Android 10 the sheet can show a preview of shared text, with a title and a thumbnail you provide. On Android 14 and later an app can add custom actions, which appear as small icons at the top of the sheet. You can supply up to two custom chooser targets and up to two initial intents, although the documentation warns that every custom target you add reduces the number the system suggests, and generally discourages adding them. You can also exclude components you control, which is how you keep your own app out of its own share sheet.

Feedback is where the two platforms genuinely differ. Android can tell you which target the user picked if you pass an IntentSender into the chooser and read the chooser result in a broadcast receiver. iOS reports the activity type when the sheet completes. A cross platform wrapper usually gives you the weaker of the two, which is the next section.

Android, send data to other apps: the Sharesheet, custom actions and chooser results

What actually goes in the payload

In a React Native app the whole feature is Share.share with a content object, and the documented fields are narrow. message goes to both platforms. url is iOS only. title is Android only. The options object adds a dialog title on Android, and on iOS a subject, a tint colour, a list of excluded activity types and the iPad anchor. The practical consequence catches people in testing: a link has to sit inside the message string, or Android users share an empty message.

What comes back is asymmetric in a way that quietly breaks analytics. On iOS the promise resolves with an action and an activity type, and a dismissed sheet still resolves, with the dismissed action. On Android the promise always resolves with the shared action. So on Android you cannot tell a real share from someone who opened the sheet and changed their mind, and you never learn the target. Count what the link does afterwards, not what the promise said.

Files take a different route. The text call handles a message, a link and a subject, nothing more. To share content from your app as an actual file, an image, a PDF, an export you generated, Expo's sharing package shares a local file by URI on both Android and iOS. Going the other way, so other apps can share into your app, needs a share extension on iOS and an intent filter on Android. That is native configuration and a rebuild rather than a JavaScript change, and Expo documents that direction as experimental.

Whatever sits in the message, the link is the real product. It should open the app when the app is installed and a web page when it is not, which is mobile app deep linking, and it should land the recipient on the exact thing that was shared rather than a home screen they have to navigate out of.

Is a share button worth building

For an app that already exists, a share sheet is a button, a payload and a test on real hardware. The cost is small, so the question is rarely whether you can and almost always what sits behind the link. If the shared link opens a login wall, an app store page with no context, or a blank screen, the share is spent and nothing comes back from it.

Sharing works when a user has a reason to send something to one specific person: a result they are pleased with, an invitation, a photo, a document, a place to meet. It works badly as a growth channel on its own. If you need people to bring other people, the share button is the easy half, and a structured app referral program with a reward and a tracked link is the half that moves the numbers.

Measure it on the link rather than the sheet. Count taps on the share button and clicks on the link that came out of it, and accept that the middle is dark on Android. Setting that up properly is its own subject, and measuring what gets shared covers the instrumentation in detail.