CSD Portfolio 2026.1.1 auf macOS 27 nutzbar? Abnahme-Checkliste für Hochschulen 2026

Symptom: CSD Portfolio startet auf macOS 27, aber niemand weiß, ob der Laborablauf damit freigegeben ist.
Schnellste Lösung: Die offizielle CCDC-Liste nennt macOS 27 bislang nicht; migrieren Sie daher nicht allein aufgrund eines erfolgreichen Starts, sondern prüfen Sie Ihre repräsentativen Abläufe isoliert und warten Sie für die reguläre Freigabe auf aktualisierte Support-Angaben.

Dieser Leitfaden ist für Sie gedacht, wenn Sie in einer Hochschulgruppe mit Mercury, ConQuest oder der CSD Python API arbeiten.
Auch wenn Sie Softwareumgebungen im Labor betreuen, finden Sie hier Prüfpunkte für eine nachvollziehbare Abnahme statt einer Vermutung aus einem kurzen Starttest.

Zuletzt aktualisiert am 30.09.2026; abgeglichen mit den CCDC-Support- und Installationsangaben sowie den Apple-Entwicklerhinweisen. Apple führt macOS 27.0.1 in den Entwicklerhinweisen vom 28.09.2026 auf; für die CSD Portfolio-Freigabe ist jedoch die CCDC-Kompatibilitätsangabe maßgeblich, nicht allein die Veröffentlichung des Betriebssystems (Apple Developer: macOS-27-Veröffentlichungen, CCDC: macOS-Unterstützung).

SECTION 01Die Grenze zwischen Start und Freigabe

Nach der derzeit herangezogenen CCDC-Supportseite sind macOS 14, 15 und 26 als unterstützte Systemversionen aufgeführt. macOS 27 erscheint dort nicht. CCDC erklärt außerdem, dass für CSD Portfolio 2026.1.1 ein Universal-Binary für Macs mit M-Series-Prozessoren entwickelt wurde; ConQuest wird in dieser Version weiterhin über Rosetta übersetzt ausgeführt (CCDC: macOS-Unterstützung).

Diese Aussagen beantworten unterschiedliche Fragen. Ein Programm kann sich installieren oder öffnen lassen, ohne dass seine Version für das Betriebssystem offiziell unterstützt wird. Und selbst eine offizielle Systemfreigabe sagt nicht automatisch, dass die Dateien, Skripte, Plugins, Lizenzwege und konkreten Ausgabeschritte Ihrer Arbeitsgruppe unverändert funktionieren.

Für Ihre Abnahme sind deshalb drei Zustände auseinanderzuhalten:

Startfähig: Die Anwendung öffnet sich in Ihrer konkreten Testumgebung. Das ist ein technischer Anfangsbefund, keine Freigabe.
Offiziell unterstützt: Das Betriebssystem und die betreffende Softwareversion sind in den CCDC-Angaben ausdrücklich aufgeführt.
Für Ihren Arbeitsablauf abgenommen: Die für Ihre Gruppe wichtigen Eingaben, Übergaben, Ausgaben und Lizenzbedingungen sind mit dokumentierten Testfällen geprüft.

Die Unterscheidung ist besonders wichtig, wenn laufende Projekte reproduzierbare Ergebnisse voraussetzen. Ein erfolgreicher Start kann Fehler bei CIF-Dateien, Exporten oder der Kommunikation zwischen ConQuest und Mercury nicht ausschließen. Ebenso ersetzt eine offizielle Kompatibilitätsangabe nicht die Prüfung Ihrer konkreten Laborumgebung.

Halten Sie deshalb vor Beginn die verwendete Betriebssystemversion, CSD-Portfolio-Version, Installationsquelle, Architektur und den Zustand der Testdateien fest. Bei einer späteren Abweichung können Sie so unterscheiden, ob ein Ergebnis durch ein Systemupdate, eine geänderte Softwareversion oder eine veränderte Projektumgebung entstanden ist.

SECTION 02Mercury: Strukturansicht und Ausgabe prüfen

Der erste praktische Prüfpunkt ist nicht, ob Mercury ein Fenster öffnet, sondern ob es eine typische Strukturaufgabe aus Ihrer Gruppe korrekt erledigt. Wählen Sie dafür eine repräsentative CIF-Datei, die keine vertraulichen oder personenbezogenen Informationen enthält. Verwenden Sie für den Vergleich eine vorhandene Laborinstallation oder ein archiviertes, nachvollziehbares Referenzergebnis.

Arbeiten Sie den Test in dieser Reihenfolge ab:

Öffnen Sie die Testdatei und prüfen Sie, ob die erwarteten Atome, Bindungen und Struktureinheiten vorhanden sind.
Kontrollieren Sie die dreidimensionale Darstellung aus den Blickwinkeln, die Sie bei der Interpretation oder Kommunikation Ihrer Ergebnisse tatsächlich benötigen.
Führen Sie die für Ihren Ablauf relevanten Strukturoperationen aus, zum Beispiel das Ändern der Ansicht oder die Bearbeitung der Darstellung.
Exportieren Sie eine Abbildung und öffnen Sie die exportierte Datei unabhängig von Mercury.
Vergleichen Sie Inhalt, Beschriftungen, Ausschnitt und Darstellung mit der Referenz. Bewahren Sie Originaldatei, Export und Prüfnotiz zusammen auf.

Der letzte Schritt wird leicht übersehen: Eine korrekte Ansicht im Anwendungsfenster beweist nicht, dass der Export für eine Publikation, ein Laborprotokoll oder eine spätere Projektübergabe geeignet ist. Prüfen Sie die tatsächlich gespeicherte Datei und nicht nur die Vorschau. Wenn in Ihrer Gruppe bestimmte Darstellungsoptionen, Farben oder Beschriftungen vorgeschrieben sind, gehören sie in den Testfall.

Dokumentieren Sie Abweichungen konkret. „Sieht anders aus“ hilft später wenig; hilfreicher ist etwa, festzuhalten, welche Ansicht, Beschriftung oder gespeicherte Datei von der bekannten Referenz abweicht. Ein nicht reproduzierbarer Export sollte die Freigabe des betreffenden Arbeitsablaufs stoppen, selbst wenn andere Mercury-Funktionen zunächst unauffällig erscheinen.

SECTION 03ConQuest und Mercury: Ergebnisübergabe getrennt abnehmen

ConQuest verdient einen eigenen Test, weil die CCDC-Angaben die Architekturbehandlung nicht für alle Komponenten gleich beschreiben: Das Universal-Binary für M-Series-Macs bedeutet nicht, dass ConQuest in CSD Portfolio 2026.1.1 ohne Übersetzung läuft. Laut CCDC wird ConQuest weiterhin über Rosetta ausgeführt (CCDC: macOS-Unterstützung).

Legen Sie eine Suchaufgabe fest, deren erwartete Treffer Sie anhand eines vorhandenen Arbeitsablaufs kontrollieren können. Prüfen Sie zuerst, ob ConQuest die Suche wie vorgesehen ausführt und die Treffer in der Oberfläche nachvollziehbar anzeigt. Danach testen Sie die Weitergabe an Mercury und schließlich den Inhalt der daraus erzeugten Dateien. Die offizielle CCDC-Anleitung zur Übertragung von ConQuest-Suchergebnissen an Mercury beschreibt den vorgesehenen Exportweg (CCDC: Suchdaten aus ConQuest an Mercury übergeben).

Behandeln Sie die Prüfung als drei getrennte Beobachtungen:

Suchergebnis: Sind die erwarteten Treffer sichtbar und lassen sie sich in Ihrer Arbeitsweise auswählen?
Übergabe: Wird die Weitergabe an Mercury abgeschlossen, und zeigt die Zielanwendung die übermittelten Strukturen an?
Ergebnisdatei: Enthält die gespeicherte Datei die erwarteten Inhalte und kann sie im nächsten Arbeitsschritt wieder geöffnet werden?

Eine einzelne Wartezeit ist kein allgemeiner Leistungswert. Wenn Sie sie festhalten, notieren Sie die konkreten Bedingungen Ihres Versuchs, etwa die verwendete Suche, den Zustand des Netzwerks und die Testumgebung. Vergleichen Sie nur gleichartige Läufe und verwenden Sie das Ergebnis nicht als pauschale Aussage darüber, wie schnell ConQuest auf anderen Macs oder mit anderen Daten arbeitet.

Scheitert die Übergabe, obwohl Suche und Anzeige funktionieren, markieren Sie den Ablauf als nicht abgenommen und sichern Sie Fehlermeldung sowie Zwischenergebnisse. So bleibt sichtbar, an welcher Stufe der Fehler auftritt. Starten Sie nicht sofort eine Migration der Laborgeräte, nur weil die Suche selbst bereits erfolgreich war.

SECTION 04Python API, Lizenz und Netzwerk

Ein Desktop-Test deckt die CSD Python API nicht mit ab. Prüfen Sie deshalb, ob Ihr Projekt die API tatsächlich verwendet und welche Installationsmethode, Python-Umgebung und CSD-Portfolio-Version dafür vorgesehen sind. Die CCDC-Installationshinweise beschreiben die Voraussetzungen und Installationswege der API; richten Sie Ihren Test an diesen Angaben aus, statt eine zufällig vorhandene Python-Installation als gleichwertig anzunehmen (CCDC: Installationshinweise zur CSD Python API).

Führen Sie zunächst einen minimalen Aufruf mit einer öffentlichen oder vollständig anonymisierten Beispieldatei aus. Notieren Sie den verwendeten Interpreter und die relevanten Pakete. Wenn Ihr Projekt externe Pakete, eine bestimmte Prozessorarchitektur oder historische Abhängigkeiten benötigt, testen Sie diese Bedingungen separat. Ein erfolgreicher Aufruf eines Minimalbeispiels belegt nicht, dass ein komplexer Analyseablauf mit allen Projektabhängigkeiten läuft.

Prüfen Sie auch die Lizenzbedingungen getrennt von der technischen Erreichbarkeit. Die CCDC-Unterlagen zur Lizenzierung erklären die verfügbaren Lizenzwege; die Netzwerkdokumentation nennt Verbindungen, die für Desktopsoftware und Online-Aktivierung erforderlich sein können (CCDC: Lizenzierungssystem, CCDC: erforderliche Netzwerkverbindungen). Ein Mac kann also technisch erreichbar sein, während der vorgesehene Lizenzweg für Ihr Konto oder die institutionelle Umgebung nicht funktioniert.

Für Hochschulgruppen sollten Sie vor der Abnahme mit der zuständigen Lizenzverwaltung klären, ob die geplante Nutzung durch die vorhandene institutionelle Vereinbarung gedeckt ist. Dieser Leitfaden bewertet keine rechtliche Anspruchsberechtigung und ersetzt keine Prüfung der Lizenzbedingungen. Dokumentieren Sie stattdessen, welches Konto den Start durchgeführt hat, ob die Aktivierung abgeschlossen wurde und ob die Arbeitsgruppe den vorgesehenen Lizenzweg nutzen darf.

Berücksichtigen Sie bei Remote- oder gemeinsam genutzten Umgebungen außerdem Datenschutz und Zugriffskontrolle. Verwenden Sie für Kompatibilitätstests zunächst keine unveröffentlichten Strukturdaten, wenn deren Speicherung oder Verarbeitung außerhalb der freigegebenen Laborinfrastruktur nicht geklärt ist. Eine funktionierende Verbindung über Fernzugriff beweist weder, dass die Datenverarbeitung Ihrer institutionellen Datenschutzvorgabe entspricht, noch dass die Lizenz eine bestimmte Nutzung erlaubt.

SECTION 05Häufige Fragen zur Abnahme

FAQ

Ist macOS 27 für CSD Portfolio 2026.1.1 offiziell freigegeben?
Die herangezogene CCDC-Supportseite nennt macOS 14, 15 und 26, aber nicht macOS 27. Daraus folgt nicht, dass die Software unter macOS 27 sicher nicht startet; die Liste bietet jedoch keine Grundlage, das System als offiziell unterstützt zu behandeln. Prüfen Sie die CCDC-Angaben unmittelbar vor der Migration erneut.

Welche Komponenten müssen Sie auf einem M-Series-Mac einzeln prüfen?
Prüfen Sie Mercury, ConQuest, die Übergabe von Suchergebnissen und die CSD Python API als getrennte Aufgaben. CCDC beschreibt für CSD Portfolio 2026.1.1 ein Universal-Binary für M-Series-Macs, weist aber zugleich darauf hin, dass ConQuest weiterhin über Rosetta ausgeführt wird. Deshalb ist ein erfolgreicher Test einer Komponente kein Beleg für die übrigen Abläufe.

Wie weisen Sie die Strukturansicht und den Export in Mercury nach?
Öffnen Sie eine repräsentative CIF-Datei, kontrollieren Sie die benötigte dreidimensionale Ansicht und führen Sie die in Ihrer Gruppe üblichen Strukturoperationen aus. Exportieren Sie anschließend eine Abbildung und prüfen Sie die gespeicherte Datei gegen eine Referenz. Erst damit erfassen Sie nicht nur die Darstellung in der Oberfläche, sondern auch den tatsächlich weiterverwendeten Output.

Wie kontrollieren Sie die Übergabe von ConQuest an Mercury?
Prüfen Sie die Trefferanzeige, den Abschluss der Datenübergabe und die resultierende Datei getrennt. Die CCDC-Anleitung zum Export beschreibt den vorgesehenen Weg, ersetzt aber nicht den Test mit Ihrer Suchaufgabe und Ihren Folgewerkzeugen. Halten Sie eventuelle Verzögerungen als Beobachtung der konkreten Testumgebung fest, nicht als allgemeine Leistungsangabe.

SECTION 06Abnahmeplan und Entscheidung

Verwenden Sie für Ihre Freigabe einen dokumentierten Testlauf, statt Einzelbeobachtungen zu einer pauschalen Aussage zusammenzufassen. Die offiziellen Systemanforderungen und Plattformangaben der CCDC sind dabei die Referenz für die Supportgrenze; die Liste nennt unterstützte Plattformen und Anforderungen, ersetzt aber keine Prüfung Ihres konkreten Workflows (CCDC: Systemanforderungen und unterstützte Plattformen).

Ausgangslage sichern: Notieren Sie Systemversion, CSD-Portfolio-Version, Installationsquelle, Mac-Architektur und relevante Laboranwendungen. Sichern Sie außerdem die vorhandenen Referenzdateien, ohne vertrauliche Proben unnötig zu kopieren.
Testdaten festlegen: Wählen Sie eine repräsentative CIF-Datei, eine reproduzierbare ConQuest-Suche und ein minimales API-Beispiel. Legen Sie vorab fest, welche Ergebnisse Sie jeweils erwarten.
Komponenten getrennt ausführen: Testen Sie Mercury, ConQuest, die Datenübergabe und die Python API einzeln. Notieren Sie Fehlermeldungen und Umgebungsbedingungen, damit ein Fehler der richtigen Komponente zugeordnet werden kann.
Ausgaben prüfen: Vergleichen Sie die Strukturansicht und exportierten Dateien mit Ihrer Referenz. Kontrollieren Sie zusätzlich, ob die übergebenen Suchdaten im Folgeprogramm und in den gespeicherten Ergebnissen vollständig ankommen.
Lizenz und Netzwerk bestätigen: Prüfen Sie den tatsächlichen Aktivierungs- und Startweg mit dem für die Arbeitsgruppe vorgesehenen Konto und Netzwerk. Lassen Sie institutionelle Nutzungsrechte von der zuständigen Stelle bestätigen.
Freigabe dokumentieren: Halten Sie fest, welche Abläufe bestanden haben, welche nicht geprüft wurden und welche Abweichungen bestehen. Verknüpfen Sie die Entscheidung mit der konkreten getesteten Umgebung und nicht mit einer allgemeinen Behauptung zur Software.

Prüfliste für die Abnahme

Kreuzen Sie einen Punkt erst an, wenn der Nachweis für Ihre konkrete Testumgebung vorliegt. Ein offenes Kästchen bedeutet, dass der betreffende Ablauf noch nicht freigegeben ist.

[ ] Supportstatus geprüft: Die aktuelle CCDC-Seite wurde unmittelbar vor der Entscheidung geprüft; macOS 27 ist entweder ausdrücklich aufgeführt oder weiterhin als nicht gelistet dokumentiert.
[ ] Testumgebung erfasst: Systemversion, CSD-Portfolio-Version, Installationsquelle und Mac-Architektur sind nachvollziehbar notiert.
[ ] Mercury geprüft: Eine repräsentative CIF-Datei wurde geöffnet, dreidimensional dargestellt und bearbeitet; der gespeicherte Export wurde gegen eine Referenz geprüft.
[ ] ConQuest geprüft: Eine festgelegte Suche wurde ausgeführt; Trefferanzeige, Übergabe an Mercury und resultierende Datei wurden jeweils kontrolliert.
[ ] Python API geprüft: Interpreter, Installationsweg und benötigte Abhängigkeiten sind festgehalten; ein minimales Beispiel wurde erfolgreich ausgeführt oder der Fehler dokumentiert.
[ ] Lizenz und Netzwerk geprüft: Aktivierung und Start wurden mit dem vorgesehenen Konto und Netzwerk getestet; die institutionelle Nutzung wurde intern geklärt.
[ ] Datenverarbeitung geklärt: Testdateien sind für die verwendete Umgebung freigegeben oder vollständig anonymisiert; Zugriff und Speicherung entsprechen den Vorgaben Ihrer Institution.
[ ] Abweichungen behandelt: Fehlermeldungen und nicht bestandene Aufgaben sind dokumentiert; ungelöste Punkte verhindern die reguläre Freigabe.

Treffen Sie die Entscheidung anhand dieser Bedingungen:

Wenn CCDC macOS 27 inzwischen ausdrücklich als unterstützt aufführt und Ihre repräsentativen Workflows, Lizenz und Netzwerkbedingungen bestanden sind, dann können Sie eine kontrollierte Migration für die geprüfte Umgebung planen.
Wenn die offizielle Liste macOS 27 weiterhin nicht aufführt, Ihre Testumgebung aber die erforderlichen Abläufe abbildet, dann verwenden Sie die Umgebung zunächst nur zur isolierten Validierung und holen Sie vor einer regulären Freigabe eine aktualisierte offizielle Aussage ein.
Wenn ConQuest-Übergabe, Python API, Ergebnisexport oder Lizenzaktivierung scheitern oder ungeklärt bleiben, dann verschieben Sie die Migration der Arbeitsumgebung und führen Sie die Analyse vorerst in der bereits freigegebenen Umgebung aus.
Wenn Sie weder eine sichere Testumgebung noch eine geeignete Referenz haben, dann ist ein einzelner erfolgreicher Programmstart kein ausreichender Abnahmenachweis.

Diese Bedingungen verhindern zwei gegensätzliche Fehlentscheidungen: eine vorschnelle Freigabe aufgrund eines Starttests und eine pauschale Behauptung, CSD Portfolio könne auf macOS 27 grundsätzlich nicht ausgeführt werden. Die verfügbaren offiziellen Informationen belegen weder eine macOS-27-Freigabe noch eine generelle Unmöglichkeit des Starts.

SECTION 07Remote-Test oder Migration der Laborumgebung

Wenn Ihr Labor bislang nur Windows- oder Linux-Arbeitsplätze bereitstellt, müssen Sie nicht sofort einen neuen Mac kaufen, um eine isolierte macOS-Prüfung vorzubereiten. Ein Remote-Mac kann für einen zeitlich begrenzten Abnahmelauf sinnvoll sein, sofern Sie vorab klären, wie Sie darauf zugreifen, welche Daten Sie verwenden dürfen und ob Ihre institutionelle Lizenz den geplanten Einsatz abdeckt. Informationen zur Remote-Mac-Umgebung von MACNOX können Ihnen helfen, die technische Bereitstellung als separate Frage zur Softwarefreigabe zu betrachten.

Die Alternativen haben unterschiedliche Grenzen. Ein vorhandener Laborrechner spart eine zusätzliche Bereitstellung, bindet den Test aber an die bereits installierte Umgebung und kann eine isolierte Systemprüfung erschweren. Ein neu gekaufter Mac bietet lokale Kontrolle, verursacht jedoch Anschaffungskosten und ist für eine kurzfristige Kompatibilitätsprüfung möglicherweise nicht die passende Investition. Ein Remote-Mac lässt sich zeitlich begrenzt für Tests nutzen, bringt aber Abhängigkeiten von Netzwerkzugriff, Datenfreigabe und Lizenzbedingungen mit sich. Keine dieser Optionen garantiert, dass CSD Portfolio 2026.1.1 unter macOS 27 offiziell unterstützt wird.

Für eine temporäre Abnahme können Sie zunächst prüfen, ob die MACNOX-Mietoptionen und Abrechnungsinformationen zu Ihrem Prüfzeitraum passen. Entscheidend ist, dass Sie vor dem Test die benötigte macOS-Version, den erlaubten Zugriff, die Übergabewege für Testdateien und die Verantwortlichkeit für die Lizenz klären. Wenn Ihre Gruppe dauerhaft rechenintensive Abläufe betreibt, physische Anschlüsse benötigt oder sensible Daten nicht in einer extern verwalteten Umgebung verarbeiten darf, ist eine lokale, institutionell betreute Lösung möglicherweise geeigneter.

Bis CCDC macOS 27 ausdrücklich aufführt, bleibt die belastbare Entscheidung: nicht allein wegen eines erfolgreichen Starts migrieren. Prüfen Sie Ihre Mercury-, ConQuest- und API-Abläufe in einer isolierten Umgebung, dokumentieren Sie offene Punkte und geben Sie die Laborumgebung erst frei, wenn Supportstatus, Arbeitsfluss und Lizenzweg zusammenpassen.