Beim Remote-Debugging einer macOS-Dokumenten-App tritt häufig Folgendes auf: Wird die App im Terminal ausdrücklich angegeben, öffnet sie die Beispieldatei. Ein Doppelklick auf dieselbe Datei auf dem Schreibtisch führt dagegen zu einer anderen App, oder macOS fragt, womit die Datei geöffnet werden soll. Der erste Erfolg zeigt nur, dass die App die Datei entgegennehmen kann. Ob die Dateitypzuordnung funktioniert, ist damit nicht geprüft. Dafür müssen Typdeklaration, Verarbeitung durch die App und Standardöffnung als drei getrennte Ergebnisse betrachtet werden.
Als Beispiel dient hier eine eigene Datei mit der Endung .notejson. Ihr Inhalt ist JSON; die Endung kennzeichnet sie als Dokument der App. Die Schritte sollten mit einer bereits gebauten, lauffähigen macOS-App durchgeführt werden. Verwenden Sie für die Testdatei ausschließlich fiktive Daten, keine produktiven Dokumente.
Zuerst den Dateityp definieren, nicht nur die Endung prüfen
Ein eigenes Format braucht eine stabile Typkennung. Im Beispiel lautet sie dev.sample.notejson, die Dateiendung ist notejson, und der Inhalt entspricht JSON. Die Typdeklaration der App muss zwei Dinge abdecken: den Typ exportieren und angeben, dass die App ihn öffnen kann. Eine Prüfung der Dateiendung im Code allein richtet noch keine Zuordnung im Finder ein.
Konfigurieren Sie im App-Target von Xcode den exportierten Typ und die Document Types. Prüfen Sie anschließend die Info.plist im fertigen App-Bundle. Beim exportierten Typ müssen Typkennung, Dateiendung und übergeordneter Typ zu finden sein, dem er entspricht. Der Dokumenttyp muss auf dieselbe Kennung verweisen. Kann die Beispiel-App Dokumente nur anzeigen, wählen Sie als Dokumentrolle Viewer. Geben Sie keine Bearbeitungsfunktion an, die noch nicht implementiert ist.
Geprüft wird das gebaute App-Bundle, nicht eine Einstellung in der Projektoberfläche, die noch nicht im Build gelandet ist.
Ist das Format tatsächlich kein JSON, deklarieren Sie es nicht nur für dieses Beispiel als JSON-konform. Die Typbeziehung muss den wirklichen Inhalt abbilden. Bauen Sie die App nach einer Änderung der Deklaration erneut: Ein vorhandenes App-Bundle aktualisiert sich nicht von selbst, wenn sich Projekteinstellungen ändern.
Die Deklarationen im ausgelieferten Bundle prüfen
Legen Sie zunächst die App, die Sie abnehmen möchten, unter einem festen Pfad ab. Die folgenden Befehle verwenden /Applications/NoteReader.app als Beispiel. Passen Sie APP vor dem Ausführen an den Pfad Ihrer App an:
APP="/Applications/NoteReader.app"
test -d "$APP/Contents" || exit 1
plutil -extract UTExportedTypeDeclarations json -o - "$APP/Contents/Info.plist"
plutil -extract CFBundleDocumentTypes json -o - "$APP/Contents/Info.plist"
Prüfen Sie in der ersten Ausgabe dev.sample.notejson und notejson, in der zweiten dieselbe Typkennung und die Dokumentrolle. Meldet plutil, dass ein Schlüssel fehlt, prüfen Sie zuerst die Target-Konfiguration und das Build-Ergebnis, statt direkt zum Doppelklick-Test überzugehen. Bei manchen Projekten entsteht die endgültige Info.plist aus Build-Einstellungen. Maßgeblich ist deshalb die Datei im Bundle.
Vergewissern Sie sich auf dem Remote-Mac außerdem, dass Sie genau die gerade gebaute Version prüfen. Liegen gleichnamige Apps sowohl im Download- als auch im Programme-Ordner, können der Test mit ausdrücklich angegebenem Pfad im Terminal und der Test der Standardöffnung im Finder unterschiedliche Kopien betreffen. Halten Sie den Bundle-Pfad fest und entfernen Sie alte Kopien, die nicht zum Test gehören. Das ist oft hilfreicher, als die Typdeklaration wiederholt zu ändern.
Fehler mit zwei Öffnungsarten eingrenzen
Erstellen Sie eine temporäre Beispieldatei. Öffnen Sie sie zuerst mit ausdrücklich angegebener App und testen Sie danach die Standardauswahl des Systems:
APP="/Applications/NoteReader.app"
CASE="$(mktemp -d)"
printf '{"title":"association-check"}\n' > "$CASE/demo.notejson"
open -a "$APP" "$CASE/demo.notejson"
open "$CASE/demo.notejson"
Wenn open -a funktioniert, wurde die angegebene App angewiesen, die Datei zu verarbeiten. Prüfen Sie anschließend, ob sie den Beispielinhalt tatsächlich anzeigt. Ein sichtbares Fenster allein belegt noch nicht, dass die Datei gelesen wurde. Erst der zweite Befehl lässt die App weg und durchläuft damit die Auswahl für die Standardöffnung. Sie können dieselbe Datei auch im Finder doppelklicken und prüfen, welche App sich tatsächlich öffnet.
Die Standardzuordnung hängt auch von den bereits auf diesem Mac installierten Apps und den Entscheidungen des Benutzers ab. Halten Sie im Abnahmeprotokoll daher das „Ergebnis mit ausdrücklich gewählter App“ und das „Ergebnis der Standardöffnung für den aktuellen Benutzer“ getrennt fest. Aus Letzterem lässt sich nicht schließen, dass sich alle Macs gleich verhalten. Erscheint ein Dialog zur App-Auswahl, protokollieren Sie auch das; es ist keine erfolgreiche automatische Zuordnung.
Anhand der Symptome prüfen, statt vorschnell den Lesecode zu ändern
| Beobachtung | Zuerst prüfen |
|---|---|
| Im App-Bundle fehlt die Typ- oder Dokumentdeklaration | Target-Konfiguration, tatsächliches Build-Ergebnis |
| Auch mit ausdrücklich gewählter App lässt sich die Datei nicht lesen | Dateiinhalt, Annahme und Verarbeitung durch die App |
| Die gewählte App kann die Datei lesen, die Standardöffnung führt aber woandershin | Standardzuordnung des aktuellen Benutzers, weitere Kopien der App |
| Die App startet, zeigt aber ein leeres Dokument | Fehlerbehandlung nach dem Empfang der Datei und Zustand der Oberfläche |
Besonders die letzten beiden Fälle lassen sich leicht verwechseln. Auch nachdem das System die Datei an die App übergeben hat, kann diese die Verarbeitung wegen eines fehlerhaften Beispielformats ablehnen. Umgekehrt kann eine App die Datei problemlos lesen, ohne vom System standardmäßig ausgewählt zu werden. Stellen Sie zuerst fest, an welcher Stelle die Weiterleitung scheitert, und ändern Sie dann den betreffenden Code.
Löschen Sie nach der Abnahme die temporäre Beispieldatei. Halten Sie im Build-Protokoll den Pfad zum App-Bundle, die Typkennung, die Dateiendung der Beispieldatei und die Ergebnisse beider Öffnungsarten fest. Wenn Sie später die Info.plist oder den Code zum Lesen von Dokumenten ändern, können Sie mit denselben Prüfungen feststellen, ob sich die Typzuordnung oder das Verhalten innerhalb der App geändert hat – statt sich auf „Ich habe einmal doppelt geklickt“ zu verlassen.
Häufig gestellte Fragen
Warum öffnet ein Doppelklick eine andere App, obwohl open -a funktioniert?
Mit open -a wird die App ausdrücklich gewählt; die Standardzuordnung wird damit nicht geprüft. Kontrollieren Sie die Typdeklaration im Bundle und testen Sie die Datei danach ohne -a oder per Doppelklick.
Was bedeutet es, wenn die App startet, den Dateiinhalt aber nicht lesen kann?
Die Weiterleitung an die App und das Parsen des Inhalts sind getrennte Schritte. Prüfen Sie zuerst das tatsächliche Dateiformat und anschließend die Leseroutine sowie deren Fehlermeldung.
Binden Sie einen Cloud-Mac in Ihren Workflow ein
VPSPush bietet dedizierte physische Macs mit Fernzugriff. Wählen Sie Standort und Laufzeit und prüfen Sie im Bestellvorgang die Zugangsdaten und den Endpreis.