Willkommen zu einer Problematik, die mich mittlerweile seit 15 Jahren auf macOS und iOS begleitet!

Zunächst ein kurzer Disclaimer: Mein Kenntnisstand basiert auf Feedbacks zu Bugreports, TSI-Tickets, Internet-Recherche und eigenen Erfahrungen (aka "Try & Error"): Ich bin für jede Ergänzung oder Korrektur dankbar, da ich auch fortwährend mit diesem Thema kämpfe.

Apple hat mit dem Konstrukt der hierarchischen UTIs - basierend auf Dateimerkmalen wie Namenserweiterung, MIME-Type etc. - ein akademisch interessantes, aber leider theoretisches Konzept entwickelt, das in der Realität an zwei Punkten krankt:

1. Dateien mit unterschiedlichen Formaten teilen sich die gleichen Namenserweiterungen, werden aber dem gleichen UTI zugeordnet. Dies war noch besser, als die Launch Services den File Creator Code berücksichtigten (der zusammen mit dem Datei-Typ in den HFS-Attributen stand). Mit Zuge der Annäherung an andere Betriebssysteme (die Dateitypen rein auf Basis der Namenserweiterung identifizieren) ging dieser Vorteil aber verloren. In diesem Fall schlagen Thumbnails / Previews, Meta-Daten und auch ein Öffnen mit der App regelmäßig fehl, wenn Dateien ohne Content-Type vorliegen (z. B. von anderen OS).
   
2. Mangels einer zentralen Registrierungsstelle vergeben App-Entwickler auch bei gleichem Dateiformat unterschiedliche UTIs. Das ist eigentlich vollkommener Humbug: Die UTI definiert ja nicht die App, sondern das Format. Eigentlich sollte der Urheber eines Dateiformates einen eineindeutigen UTI unter Nutzung einer "reverse domain name conversion" benennen und alle dieses Format lesende Apps nutzen diesen. In Realität fühlt sich jeder Entwickler berufen, in seiner App einen eigenen UIT zu definieren und vergrößert damit das Chaos.
   

Zu Deiner konkreten Situation:

Ich verstehe Dich so, dass bei Dir der zweite Fall vorliegt: Die beiden Apps verarbeiten das gleiche Dateiformat, richtig? Dann kannst Du in Deinen Plugins einfach den "fremden" UTI importieren, so dass sich QL-Generator und MD-Importer zuständig fühlen - bis der nächste Entwickler einen neuen UTI für .sid einführt, dann musst Du wieder nachziehen etc. pp. Das funktioniert, solange die anderen Apps nicht selber Quick Look Plugins ausliefern (oder Du mit system-seitig definierten UTIs kollidierst): Quick Look erlaubt keine Priorisierung der gefundenen Plugins und es ist willkürlich, welches zur Anzeige herangezogen wird. Mein entsprechender Bug-Report ist seit >10 Jahren offen und wird es wohl auch bleiben.

Bzgl. der standardmäßig öffnenden App scheint für die Launch Services die Installationsreihenfolge ausschlaggebend zu sein, solange eine Datei noch keinen Content-Type hat (vgl. kMDItemContentType von mdls). Ansonsten zieht der UTI des Content-Types, kann aber vom Benutzer per "Open with..." - "Always open with..." überstimmt werden. Als Entwickler hat Du darauf keinen Einfluss.

Puh, ich komme vom Hölzchen auf's Stöckchen - und höre mal besser auf. Bei Fragen fragen ... Du merkst, das Thema treibt mich um. Und an alle: Wie oben geschrieben gerne korrigieren / ergänzen: Ich bin über jeden Wissensgewinn dankbar!

Mattes

Leichtes déja vue - wie die Zeit vergeht:

Lesen von Dateien mit gleicher File-Extension, aber ungleichem UTI

Hier der aktuelle Stand in meiner App - nach dem historischen Post habe ich dann doch UTIs importiert, um unabhängig von einer Installation der Fremd-App deren Dateien öffnen zu können:

In der App's info.plist hier ein Beispiel mit der Erweiterung .jef: Ich definiere die App im CFBundleDocumentTypes für einen Content-Type als Editor / Owner, für drei andere (fremde) als Viewer / Default. Analog gibt es eine exportierte und drei importierte UTIs, die ich vollständig definiere - keine Ahnung, ob weniger reichen würde:
Bei den Plugins ist es etwas übersichtlicher: Hier gibt es nur eine Rolle für alle UITs, "QLGenerator" bzw. "MDImporter", der alle Content-Types beinhaltet.
Korrektur: Übrigens bemerke ich gerade, dass ich bei den Plugins nur meine eigenen UTIs importiere - insofern ist meine obige Aussage nicht korrekt: Nicht die UTIs müssen alle importiert, sondern die entsprechenden Content-Types als LSItemContentTypes aufgeführt werden. Sorry für den Schnitzer...

Einfach ist anders, Mattes

Edit: Die App hat übrigens 11 exportierte und 29 importierte UTIs bei 20 Dokument-Typen ... und ich habe sicher nicht alle Apps auf dem Schirm, die "meine" Dateiformate schreiben...

Alles gut, kein Stress
Meine Logik war, dass die Plugins ja "nur" UTIs konsumieren, die von einem anderen Bundle definiert / exportiert werden: Der Haupt-App. Ganz ehrlich glaube ich aber nicht, dass es in diesem Kontext von Apps mit enthaltenen Plugin irgendeinen Unterschied macht.

Hier der entsprechende Kommentar von Apple

Apple schrieb:

An imported UTI declaration is used to declare a type that the bundle does not own, but would like to see available on the system. For example, say a video-editing program creates files using a proprietary format whose UTI is declared in its application bundle. If you are writing an application or plugin that can read such files, you must make sure that the system knows about the proprietary UTI, even if the actual video-editing application is not available. To do so, your application should redeclare the UTI in its own bundle but mark it as an imported declaration

Ich würde die info.plists immer vollständig definieren - was wolltest Du denn nur in der App machen? Mein Konstrukt läuft nun seit Jahren problemlos (bzw. nur mit den genannten Problemen bzgl. Kollisionen mit anderen Apps bzw. System-UTIs), basiert aber auch viel auf Try & Error: Offizielle Dokumentationen, aber auch Google fand ich nur bedingt hilfreich...

Mattes