macOS Tahoe 26: Kompatibilitätstest für Forschungssoftware

Die vier Abnahmestufen müssen getrennt dokumentiert werden

Ein erfolgreicher Start beweist lediglich, dass ein Installationspfad und ein grundlegender Programmaufruf funktionieren. Für eine wissenschaftliche Freigabe reicht das nicht aus. Die Testakte sollte mindestens zwischen diesen vier Zuständen unterscheiden:

Vor dem ersten Test müssen deshalb ein Beispieldatensatz, ein erwartetes Ergebnis und konkrete Fehlerbedingungen festgelegt werden. „Das Fenster öffnet sich“ ist kein ausreichendes Akzeptanzkriterium. Ebenso darf „aktuelle Version“ nicht als Versionsangabe verwendet werden. In der Testakte stehen die exakte Version von macOS Tahoe 26, die Version der Forschungssoftware, die Compiler- oder Laufzeitversion sowie alle relevanten Bibliotheken.

Für ein Analysewerkzeug kann beispielsweise gelten: Der Test ist nur dann bestanden, wenn die Eingabedatei ohne manuelle Nachbearbeitung verarbeitet wird, alle erwarteten Ergebnisdateien entstehen, der Prozess mit einem erfolgreichen Exit-Code endet und die fachlich relevanten Kennwerte innerhalb der vom Softwarehersteller dokumentierten Toleranz liegen. Gibt es keine offizielle Toleranz, muss der Unterschied fachlich bewertet werden, statt eine beliebige Schwelle zu erfinden.

Erste Prüfachse: Architektur, Apple Silicon und Rosetta

macOS Tahoe 26 unterstützt eine Reihe von Intel- und Apple-Silicon-Macs. Apple weist zugleich darauf hin, dass Tahoe die letzte macOS-Version für Intel-basierte Macs ist. Rosetta bleibt als Übergangstechnologie relevant, ist aber kein Ersatz für eine native Apple-Silicon-Version. Die offizielle Dokumentation beschreibt Rosetta als Übersetzungsumgebung für x86_64-Anweisungen auf Apple Silicon und nicht als dauerhafte Lösung für eine native Portierung. (support.apple.com)

Die Architekturprüfung darf sich nicht auf das Hauptprogramm beschränken. Zu erfassen sind:

• grafische Hauptanwendung,
• Kommandozeilenprogramme,
• dynamische Bibliotheken,
• Plugins und Erweiterungen,
• Python-, R- oder C++-Module,
• externe Solver, Datenbanktreiber und Hilfsprogramme.

Wie lässt sich native Unterstützung für Apple Silicon prüfen?

Auf einem Test-Mac kann die Architektur eines Binärprogramms mit file und lipo ermittelt werden:

file /Pfad/zur/Anwendung.app/Contents/MacOS/Anwendung
lipo -info /Pfad/zur/Anwendung.app/Contents/MacOS/Anwendung

Ein möglicher Befund lautet:

Mach-O 64-bit executable arm64
Architectures in the fat file: Anwendung are: x86_64 arm64

arm64 weist auf eine Apple-Silicon-kompatible Binärdatei hin. x86_64 bedeutet, dass der betreffende Bestandteil für Intel kompiliert wurde und auf Apple Silicon möglicherweise Rosetta benötigt. Eine universelle Binärdatei enthält beide Architekturen. Dieser Befund muss für jedes kritische Teilprogramm einzeln gespeichert werden.

Besonders fehleranfällig ist eine gemischte Umgebung: Die Hauptanwendung läuft nativ, lädt aber ein Intel-Plugin nicht; ein Terminalprozess verwendet eine arm64-Python-Umgebung, während eine wissenschaftliche Bibliothek nur als x86_64 vorliegt; oder ein externer Solver wird über einen Pfad aufgerufen, der auf eine andere Architektur zeigt.

Ein Architekturtest ist daher erst vollständig, wenn die Testakte festhält:

1. Welche Komponenten nativ als arm64 laufen.
2. Welche Komponenten als universal vorliegen.
3. Welche Komponenten Rosetta benötigen.
4. Ob Rosetta automatisch installiert oder vom Testsystem ausgeschlossen wird.
5. Ob Fehler nur unter einer bestimmten Architektur auftreten.

Apple dokumentiert zusätzlich, dass macOS Tahoe 26.4 beim Start Rosetta-abhängiger Anwendungen auf die kommende Einschränkung hinweist. Für langfristig gepflegte Forschungssoftware sollte ein Rosetta-Abhängigkeit deshalb als technisches Risiko und nicht als „bestanden“ markiert werden. (developer.apple.com)

Zweite Prüfachse: Systemversion, Rechte und Abhängigkeiten

Eine erfolgreiche Installation ist nicht gleichbedeutend mit offizieller Unterstützung. In der Testakte müssen die Herstellerangaben der Forschungssoftware und die tatsächlich verwendete Version von macOS Tahoe 26 getrennt erfasst werden. Die Formulierung „läuft auf dem neuesten Mac-System“ genügt nicht als Nachweis.

Zu prüfen sind mindestens:

• deklarierte macOS-Versionen des Herstellers,
• Installationsformat, etwa Paketinstaller, Anwendungspaket oder Kommandozeilenarchiv,
• erforderliche Laufzeiten und Bibliotheken,
• Dateisystem- und Verzeichnisrechte,
• Zugriff auf geschützte Ordner,
• Zugriff auf Netzwerkfreigaben,
• Verhalten bei der ersten Ausführung,
• Verhalten nach einem Neustart,
• Hintergrundprozesse und geplante Aufgaben.

Ein reproduzierbarer Nachweis kann beispielsweise so aussehen:

sw_vers
uname -m
which python3
python3 --version
python3 -c "import sys; print(sys.executable)"

Beispielausgabe:

ProductName:    macOS
ProductVersion: 26.x
BuildVersion:   25xxxx
arm64
/opt/.../bin/python3
Python 3.x.x

Die konkreten Werte müssen aus dem jeweiligen Testlauf übernommen werden. Sie dürfen nicht durch allgemeine Angaben wie „neues macOS“ ersetzt werden.

Wird eine Anwendung von macOS blockiert, sollte die ursprüngliche Meldung unverändert dokumentiert werden. Ein Sicherheitshinweis, eine fehlende Berechtigung und eine beschädigte Bibliothek haben unterschiedliche Ursachen. Das pauschale Deaktivieren von Sicherheitsfunktionen verschlechtert die Aussagekraft der Abnahme und kann gegen die Datenschutz- oder Sicherheitsvorgaben einer Hochschule verstoßen.

Datenschutz ist bei Forschungsdaten besonders wichtig. Vor der Übertragung auf eine Remote-Umgebung müssen personenbezogene oder vertrauliche Daten minimiert, pseudonymisiert oder durch synthetische Testdaten ersetzt werden. Die Testakte sollte außerdem vermerken, wo Eingabedaten, Logs und Ergebnisdateien gespeichert werden und wer Zugriff auf die Umgebung besitzt.

Dritte Prüfachse: Rechenergebnisse und wissenschaftliche Reproduzierbarkeit

Der zentrale Prüfpunkt einer Forschungssoftware ist nicht die Benutzeroberfläche, sondern die fachliche Verlässlichkeit der Ergebnisse. Ein identischer Workflow sollte deshalb mit demselben Eingabedatensatz unter Linux oder Windows und unter macOS Tahoe 26 ausgeführt werden, sofern beide Umgebungen Teil des geplanten Einsatzes sind.

Die Vergleichsprüfung umfasst:

• identische Eingabedateien,
• identische Konfigurationsdateien,
• identische Zufallsparameter oder Seeds,
• identische Datenbank- und Referenzstände,
• identische Verarbeitungsschritte,
• vollständige Logs,
• erzeugte Ergebnisdateien,
• Exit-Codes und Warnungen.

Besonders relevant sind Floating-Point-Abweichungen, unterschiedliche Bibliotheksimplementierungen und parallelisierte Berechnungen. Kleine numerische Unterschiede können technisch normal sein. Ob sie fachlich akzeptabel sind, hängt jedoch vom Verfahren ab. Bei einer Bildanalyse, Simulation oder statistischen Auswertung kann eine scheinbar kleine Abweichung eine andere Schlussfolgerung auslösen.

Daher sollte der Ablauf nicht nur mit einem abschließenden Hash verglichen werden. Sinnvoller ist eine gestufte Prüfung:

1. Stimmen Dateinamen, Dateiformate und Datensatzgrößen überein?
2. Sind zentrale Zwischenwerte und Stichproben identisch oder erklärbar abweichend?
3. Bleiben statistische oder wissenschaftliche Entscheidungen unverändert?
4. Sind Warnungen und Rundungsfehler dokumentiert?
5. Ist die Abweichung durch eine offizielle Software- oder Bibliotheksdokumentation erklärbar?

Für die spätere Wiederholung werden mindestens die Lock-Datei der Abhängigkeiten, die exakten Startbefehle, die Versionsinformationen und die Testdaten-ID archiviert. Bei Python, R oder C/C++ kann zusätzlich die verwendete virtuelle Umgebung, das Build-Protokoll oder die Compilerkonfiguration entscheidend sein.

Wie werden plattformübergreifend abweichende Ergebnisse eingegrenzt?

Zuerst wird der Ablauf in kleine Abschnitte zerlegt. Wenn die Rohdaten bereits nach dem Import voneinander abweichen, liegt die Ursache wahrscheinlich bei Dateiformat, Zeichensatz, Bibliothek oder Eingabebehandlung. Stimmen die Rohdaten überein, aber die späteren Modell- oder Statistikwerte nicht, müssen numerische Bibliotheken, Parallelisierung, Compilerflags und Zufallsquellen untersucht werden.

Ein nützlicher Nachweis ist ein minimierter Testfall:

./analyse \
  --input testdaten/kleiner_fall \
  --config config/reproduzierbar.yml \
  --seed 12345 \
  --log logs/macos-tahoe-26.txt
echo $?

Der Befehl selbst ist kein Beweis. Erst die Kombination aus Eingabe, Konfiguration, Log, Exit-Code und Ergebnisvergleich macht ihn prüfbar.

Vierte Prüfachse: Grafische Interaktion, Terminal und Remote-Zugriff

Ein lokaler Fensterstart sagt wenig über eine realistische Nutzung im Labor aus. Bei einer Remote-Abnahme müssen zusätzlich Terminalzugriff, grafische Bedienung, Dateiübertragung, Zwischenablage und Wiederaufnahme nach einer Verbindungsunterbrechung geprüft werden.

Die praktische Prüfung sollte diese Fälle enthalten:

• Start der Anwendung über die grafische Oberfläche.
• Start und Überwachung eines Terminalprozesses.
• Upload eines Testdatensatzes.
• Download der Ergebnisdateien.
• Kopieren eines Befehls oder kleiner Textabschnitte.
• Trennung der Remote-Sitzung während eines laufenden Prozesses.
• Wiederverbindung und Prüfung des Prozessstatus.
• Neustart der Anwendung und erneuter Zugriff auf Projektdateien.

Netzwerklatenz und Softwarefehler müssen getrennt protokolliert werden. Verzögert sich nur die Bildschirmdarstellung, während der Prozess korrekt weiterläuft, liegt nicht automatisch ein Kompatibilitätsfehler vor. Bricht dagegen der wissenschaftliche Prozess bei einer Dateioperation oder einem Plugin-Aufruf ab, muss der Fehler dem Softwaretest zugeordnet werden.

Eine Remote-Umgebung ersetzt außerdem nicht jedes Laborgerät. Audiointerfaces, USB-Instrumente, spezielle Kameras, Messkarten und lokale Hardwarebeschleuniger können über eine entfernte Verbindung nicht gleichwertig verfügbar sein. Solche Funktionen werden entweder ausdrücklich als „nicht getestet“ markiert oder an einem physisch angeschlossenen Gerät validiert.

Für automatisierte Vorprüfungen kann GitHub Actions hilfreich sein. GitHub dokumentiert für macOS-26-Runner sowohl Intel- als auch arm64-Varianten; die verfügbaren Runner unterscheiden sich bei Architektur und Ressourcen. GitHub weist außerdem darauf hin, dass das Label -latest nicht zwingend die neueste vom Betriebssystemanbieter veröffentlichte Version meint. Ein CI-Lauf ist daher ein guter Filter für Build-, Paket- und Basistests, aber kein vollständiger Ersatz für die reale Abnahme. (docs.github.com)

Fünfte Prüfachse: Stabilität, Ressourcen und lange Aufgaben

Kurze Starttests erkennen keine Speicherzunahme, keinen Abbruch nach einer Netzwerktrennung und keine beschädigten Logs nach einem längeren Lauf. Für die Stabilitätsprüfung werden deshalb mindestens ein kurzer repräsentativer Test und ein längerer realitätsnaher Ablauf benötigt.

Zu dokumentieren sind:

• Beginn und Ende des Prozesses,
• verwendeter Datensatz,
• Prozessstatus,
• Fehlermeldungen,
• Log-Vollständigkeit,
• Verhalten bei Remote-Trennung,
• Verhalten nach einem Neustart,
• erzeugte Ergebnisdateien,
• Abweichungen zwischen Wiederholungsläufen.

Nicht belegte Geschwindigkeits- oder Laufzeitversprechen gehören nicht in die Abnahme. Werden Ressourcen verglichen, müssen Datensatz, Systemversion, Softwareversion und Testbedingungen identisch sein. Andernfalls lässt sich nicht erkennen, ob eine Änderung durch die Plattform, die Eingabedaten oder die Testumgebung verursacht wurde.

Entscheidungshilfe: Wann wird freigegeben?

Die folgende Bedingungsliste verhindert, dass ein einzelner erfolgreicher Test die gesamte Entscheidung dominiert:

• Wenn alle kritischen Komponenten nativ oder offiziell unterstützt laufen, die Ergebnisse fachlich übereinstimmen und Remote-Unterbrechungen beherrscht werden, dann kann die Version als „bestanden“ freigegeben werden.
• Wenn nur Rosetta, eine nicht offiziell bestätigte Bibliothek oder ein noch nicht validiertes Plugin betroffen ist, dann ist „bedingt bestanden“ angemessen; die Einschränkung muss im Freigabedokument sichtbar bleiben.
• Wenn Ergebnisse nicht reproduzierbar sind oder ein Kernschritt nur mit einer unsicheren Sicherheitsumgehung funktioniert, dann lautet die Entscheidung „vorerst nicht bestanden“.
• Wenn die Anwendung lediglich startet, aber noch keine Ergebnis- und Stabilitätsprüfung vorliegt, dann bleibt der Status „installierbar oder ausführbar“, nicht „kompatibel“.
• Wenn das Labor keinen geeigneten Mac besitzt, dann kann die Automatisierung die Vorauswahl übernehmen; die Endabnahme erfolgt anschließend auf einem echten Remote-Mac mit vollständigen Rechten.

Drei Tabellen für die eigentliche Testplanung

Die aktuelle Umgebung mit einer echten Mac-Abnahme vergleichen

Automatisierte macOS-Tests sind kosteneffizient, aber sie decken nicht jede reale Bedingung ab. Ein CI-Runner arbeitet meist in einer frischen, standardisierten Umgebung; lokale Zugriffsrechte, grafische Bedienung, Remote-Sitzungen, besondere Plugins und der Umgang mit laufenden Aufgaben können dadurch unberücksichtigt bleiben. Ein Labor ohne eigenen Mac bleibt außerdem von verfügbaren Runner-Labels und deren konkreter Systemkonfiguration abhängig.

Wenn eine Arbeitsgruppe dauerhaft umfangreiche Berechnungen ausführt, spezielle USB-Geräte benötigt oder eine langfristig kontrollierte Hardwarebasis aufbauen muss, kann ein eigener Mac die bessere Lösung sein. Für eine zeitlich begrenzte Tahoe-26-Abnahme ist der Kauf jedoch nicht zwingend der erste Schritt. Nach dem Aufbau der Mac-Arbeitsumgebung für Forschungs- und Entwicklungsaufgaben kann NodeMini eine echte Remote-Mac-Umgebung bereitstellen, in der Architektur, Abhängigkeiten, Ergebnisgleichheit und Wiederverbindung unter realen Bedingungen geprüft werden. Informationen zur möglichen Mac-Beschaffung als dauerhafte Alternative helfen bei der späteren Investitionsentscheidung.

Für die beschriebene Situation ist eine zeitlich begrenzte Miete besonders dann sinnvoll, wenn das Testfenster klar definiert ist, keine physische Laborhardware angeschlossen werden muss und die Abnahme mit vollständigen Rechten erfolgen soll. Vor einer langfristigen Anschaffung sollte die Forschungssoftware zuerst auf dem Zielsystem freigegeben werden. So wird nicht nur geprüft, ob macOS Tahoe 26 startet, sondern ob der wissenschaftliche Workflow unter dokumentierten Bedingungen tatsächlich belastbar bleibt.