What you put on the share sheet decides whether the receiver can open it
Aliases: share payload · MIME type · UTI · NSItemProvider
What it is
The share sheet does not pass "some content" in the abstract. It passes a typed payload: plain text, a URL, a bitmap, a file copy, or several representations of the same object. Receivers claim what they registered for. A mismatch greys the target out, or accepts a blob that will not open, drops fields, or turns into an unreadable string. Types are UTIs on iOS and MIME types plus ClipData on Android. This entry is about which data leaves. It is not about whether to use the system sheet, and not about who shows up in the destination list.
Why it happens
Receivers register at install time which types they can digest. Matching happens when the sheet opens: the sender's type set is intersected with each receiver's filter. Empty intersection means the app is not a tappable target, or it opens to a blank page. A single representation is brittle. A URL string may not parse as coordinates in a maps app. A JPEG of an invoice may give a finance app no amount and no tax id. HTML shared to a receiver that only claimed plain text loses layout and tables. The OS therefore allows multiple representations of one object (item providers, multi-MIME ClipData); the receiver takes the one it can use and ignores the rest. A quieter failure is lifetime: the sender hands a sandbox path instead of a readable copy, the receiver has no right to that path, and a thumbnail sits over an empty file.
Where it stops holding
When the receiver is a person, not a parser (pasting a link into chat), plain text is usually enough and type precision buys less. Multiple representations of a huge original can blow memory and radios; a thumbnail plus a remote URL beats embedding the whole video. Encrypted or permission-gated content must not ride around the receiver's permission model on the back of a type claim: declaring PDF support is not a license to copy an unauthorized attachment. The sheet already filters by type, so the sender need not branch per destination, but the information the person actually meant to take must exist in at least one type that receivers commonly register.
Applying it
- Offer at least two representations of the same object: human-readable plain text or a URL, plus a structured file the specialist receiver can parse (PDF, vCard, image).
- When sharing a file, hand over a readable copy or a system file provider, not an absolute path inside the app sandbox.
- Verify with three receivers of the same share: a plain-text editor, a specialist app for that type, and an app that never claimed the MIME. The specialist should open every field, the editor should get a readable summary, and the unclaimed type should not appear as a tappable target. Missing fields in the specialist mean another registered representation is required.