NSInvalidArgumentException while sharing in UIDocumentInteractionController

The stack you've posted is entirely within the ShareSheet framework — no app frames are visible. -[__NSArrayM insertObject:atIndex:] + 1276 is the code path that throws NSInvalidArgumentException when you pass a nil object, so something inside SHSheetActivityItemsManager loadItemProvidersForRequest:activity:completion: is receiving a nil item provider for one of the activity items and adding it to an array without a nil check. That suggests a framework issue, but I'll need more to be confident. It's also possible that the specific item you're passing to UIDocumentInteractionController is what triggers the nil-provider path.

A few things would help narrow this down:

1. A full .ips crash report. Beyond the top frames, the thread that crashed, the other threads' states, and the binary images list all matter for diagnosis. The exception reason string matters most — the "*** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '...'" line that usually precedes this kind of stack. That reason string often names what was nil.

2. The specific iOS 26.x point releases where you're seeing this. Is it every 26.x build, or did it start at a particular one?

3. How you're configuring and presenting the UIDocumentInteractionController: the source of the file URL (bundled resource, downloaded file, file picked using UIDocumentPickerViewController, security-scoped, and so on), whether you set uti explicitly, and which present… method you're calling.

4. The rate you see this in your analytics. Is it a small fraction of share attempts or most of them?

Once you have a complete .ips, please share it here and file a Feedback report with it attached — without one, engineering doesn't have enough to investigate. If you can, attach more than one sample, because variation across crashes often reveals whether the trigger is a specific file type, a specific URL shape, or something environmental. If you do file, please post the FB number here so I can reference it.

Thank you for your quick response.

1. Attached 3 decrypted stack traces. Some sensitive data is hidden

    guard url.isFileURL, url.pathExtension == "pdf" else {
      completion(false)
      return
    }

    guard fileManager.fileExists(atPath: url.path) else {
      completion(false)
      return
    }

    let interactionController = UIDocumentInteractionController(url: url)
    interactionController.delegate = self
    let success = interactionController.presentPreview(animated: true)

1. We are seeing this on a small number of users, so far it is not a critical percentage. At the moment, we cannot estimate which part of the attempts to open files is failing and which is successful. We expect technical improvements from APPLE and hope for an early fix.

Thanks for sending the three samples and the code snippet. They confirm the symptom (NSInvalidArgumentException: object cannot be nil from [__NSArrayM insertObject:atIndex:]) but don't yet narrow the source.

I traced the symbol from your stack into the ShareSheet binary. The crash lands inside the block that processes activity items in loadItemProvidersForRequest:activity:completion:, in the branch that handles NSURL items. That branch resolves metadata for the file URL via LaunchServices and FileProvider, builds a security context, and constructs an NSArray from the result. The NSArray construction has no nil guard, so any nil reaching it throws the exception you see.

On an iPhone 16 running iOS 26.4, I built a small reproducer that presents a downloaded PDF four ways: UIDocumentInteractionController.presentPreview, QLPreviewController, UIActivityViewController with the file URL, and UIActivityViewController with an NSItemProvider built from the PDF's bytes. None crashed. The three file-URL paths produced (null) returns from LaunchServices and FileProvider in the console; the NSItemProvider-from-data path did not. Per the disassembly, the three file-URL paths all go through the same NSURL branch as your current code; the NSItemProvider path bypasses it.

The three logs you sent are all from the same app in the same embedding environment (the CrBrowserMain thread name plus the KeyCoreMultiplatform and XNNPACK symbols in other threads), so identical stacks across the three aren't evidence that the framework is the trigger — they're evidence that the same path in your app reaches the same crash. Two interpretations are equally consistent with the data:

• Framework cause: the upstream metadata resolution returns nil under conditions we haven't reproduced; the unguarded call site lets that nil through.
• Environment cause: something in the embedded runtimes (Chromium URL/object lifetime, Kotlin/Native ARC interop, how file URLs flow through that stack) produces a nil where the framework expects non-nil; the unguarded call site is where it lands.

The missing nil guard is worth Apple knowing about either way. But the trigger source matters for what would actually move the rate down in your build, and the logs alone can't tell them apart.

What would help differentiate: a reproducible case, or instrumentation in your share path that captures — on both crash and success — the activity that was tapped, the file URL, the FileProvider domain (if any), the directory the file lives in (NSTemporaryDirectory, NSCachesDirectory, an app group container, a UIDocumentPickerViewController-vended URL), and ideally whether the URL was produced or touched by Chromium vs. native code paths. Analytics correlations by iOS version, device, share activity, and URL provenance would do the same.

Without a reproduction, recommending the NSItemProvider-from-data change — or any code change — would rest on inference rather than evidence. The disassembly identifies the unguarded site; instrumentation in your environment is what would identify the trigger.

Hello,

We can confirm that the issue occurs on all versions of iOS 26.

Key details:

The file is definitely stored in the device’s local storage (in the Documents directory).

A file existence check is performed before opening — and it always passes successfully.

Here are a few examples of file URLs where the crash occurs:

file:///var/mobile/Containers/Data/Application/0707C22C-7C21-404A-8074-5C0EE02D198E/Documents/%D0%9E%D0%B4%D0%BE%D0%B5%D0%B2%D1%81%D0%BA%D0%B8%D0%B8%CC%86-%D0%92%D0%BB%D0%B0%D0%B4%D0%B8%D0%BC%D0%B8%D1%80-%D0%A4%D0%B5%D0%B4%D0%BE%D1%80%D0%BE%D0%B2%D0%B8%D1%87(2).-%D0%93%D0%BE%D1%80%D0%BE%D0%B4%D0%BE%D0%BA-%D0%B2-%D1%82%D0%B0%D0%B1%D0%B0%D0%BA%D0%B5%D1%80%D0%BA%D0%B5.pdf

file:///var/mobile/Containers/Data/Application/A28276DB-CF84-46E0-A5B6-D6796E426A0C/Documents/%D0%9E%D0%B1%D0%BB%D0%BE%D0%B6%D0%BA%D0%B8%20%D0%B4%D0%BB%D1%8F%20%D1%82%D0%B5%D1%82%D1%80%D0%B0%D0%B4%D0%B5%D0%B8%CC%86.pdf

We’ve found a public report about a similar issue: . We believe it would be useful to study it. https://github.com/fluttercommunity/plus_plugins/issues/3784?ref=https://githubhelp.com