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 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. 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. Share Extension We also implemented a Share Extension that: Receives the shared NSItemProvider. Stores the image or PDF in an app group container. 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 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? 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? If directly opening the containing app is not supported, what is the recommended architecture when the import/upload depends on authenticated app state? 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? 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? 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. Build and run the app on a physical iPhone. Leave the app installed. Capture a screenshot. Tap the screenshot thumbnail. Tap the Share button. Choose the app’s Share Extension from the share sheet. Observe that the Share Extension receives the image payload. 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.

Here’s a polished Apple Developer Forums post you can use. I removed personal identifiers such as email, Person ID, Team ID, and DTS Case ID because the forums are public. The post is based on your DTS request and Apple’s response directing you to ask in the Developer Forums.  ⸻ Title Supported public API to open containing iOS app from Share Extension for image/PDF share sheet imports Tags iOS Share Extension UIKit App Intents Uniform Type Identifiers Post Body 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. What we have tried 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. 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. Share Extension We also implemented a Share Extension that: Receives the shared NSItemProvider. Stores the image or PDF in an app group container. 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 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? 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? If directly opening the containing app is not supported, is the recommended design to perform all upload/import work inside the Share Extension itself? 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. Build and run the app on a physical iPhone. Leave the app installed. Capture a screenshot. Tap the screenshot thumbnail. Tap the Share button. Choose the app’s Share Extension from the share sheet. Observe that the Share Extension receives the image payload. Attempt to open the containing app from the extension. Expected Result The containing app should foreground and receive a URL or other handoff signal indicating that a shared file is available for import. 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, should the supported implementation be: Share Extension receives the file → Share Extension performs the upload/import itself rather than: Share Extension receives the file → Share Extension opens containing app → Main app performs upload/import Any guidance on the supported architecture would be appreciated. Thank you.