TSI schrieb:

QLSupportedContentTypes cannot contain system-supported types (UTIs)

Full description
My app is reading machine embroidery designs, e.g. represented in a proprietary file format from Janome with the file name extension .JPX - which is out of my control. In addition I’m providing QuickLook and Thumbnail extensions, used system-wide and in my app.

Unfortunately iOS is assigning the JPEG-2000 file type (UTI „public.jpeg-2000“) to this file extension, and therefore - to work with associated files - my app is importing this UTI and both extensions are listing „public.jpeg-2000“ in their info.plist as QLSupportedContentTypes. This works to some extend in simulators and when debugging from Xcode on a device: Files with the file extension „.JPX“ are listed with thumbnails provided by my extension, although the preview seems to invoke the system-provided viewer and fails. Not perfect, but good enough as my app requires an icon preview (aka thumbnail) in its UIDocumentBrowserViewController.

But when I try to submit my app incl. extensions to the Apple App Store / TestFlight asset validation is reporting an error:

„Asset validation failed. Invalid Info.plist value. The value for the key ‚QLSupportedContentTypes‘ in bundle … is invalid. [public.jpeg-2000] are system-supported types.“

How to assign QuickLook / Thumbnail extensions to 3rd party files types whose extension is conflicting with a system-supported UTI?

Platform
iOS / iPadOS

Hardware and software configuration
MacBook Pro 14“, 2021
macOS 14.2.1 (23C71)
Xcode 15.2 (15C500b)
iOS 17.3 / iPadOS 17.2

Steps to reproduce
Include a custom QuickLook / Thumbnail extension in an iOS app, supporting a 3rd party file type with a name extension already defined by the system. Submit this app for TestFlight testing.

Apple DTS schrieb:

I did some investigation in this area, and my conclusion is that there is no workaround for your use.

In case you are curious, here is how the system works:

1. In today’s file system, a file doesn’t convey the information about its file type and file creator. Your app uses `CFBundleDocumentTypes` and `UTExportedTypeDeclarations` to define and export a file (document) type associated with a UTI, but the file system doesn’t define a location to store the UTI for a file your app creates.

2. The system infers the file type from the file extension name, which is pretty much the only [*] information the system can use for that purpose. In your case, the file extension is `.JPX`.

3. The system then uses the file extension name to find the associated UTI from the launch service database, and use the UTI to determine which app to be launched when, for example, a user double clicks a file.

4. When multiple apps define and export a same file extension name, the system determines which file type (or UTI) should be used. In your case, the system decides JPEG-2000 should be used for `.JPX`, as you have noticed, because JPEG-2000 is a (more) well-known format.

As you can see, the issue lies in #2 – The system has to infer the file type from the extension name. That is obviously not ideal, but the decision was based on some historical reasons and was made after a long debate.

That being said, when developers hit a file extension name conflict, there is no way for them to resolve the conflict. The only thing they can do is to use a different file extension name. I know this is disappointing to you, but with today’s system, it is the reality.

You can file a feedback report <developer.apple.com/bug-reporting/> against the decision related to #2, and probably #4, though any change on that area will be quite fundamental, and need long-time evolvement.

* Back to the earlier day, macOS used a four-character code to represent a file type. That was deprecated long time ago, and doesn’t apply to today’s macOS.