Eigentlich sollte es nur ein kurzer Test sein.

Csio aus Ungarn hatte mich gefragt, ob ich eine erste macOS-Version des MeDFLIstvan DFLI Editors auf meinem neuen MacBook Air M4 ausprobieren könnte. Der Editor selbst stammt von ByteHexer, basiert auf Java und wurde ursprünglich hauptsächlich für Windows entwickelt.

"Einmal starten und kurz Feedback geben."

Wie schwer kann das schon sein?

Die ersten Stolpersteine

Natürlich fing alles damit an, dass das Build-Skript überhaupt nicht starten wollte.

Operation not permitted

Willkommen auf macOS.

Schnell stellte sich heraus, dass die ZIP-Datei über WhatsApp verschickt worden war und macOS die Datei deshalb unter Quarantäne gestellt hatte. Also erstmal:

• Quarantäne-Attribute entfernen (xattr)
  

• Ausführungsrechte setzen (chmod +x)
  

• und dann den ersten Build starten.
  

Der erste Erfolg ließ nicht lange auf sich warten: Die Anwendung ließ sich tatsächlich starten.

Rosetta, Duke und die große Verwirrung

Die App funktionierte bereits erstaunlich gut.

Allerdings gab es zwei Dinge, die überhaupt keinen Sinn ergaben:

• Beim Start aus dem Finder erschien immer eine Rosetta-Warnung.
  

• Im Dock tauchte statt eines eigenen Icons nur das bekannte Java-"Duke"-Icon auf.
  

Das Verrückte daran:

Die Anwendung selbst lief problemlos.

Der eigentliche Editor funktionierte bereits. Nur das Drumherum machte den Eindruck, als wäre irgendwo noch ein Intel-Mac von 2015 beteiligt.

Ein neues Packaging-System

Parallel arbeitete ByteHexer bereits an einem komplett neuen Packaging-Prozess auf Basis von jpackage, um native macOS-App-Bundles zu erzeugen.

Also begann die eigentliche Fehlersuche.

ARM64 prüfen.

Java-Version prüfen.

Launcher prüfen.

Finder testen.

Rosetta testen.

Icon testen.

Zwischendurch entstand gefühlt mehr Terminal-Ausgabe als eigentliche Anwendung.

Der kurioseste Bug der ganzen Reise

Nach vielen Tests startete die neue App zwar, verschwand aber nach wenigen Millisekunden sofort wieder.

Erst ein Blick in die erzeugte Konfigurationsdatei brachte den entscheidenden Hinweis.

Aus:

-Dapple.awt.application.name=MeDFLIstvan Editor

war intern geworden:

java-options=-Dapple.awt.application.name=MeDFLIstvan
java-options=Editor

Ein einziges Leerzeichen hatte dafür gesorgt, dass Editor plötzlich als eigene Java-Option interpretiert wurde.

Nach dem Entfernen des Leerzeichens lief die Anwendung sofort stabil.

Manchmal kämpft man tagelang gegen Apple Silicon, ARM64, Java und Finder – und am Ende gewinnt ein Leerzeichen.

ZIP ist nicht gleich ZIP

Als die Anwendung schließlich sauber lief, tauchte noch ein letzzter Stolperstein auf.

Ein macOS-.app-Bundle ist technisch kein einzelnes Programm, sondern ein kompletter Verzeichnisbaum mit speziellen Dateirechten und Metadaten.

Ein normales ZIP (zum Beispiel über Windows oder manche Messenger) kann diese Informationen beschädigen.

Deshalb wurde das finale Release direkt unter macOS mit ditto erstellt:

ditto -c -k --sequesterRsrc --keepParent "MeDFLIstvanEditor.app" "MeDFLIstvan-v2.0-macOS-arm64.zip"

Anschließend wurde das Archiv noch einmal komplett getestet:

• ZIP erstellen
  

• Originale App entfernen
  

• ZIP entpacken
  

• Direkt aus dem Finder starten
  

Erst nachdem dieser komplette Test erfolgreich war, ging das Release zurück an die Entwickler.

Das Ende einer ziemlich verrückten Reise

Was ursprünglich als kleiner Funktionstest gedacht war, entwickelte sich zu einer echten Zusammenarbeit zwischen Deutschland und Ungarn.

Gemeinsam wurden Build-Skripte verbessert, Java-Probleme analysiert, ARM64 getestet und schließlich ein sauber funktionierendes macOS-Release erstellt.

Besonders gefreut hat mich dabei der Austausch mit Csio. Während wir zunächst ausschließlich auf Englisch schrieben, stellte sich irgendwann heraus, dass er seit einigen Jahren in Deutschland lebt, ebenfalls im Krankenhaus arbeitet und gerade seine Ausbildung zum Pflegeassistenten abschließt.

Die Welt ist manchmal wirklich erstaunlich klein.

Am Ende funktionierte alles:

• Native ARM64-App
  

• Eigenes Icon
  

• Kein Rosetta mehr
  

• Start direkt aus dem Finder
  

• Sauberes Release-Paket
  

Eine dieser Geschichten, die zeigen, dass Open-Source-Projekte oft genau davon leben: Menschen aus völlig unterschiedlichen Bereichen arbeiten gemeinsam an einem Problem, lernen voneinander – und haben dabei erstaunlich viel Spaß.