Supported public API to open containing iOS app from Share Extension for image/PDF share sheet imports

Hello Apple Developer Forums,

We are building an iOS app that needs to receive images and PDFs shared from the system share sheet. The sources include Screenshots, Photos, Files, and third-party apps.

The desired user experience is similar to apps such as ChatGPT or Claude: when the user taps our app in the share sheet, the main containing app opens and starts importing or uploading the shared image or PDF.

We are trying to understand the supported public API for this behavior.

Why opening the containing app is important

For our use case, it is important that the containing app opens during the share flow.

The import/upload operation depends on the user’s authenticated session. If the Share Extension attempts to upload the file directly, the auth token available to the extension could be missing, expired, or invalid.

We would prefer not to make the Share Extension responsible for authentication-dependent behavior such as:

validating the user session refreshing tokens handling expired credentials presenting login or re-authentication UI owning upload retry logic tied to auth state

In our architecture, authentication and token refresh are owned by the containing app. The Share Extension should ideally only receive the shared file, persist it in an app group container, and hand off to the main app. The main app would then validate auth state, refresh tokens if needed, and perform the import/upload.

So the desired flow is:

Share Extension receives image/PDF → Share Extension stores file in app group container → Containing app opens → Containing app validates auth/session state → Containing app imports/uploads the file

The alternative flow is problematic for us:

Share Extension receives image/PDF → Share Extension attempts upload directly → Upload may fail if auth token is expired or unavailable → Share Extension would need auth/session responsibilities

We are trying to avoid having an authentication dependency inside the Share Extension implementation.

What we have tried

1. CFBundleDocumentTypes

We added document type support for:

public.image public.png public.jpeg public.heic public.heif com.adobe.pdf

This works for some document-open flows, such as opening files from Files or Photos in certain cases.

However, it does not make the app appear reliably as a share target from Screenshot Share or from some third-party app share sheets.

1. App Intents

We tried using App Intents with IntentFile and:

static var openAppWhenRun: Bool = true

However, this does not seem to create a general-purpose share-sheet receiver for arbitrary image or PDF NSItemProvider payloads.

1. Share Extension

We also implemented a Share Extension that:

1. Receives the shared NSItemProvider.
2. Stores the image or PDF in an app group container.
3. Attempts to open the containing app.

However:

NSExtensionContext.open(_:completionHandler:)

does not appear to foreground the containing app from a Share Extension in the way we need.

We also tested responder-chain openURL: trampoline approaches, but those do not work reliably and appear to be unsupported as a public API contract.

Questions

1. Is there a supported public API for an iOS app to appear as a share target for arbitrary image/PDF NSItemProvider payloads and then directly open the containing app?
2. If apps such as ChatGPT or Claude appear to switch directly into the main app from the share sheet, is that behavior achievable using public APIs available to third-party developers?
3. If directly opening the containing app is not supported, what is the recommended architecture when the import/upload depends on authenticated app state?
4. Is Apple’s recommended design that the Share Extension itself must perform the full import/upload operation, even when that operation depends on auth validation or token refresh?
5. Is there a supported handoff mechanism where the Share Extension can persist the file in an app group container and then ask the system to open the containing app to continue the flow?
6. Are App Intents intended to support this kind of share-sheet attachment import flow, either currently or in a future iOS version?

Reproduction Steps

We created a focused sample project to reproduce the issue.

1. Build and run the app on a physical iPhone.
2. Leave the app installed.
3. Capture a screenshot.
4. Tap the screenshot thumbnail.
5. Tap the Share button.
6. Choose the app’s Share Extension from the share sheet.
7. Observe that the Share Extension receives the image payload.
8. Attempt to open the containing app from the extension.

Expected Result

The Share Extension receives the shared image or PDF, stores it in an app group container, and the containing app foregrounds.

The containing app then validates the user’s authenticated session, refreshes tokens if needed, and performs the import/upload.

Actual Result

The Share Extension receives the image payload and logs the provider type identifiers, but the containing app does not reliably foreground.

NSExtensionContext.open does not provide the desired transition, and responder-chain URL-opening workarounds do not appear to be supported or reliable.

Minimal Question

For image/PDF imports from the iOS share sheet, where upload/import requires authenticated app state, what is the supported implementation?

Is it expected to be:

Share Extension receives the file → Share Extension performs auth-dependent upload/import itself

or is there a supported way to implement:

Share Extension receives the file → Share Extension stores the file in app group container → Share Extension opens or hands off to containing app → Main app performs auth validation and upload/import

Any guidance on the supported architecture would be appreciated.

Thank you.