MATLAB R2026b Prerelease sollte ausschließlich in einer isolierten Umgebung vorab abgenommen werden; die stabile Forschungsinstallation bleibt unangetastet. Wer keinen Apple-Silicon-Mac besitzt, kann dafür vorübergehend einen Remote Mac einsetzen und zuerst Lizenz, benötigte Toolboxes, MEX-Dateien sowie ein repräsentatives Projekt prüfen, bevor über eine Migration entschieden wird.

Dieser Leitfaden richtet sich an Studierende und Forschende, die mit MATLAB an einer Dissertation oder einem laufenden Projekt arbeiten und reproduzierbare Ergebnisse schützen müssen. Ebenfalls angesprochen sind Entwickler mit Simulink-Modellen oder eigenen Erweiterungen sowie Hochschuladministratoren, die eine gemeinsam genutzte Umgebung ohne freien Test-Mac verwalten.

Hinweis zum Stand der Informationen: Am 20.09.2026 wird R2026b auf der offiziellen Prerelease-Seite weiterhin als Vorschau geführt. Die aktuell genannten Anforderungen umfassen macOS Tahoe 26, macOS Sequoia 15 sowie Macs mit Apple-A- oder M-Serie. Eine endgültige Veröffentlichung, finale Systemanforderung oder abschließende Fehlerbehebung darf daraus nicht abgeleitet werden. Die Angaben sollten vor jedem neuen Test anhand der offiziellen R2026b-Prerelease-Anforderungen erneut geprüft werden.

Entscheidung vor dem Zugriff

Eine Prerelease lohnt sich nicht automatisch für jedes Forschungsteam. Der Aufwand ist sinnvoll, wenn ein Projekt von einer neuen macOS-Version, einer Apple-Silicon-Umgebung, einer geänderten Toolbox oder einer eigenen Erweiterung betroffen sein könnte. Für eine bereits laufende Publikation ohne konkreten Kompatibilitätsdruck ist es dagegen meist sicherer, die stabile Umgebung weiterzuführen und nur einen abgeschirmten Test zu planen.

Vor der Reservierung eines Remote Mac sollte die Projektleitung vier Fragen schriftlich beantworten:

  • Welche MATLAB-Produkte werden im laufenden Projekt tatsächlich aufgerufen?
  • Gibt es eigene MEX-Dateien, externe Toolboxes, Compiler-Abhängigkeiten oder Geräteanbindungen?
  • Welches Ergebnis aus der stabilen Version dient als Referenz?
  • Wer entscheidet, ob ein Unterschied ein Fehler, eine Abhängigkeit oder ein erwartbares Verhalten ist?
Option Geeignet, wenn Vorteil Kritische Grenze
Bestehende stabile Umgebung Eine Publikation läuft und kein konkreter Upgrade-Druck besteht Höchste Vergleichbarkeit mit dem bisherigen Ablauf Keine frühe Erkenntnis über spätere Inkompatibilitäten
Separater lokaler Apple-Silicon-Mac Die Hochschule besitzt freie Testhardware und darf sie isoliert verwenden Direkter Zugriff auf lokale Dateien und Geräte Beschaffung, Administration und Datenschutz müssen selbst gelöst werden
Zeitlich begrenzter Remote Mac Kein eigener Apple-Silicon-Mac verfügbar ist und Softwarekompatibilität geprüft werden soll Getrennte Testumgebung ohne Kauf eines Geräts Physische Instrumente und lokale Messhardware sind nicht automatisch verfügbar
Prerelease als produktive Installation Nur scheinbar bequem, aber für laufende Forschungsarbeit riskant Kein zusätzlicher Installationsaufwand Nicht vertretbar als allgemeine Freigabe, solange Status und Fehlerlage vorläufig sind

Ein Remote Mac passt damit vor allem zu einer klar begrenzten Abnahme. Die aktuelle Arbeitsumgebung bleibt Referenz; die Vorschau dient der Risikoerkennung, nicht der sofortigen Ablösung.

Apple-Silicon-Baseline

Die erste technische Prüfung beginnt nicht mit einem großen Toolbox-Download, sondern mit der Identität der Testumgebung. Auf einem Remote Mac sollte die zuständige Person die Architektur, die macOS-Version, die Zugriffsrechte, den verfügbaren Speicher und die Lizenzart protokollieren. Die offiziellen Prerelease-Anforderungen nennen derzeit macOS Tahoe 26 und macOS Sequoia 15 sowie Apple-A- oder M-Serie; daraus folgt jedoch nicht, dass jede Kombination aus Betriebssystem, Lizenz und Produkt automatisch für das konkrete Projekt genügt.

Eine kurze Baseline kann beispielsweise folgende Informationen enthalten:

uname -m
sw_vers

Die Befehle liefern die Architektur und die installierte macOS-Version. Zusätzlich wird innerhalb von MATLAB geprüft, ob die erwartete Sitzung startet und welche Produkte verfügbar sind. Die Kommandos ersetzen keine offizielle Kompatibilitätsprüfung, helfen aber dabei, eine spätere Abweichung auf dieselbe Ausgangslage zurückzuführen.

Baseline-Punkt Nachweis Entscheidung bei Abweichung
Prozessorarchitektur Systembericht oder uname -m Test pausieren, wenn keine unterstützte Apple-A- oder M-Serie vorliegt
macOS-Version sw_vers und Systeminformationen Offizielle Prerelease-Seite erneut prüfen
MATLAB-Release Startdialog und Installationspfad Keine gemeinsame Installation mit der stabilen Version verwenden
Lizenzstatus Aktivierung oder Lizenzprüfung Vor Projektimport klären, ob die Nutzung berechtigt ist
Produkte und Toolboxes Installationsübersicht und Projektabhängigkeiten Nur tatsächlich benötigte Komponenten zuerst installieren
Datenzugriff Getrennte Projektkopie und definierter Speicherort Keine Originaldaten in eine unklare Testumgebung übertragen

Für die Installation sollten R2026b Prerelease und die stabile Version getrennte Installationsverzeichnisse, Benutzerkonfigurationen und Projektkopien erhalten. Hinweise zur parallelen Installation mehrerer Versionen stehen in der offiziellen Dokumentation zu mehreren MATLAB-Versionen. Die Testkopie sollte aus bereinigten oder anonymisierten Daten bestehen; personenbezogene Forschungsdaten gehören nicht ungeprüft auf einen extern verwalteten Rechner.

Erste Sitzung und Minimalinstallation

Der erste Durchlauf muss klein bleiben. Werden sofort alle verfügbaren Produkte, externe Erweiterungen und persönliche Einstellungen übernommen, ist eine spätere Fehlersuche unnötig schwer. Ziel der ersten Sitzung ist lediglich ein belastbarer Start- und Aktivierungsnachweis.

Schritt 1: Berechtigung vor Download prüfen

Die Forschungsgruppe klärt, ob die eigene Hochschul- oder Campuslizenz die Prerelease-Nutzung abdeckt. Ein erfolgreicher Download ist kein Beweis für eine erlaubte Nutzung. Die offiziellen Installations- und Lizenzhinweise beschreiben die grundlegenden Abläufe für Installation, Anmeldung und Lizenzverwaltung.

Wenn die Lizenzprüfung nicht eindeutig ist, wird der Test an dieser Stelle gestoppt. Eine Installation ohne geklärte Berechtigung erzeugt später keine verwertbare technische Aussage.

Schritt 2: Isolierten Installationspfad festlegen

Die Prerelease erhält ein eigenes Verzeichnis. Persönliche Pfade, Startdateien und Präferenzen werden nicht aus der stabilen Installation kopiert, solange nicht dokumentiert ist, welche Auswirkungen sie haben. Die Projektkopie wird ebenfalls unter einem klaren Namen abgelegt, der Release und Testdatum erkennen lässt.

Schritt 3: Nur den Projektkern installieren

Zuerst werden MATLAB selbst und die Produkte installiert, die für den kleinsten reproduzierbaren Test erforderlich sind. Die vollständige Toolbox-Liste folgt erst, wenn Anmeldung, Aktivierung und Grundrechnung funktionieren. Für Offline- oder vorbereitete Installationsabläufe kann die Dokumentation zum Herunterladen ohne sofortige Installation relevant sein.

Schritt 4: Start, Java und Lizenzprüfung dokumentieren

Die Sitzung muss starten, ein minimales Skript ausführen und eine Logdatei speichern können. Zusätzlich wird notiert, ob die erwartete Java-Umgebung verfügbar ist, ob die Lizenz erfolgreich ausgecheckt wird und ob der Prozess auf Apple Silicon wie vorgesehen läuft. Bei einem Fehler werden Installations-, Aktivierungs- und Startprotokolle gesichert.

Schritt 5: Bei Fehlern nicht blind überschreiben

Scheitert die erste Sitzung, wird nicht wiederholt installiert, bis die ursprüngliche Ursache verschwunden ist. Zuerst werden Fehlermeldung, Zeitpunkt, Release, Architektur, Lizenzstatus und Logdatei gesichert. Danach wird nur eine einzelne Variable geändert. So bleibt nachvollziehbar, ob beispielsweise die Lizenz, ein Pfad, ein Produkt oder die Umgebung den Fehler verursacht.

Stoppregel: Wenn Aktivierung oder minimaler MATLAB-Start nicht reproduzierbar funktionieren, beginnt noch keine Projektmigration. Ein erfolgreich geöffnetes Fenster ohne verwertbare Logs ist kein ausreichender Abnahmenachweis.

Repräsentatives Projekt und Abnahmekriterien

Nach dem Minimaltest folgt ein einzelner, repräsentativer Arbeitsablauf. Geeignet ist beispielsweise eine anonymisierte Analyse aus einer Publikation, ein Simulink-Modell oder eine interne Forschungsanwendung, die typische Abhängigkeiten enthält. Ein künstliches „Hallo-Welt“-Skript reicht nicht aus, wenn das reale Projekt MEX-Dateien, externe Toolboxes oder komplexe Exporte verwendet.

Die Regression erfolgt in einer festen Reihenfolge:

  1. Projektkopie öffnen und relative sowie absolute Pfade kontrollieren.
  2. Benötigte Toolboxes und externe Erweiterungen aufrufen.
  3. Eingabedaten mit einer dokumentierten Referenzdatei verarbeiten.
  4. Eigene MEX-Dateien laden und deren Ausgabe prüfen.
  5. Grafiken, Tabellen und exportierte Dateien erzeugen.
  6. Referenzresultate aus der stabilen Version vergleichen.
  7. Logs, Warnungen und Unterschiede in einem Testprotokoll sammeln.

MEX-Dateien verdienen eine eigene Prüfung, weil sie native Komponenten und damit Architektur-, Compiler- oder Abhängigkeitsfragen einführen können. Die offizielle MEX-Dokumentation erklärt Aufbau und Verwendung; sie ersetzt jedoch nicht den Test der konkreten Datei im Forschungsprojekt.

Beim Vergleich darf das Team nicht nur auf die Laufzeit schauen. Wichtiger sind numerische Ergebnisse, Dimensionen, fehlende Werte, Konvergenz, Dateiformate und Visualisierungen. Eine veränderte Dauer ist zunächst eine Beobachtung, kein Beweis für einen Fehler. Abweichungen werden mindestens vier Kategorien zugeordnet:

  • Fehler im eigenen Code oder in einer Annahme über Pfade;
  • fehlende oder inkompatible Drittanbieterabhängigkeit;
  • bekannte Einschränkung der Prerelease;
  • noch nicht eingeordnetes Vorschauverhalten.

Für Projekte mit Versionsverwaltung sollte die Testkopie einen eigenen Branch oder ein klar markiertes Arbeitsverzeichnis erhalten. MATLAB-Projektdateien, Pfade und Verknüpfungen werden anhand der offiziellen Anleitung zur Verwaltung von Projektdateien geprüft. Änderungen an der produktiven Projektdefinition bleiben bis zum Abschluss der Abnahme ausgeschlossen.

Erste Testwoche und Daueraufgaben

Eine einmalige Desktop-Sitzung beantwortet nur die Frage, ob die Umgebung grundsätzlich startet. Für eine belastbare Migrationsentscheidung braucht die Gruppe zusätzlich einen kleinen Wochenplan:

  • Befehlszeilen- oder Batch-Ausführung ausführen;
  • einen längeren Analysejob starten und den Wiederanlauf dokumentieren;
  • Projektdateien zwischen berechtigten Mitarbeitenden austauschen;
  • einen kontrollierten Versionsverwaltungsablauf prüfen;
  • typische Ergebnisse erneut exportieren;
  • Warnungen und Abbrüche mit reproduzierbaren Eingaben erfassen.

Bei einem Remote Mac müssen außerdem Verbindung und Bedienmodell geprüft werden. VNC oder eine Webkonsole kann für grafische Arbeit geeignet sein, während SSH für Batch-Aufgaben besser passt. Die Abnahme sollte daher getrennt festhalten, ob GUI-Sitzung, Terminalzugriff und Wiederaufnahme nach einer getrennten Sitzung funktionieren. Ein Netzwerkabbruch darf nicht stillschweigend als MATLAB-Fehler eingeordnet werden.

GPU-Beschleunigung, Messgeräte, Spezialkarten und andere physisch angeschlossene Komponenten bilden eine eigene Grenze. Ein Remote Mac kann Softwarekompatibilität und viele Rechenabläufe prüfen, aber keine Aussage darüber liefern, ob ein lokales Instrument, ein Treiber oder ein bestimmter Anschluss im Labor funktioniert. Dieser Teil muss später auf der tatsächlichen Zielhardware abgenommen werden.

Für jede Störung werden mindestens folgende Informationen gesammelt:

  • genaue Release- und Systemangabe;
  • minimaler reproduzierbarer Ablauf;
  • anonymisiertes Eingabebeispiel;
  • erwartetes und tatsächliches Ergebnis;
  • Logdatei sowie Zeitpunkt des Auftretens;
  • Einschätzung, ob der Fehler blockierend oder umgehbar ist.

Die offiziellen Hinweise zu bekannten Prerelease-Problemen sollten während der Testwoche erneut gelesen werden. Ein dort beschriebener Fehler wird nicht als lokales Versagen des Forschungsteams verbucht; er bleibt aber für die Migrationsentscheidung relevant.

Ergebnisse, Rückkehr und Datenlöschung

Am Ende wird nicht einfach „kompatibel“ oder „inkompatibel“ notiert. Eine brauchbare Entscheidung unterscheidet drei Zustände:

  • Für die Vorbereitung geeignet: zentrale Projekte, Toolboxes und Referenzergebnisse bestehen die Abnahme; die formale Freigabe erfolgt trotzdem erst nach der stabilen Veröffentlichung und einer erneuten Prüfung.
  • Doppelbetrieb erforderlich: der Kern funktioniert, einzelne nicht zentrale Erweiterungen oder Arbeitsabläufe bleiben offen.
  • Migration vorerst blockiert: ein wichtiges Projekt, eine MEX-Datei, Lizenzkomponente oder Hardwareabhängigkeit scheitert.

Die stabile Version bleibt während dieses Prozesses unverändert. Für die Rückkehr werden zunächst Bericht, Umgebungsliste, Logs und notwendige Projektdateien exportiert. Danach löscht die zuständige Person aus der Testumgebung:

  • Lizenz- und Aktivierungsinformationen;
  • gespeicherte Zugangsdaten und Sitzungstoken;
  • Forschungsdaten und temporäre Kopien;
  • SSH-Schlüssel, API-Zugangsdaten und persönliche Konfigurationen;
  • nicht mehr benötigte Installations- und Logdateien.

Die Löschung sollte intern dokumentiert und mit den Datenschutzvorgaben der Hochschule, insbesondere den Anforderungen der DSGVO, abgeglichen werden. Bei einem gemieteten Remote Mac wird zusätzlich bestätigt, welche Daten nach Ende des Nutzungszeitraums entfernt wurden und ob die Arbeitsgruppe eigene Sicherungskopien besitzt.

Die manuelle MATLAB-Aktivierung ist besonders dann relevant, wenn die Umgebung nicht über den normalen Anmeldeweg aktiviert werden kann. Auch hier gilt: Aktivierungsdateien gehören nicht in ein öffentliches Projektarchiv und nicht in unbereinigte Supportpakete.

FAQ zur Prerelease-Abnahme

Geeignete Mac-Umgebung

Die aktuell bestätigte Prerelease-Anforderung umfasst macOS Tahoe 26, macOS Sequoia 15 und Apple-A- oder M-Serie. Vor dem Test müssen die konkrete Systemversion, Lizenz und benötigten Produkte zusätzlich geprüft werden. Eine unterstützte Architektur allein garantiert nicht, dass alle externen Toolboxes, MEX-Dateien oder Geräteabhängigkeiten funktionieren.

Test ohne eigenen Mac

Ohne eigene Hardware kann ein zeitlich begrenzter Remote Mac die Apple-Silicon-Prüfung ermöglichen. Dafür wird eine getrennte Installation mit anonymisierter Projektkopie verwendet. Dieser Weg eignet sich für Software- und Regressionsprüfungen, nicht jedoch als vollständiger Ersatz für Messgeräte, lokale Treiber oder andere physische Laboranschlüsse.

Öffnen bestehender Forschungsprojekte

Das direkte Öffnen der produktiven Projektdatei ist zu vermeiden. Stattdessen wird zuerst eine Kopie mit dokumentierten Pfaden und Referenzergebnissen geöffnet. Erst wenn Toolboxes, MEX-Dateien, Berechnungen, Grafiken und Exporte nachvollziehbar geprüft sind, kann die Gruppe eine mögliche Migration diskutieren.

Rückkehr zur stabilen Version

Eine Rückkehr gelingt zuverlässig, wenn Prerelease und stabile Version von Anfang an getrennt wurden. Nach dem Test werden Konten, Lizenzen, Daten und temporäre Dateien aus der Vorschauumgebung entfernt. Die stabile Installation bleibt mit ihrer eigenen Konfiguration erhalten und wird anhand eines bekannten Referenzlaufs erneut geprüft.

Priorität bei Toolboxes und MEX-Dateien

Zuerst werden alle Produkte geprüft, die das repräsentative Projekt tatsächlich verwendet. Danach folgen externe Toolboxes, eigene MEX-Dateien, Compilerabhängigkeiten sowie GPU- und Gerätepfade. Eine Toolbox, die nur installiert, aber im Projekt nicht aufgerufen wird, hat für die erste Entscheidung geringere Priorität als ein einzelnes MEX-Modul im zentralen Analyseweg.

Remote Mac als begrenzte Testressource

Wenn eine Hochschule keinen freien Apple-Silicon-Mac besitzt, ist eine periodisch gemietete Testumgebung oft passender als ein ungeplanter Hardwarekauf: Der Bedarf bleibt auf die Abnahme beschränkt, und die stabile Laborumgebung muss nicht umgebaut werden. Über die deutsche RUVCLOUD-Übersicht lässt sich ein geeigneter Remote-Mac-Zugang für diesen Zweck prüfen; eine separate Preisübersicht sollte dabei erst nach Klärung von Lizenz, Datenschutz und Projektdauer bewertet werden.

Der Vergleich mit der aktuellen Lösung sollte dennoch nüchtern bleiben. Ein vorhandener Windows- oder Linux-Rechner bietet möglicherweise bereits die Datenablage, lokale Geräte und vertraute Batch-Prozesse, kann aber die macOS- und Apple-Silicon-Abnahme nicht ersetzen. Ein Kauf bindet dagegen Budget, Beschaffung und Wartung, obwohl die Forschungsgruppe den Mac vielleicht nur für eine kurze Prerelease-Prüfung benötigt. Ein Remote Mac beseitigt diese Grenzen nicht, reduziert aber den Aufwand für einen zeitlich begrenzten Softwaretest, sofern keine physische Hardware angeschlossen werden muss.

Nach der abgeschlossenen Abnahme entscheidet die Gruppe anhand des Protokolls: stabile Version beibehalten, vorübergehend doppelt betreiben oder erst nach der offiziellen Veröffentlichung erneut testen. R2026b Prerelease darf nicht allein deshalb zur Produktionsbasis werden, weil Start und ein einzelnes Skript funktioniert haben.