iOS Intune MAM UTI registrations

Question

iOS Intune MAM UTI registrations

Ricki Gregersen (RGX) 0

I am experiencing problem implementing an NSReplicatedFileProvider in IOS that uses the Intune SDK.

Microsoft Intune App SDK 21.6.0 swizzles 16 methods on NSItemProvider including registeredTypeIdentifiers and initWithContentsOfURL:. When a managed-source app passes a file URL to UIActivityViewController, the swizzles rewrite the item's type identifiers into the com.microsoft.intune.mam.* namespace. The iOS share-sheet matchmaking process searches for share/action extensions whose NSExtensionActivationRule declares those types. Word for iOS declares only the standard UTIs, not the MAM-prefixed variants, so Word does not appear in the share sheet. OneNote, which does declare the MAM types, appears correctly. Confirmation: a build of our app without IntuneMAMSwift linked (vanilla) has zero swizzles on these classes and Word appears + opens + writes back. Is there a supported path for in-place editing of file-provider-vended documents in Word from a third-party Intune-managed source app?

0 comments

2 answers

Your answer

Answer 1

Thank you for confirming there is no documented mechanism. For our records, can you confirm whether this is a known limitation of Word for iOS's share extension activation rules — that they don't include the com.microsoft.intune.mam.* prefixed UTIs — and whether this has been raised with the Word for iOS team as a feature request? We've validated the gap empirically: a build of our app without IntuneMAMSwift linked has Word appearing in the share sheet and opening files with in-place editing + writeback through our NSFileProviderReplicatedExtension. Linking IntuneMAMSwift breaks this through the documented UTI rewriting. Routing users through Files.app is our planned workaround, but a Word-side fix would close the gap for all third-party file provider apps under Intune MAM.

Answer 2

There is no supported path described for enabling in-place editing of NSFileProvider/NSFileProviderReplicatedExtension–vended documents in Word for iOS from a third‑party Intune-managed source app beyond the standard Intune MAM integration patterns.

The documented and supported behaviors for Intune MAM on iOS in this area are:

When using UIActivityViewController and Intune MAM, the SDK rewrites UTIs into the com.microsoft.intune.mam.* namespace and expects participating apps/extensions to declare those MAM-prefixed types in their NSExtensionActivationRule.
- Guidance is explicitly given to:
  - Configure NSExtensionActivationRule to support a single file and all types from the app’s CFBundleDocumentTypes prefixed with com.microsoft.intune.mam.*.
  - Update existing Share/Action extensions to add the MAM-prefixed types for each supported type.
- The IntuneMAMConfigurator tool can be used to add the Intune types or convert from predefined constants to predicate syntax.
For File Provider extensions (non‑replicated and replicated), the supported integration points are:
- Use the dedicated libIntuneMAMSwiftFileProvider.xcframework for the non‑UI portion of File Provider extensions.
- For non‑replicated providers (NSFileProviderExtension):
  - In startProvidingItemAtURL:completionHandler:, check [[IntuneMAMPolicy instance] shouldFileProviderEncryptFiles] and use IntuneMAMFileProtectionManager (encryptFile:forAccountId:) when required, sharing out a copy instead of storing encrypted content in cloud storage.
  - In importDocumentAtURL:toParentItemIdentifier:completionHandler:, use isFileEncrypted: and decryptFile:toCopyPath:; in multi-identity scenarios, also check canReceiveSharedFile:.
- For replicated providers (NSFileProviderReplicatedExtension):
  - In fetchContentsForItemWithIdentifier:version:request:completionHandler:, again use shouldFileProviderEncryptFiles and encryptFile:forAccountId: and share out a copy when encryption is required.
  - In createItemBasedOnTemplate:fields:contents:options:request:completionHandler:, use isFileEncrypted: and decryptFile:toCopyPath: and canReceiveSharedFile: for multi-identity.
  - Wherever an NSFileProviderItem is created and passed to the system, call protectFileProviderItem:forAccountId: with the owner identity.
For handling incoming content into a managed app, the supported checks are:
- canReceiveSharedItemProvider: for NSItemProvider objects (after loading the item via loadItemForTypeIdentifier:options:completionHandler:).
- canReceiveSharedFile: for file paths.
- If sharing/opening is blocked by policy, use showSharingBlockedMessage from IntuneMAMUIHelper.h to present a generic blocked message.
For URL-based flows, the supported pattern is:
- Add all schemes used with UIApplication canOpenURL to LSApplicationQueriesSchemes, plus their -intunemam variants and the additional Intune/MTD schemes listed.
- If the list is full and some -intunemam schemes must be removed, call [IntuneMAMPolicy isURLAllowed:url isKnownManagedAppScheme:YES] first; if allowed, temporarily set an empty identity and call canOpenURL().

The documentation does not provide a mechanism to force first‑party apps like Word for iOS to declare or honor the com.microsoft.intune.mam.* UTIs for File Provider–vended items from third‑party apps, nor does it describe any special contract to enable in-place editing in Word beyond the general MAM UTI and File Provider guidance above.

References: