MTP-Dateien auf Mac einbinden: Warum NSOpenPanel Android-Geräte ignoriert

Immer wieder kämpfen Entwickler mit einer scheinbar trivialen Aufgabe: Wie lässt sich auf einem Mac ein Android-Gerät über MTP (Media Transfer Protocol) in eine Anwendung einbinden? Die Antwort lautet: Es geht nicht – zumindest nicht mit den üblichen macOS-Bordmitteln.

Bei der Entwicklung der App HiyokoMTP stießen wir auf diese Einschränkung: Der native macOS-Dateidialog NSOpenPanel zeigt Android-Geräte schlicht nicht an. Der Grund dafür liegt tief in der Architektur von macOS verborgen.

Warum der Standard-Dateidialog Android-Geräte nicht anzeigt

macOS stellt Anwendungen über APIs wie NSOpenPanel eine Schnittstelle zum Dateisystem bereit. Diese APIs setzen jedoch voraus, dass Speichermedien als vollständig eingebundene Volumes vorliegen – etwa wie bei einer Festplatte oder einem USB-Stick. MTP funktioniert jedoch völlig anders: Es handelt sich um ein zustandsbehaftetes Protokoll, das direkt über USB kommuniziert und keine klassische Dateisystem-Einbindung erfordert.

Früher nutzte das Tool Android File Transfer einen virtuellen Mountpunkt, um Android-Geräte als Volume darzustellen. Diese Methode war jedoch fehleranfällig, benötigte Kernel-Erweiterungen und wurde weitgehend eingestellt. Moderne MTP-Implementierungen arbeiten stattdessen direkt mit dem Gerät zusammen und verwalten den Objektbaum selbst – das Betriebssystem sieht die Daten nie als klassisches Verzeichnis.

Das Ergebnis: NSOpenPanel, NSSavePanel und sogar die Finder-Integration ignorieren Android-Geräte komplett. Entwickler müssen sich selbst um die Dateiauswahl kümmern.

Eigenen MTP-Dateidialog selbst entwickeln: So geht’s

Wer trotzdem eine benutzerfreundliche Lösung braucht, muss einen eigenen Dateidialog implementieren. Hier sind die zentralen Schritte am Beispiel von HiyokoMTP:

1. Backend: MTP-Integration in Rust

Die Kommunikation mit dem Android-Gerät übernimmt die Rust-Bibliothek libmtp. Über eine Tauri-IPC-Schnittstelle wird eine Funktion bereitgestellt, die Verzeichnisinhalte abruft:

#[tauri::command]
fn list_mtp_dir(path: String) -> Result<Vec<MtpObject>, String> {
    // Anfrage an das MTP-Gerät senden und Objektliste zurückgeben
}

Die Funktion akzeptiert einen Pfad und gibt eine Liste von Objekten (Dateien und Ordner) zurück. Wichtig ist, dass die Implementierung die Hierarchie des MTP-Baums nachbildet – ein klassisches Dateisystem-Layout gibt es hier nicht.

2. Frontend: React-Komponente für die Navigation

Auf der Benutzeroberfläche wird eine einfache, aber funktionale Navigation realisiert. Der Nutzer sieht eine Liste von Ordnern und kann durch die Hierarchie blättern – ähnlich wie im macOS-Finder:

// Beim Öffnen des Dialogs
const root = await invoke("list_mtp_dir", { path: "/" });

// Bei Auswahl eines Ordners
const contents = await invoke("list_mtp_dir", { path: selectedPath });

// Navigationstack für Zurück-Button
const [navStack, setNavStack] = useState<string[]>(["/"]);

Die Implementierung erfordert etwas Aufwand, da macOS keine native Unterstützung bietet. Der Entwickler muss selbst den Pfadverlauf verwalten, Ladezustände anzeigen und Fehlerfälle abfangen.

3. Praktische Herausforderungen im Alltag

In der aktuellen Version von HiyokoMTP ist ein solcher Dateidialog noch nicht umgesetzt. Nutzer müssen Pfade manuell eingeben oder auf vordefinierte Speicherorte zurückgreifen. Ein vollständiger MTP-Dateidialog ist jedoch für Version 2 geplant.

Wer selbst an einem MTP-Client arbeitet, sollte diese Architektur als Ausgangspunkt nutzen. Es gibt keine Abkürzung über native APIs – der Umweg über eine benutzerdefinierte Lösung ist unvermeidbar.

Fazit: Kein Workaround, aber eine machbare Lösung

Die Einschränkung von NSOpenPanel bei MTP-Geräten ist kein Bug, sondern eine Konsequenz der macOS-Architektur. Entwickler, die Android-Geräte in ihre Apps integrieren möchten, müssen daher eigene Lösungen schaffen. Der Aufwand ist überschaubar, erfordert aber tiefgehende Kenntnisse in MTP, USB-Kommunikation und UI-Entwicklung.

Wer bereit ist, diese Hürde zu nehmen, kann mit der oben skizzierten Architektur eine stabile und nutzerfreundliche Lösung umsetzen. Die nächste macOS-Version oder zukünftige MTP-Bibliotheken könnten diese Lücke möglicherweise schließen – bis dahin bleibt Eigeninitiative gefragt.