IBM hat SPSS Statistics 32.0.0 am 23.04.2026 veröffentlicht. Die Veröffentlichung umfasst Installations- und Lizenzdokumentation für macOS. Das belegt jedoch nicht, dass das aktuelle Installationspaket bereits nativ auf Apple Silicon läuft. Maßgeblich sind die offiziellen SPSS-32-Dokumente und die Release Notes für SPSS 32.0.0.

Für Ihre Beschaffungsentscheidung müssen Sie drei Aussagen strikt auseinanderhalten:

• Bestätigt: SPSS Statistics 32.0.0 ist verfügbar und es gibt eine macOS-Installations- und Autorisierungsdokumentation.
• Nicht automatisch bestätigt: Ein macOS-Paket ist nicht allein deshalb eine Apple-Silicon-Anwendung. Es kann als Intel-Anwendung unter Rosetta laufen.
• Noch nicht veröffentlicht: Ein IBM-Techniker hat in der offiziellen Community eine native Apple-Silicon-Version im Zusammenhang mit SPSS 32.0.1 für September 2026 in Aussicht gestellt. Das ist eine Planung, keine veröffentlichte Version und keine Garantie für Datum, Funktionsumfang oder Paketarchitektur. Die offizielle IBM-Community-Diskussion zur Apple-Silicon-Kompatibilität ist deshalb als Roadmap-Information zu lesen.

Die Frage nach nativer Unterstützung von SPSS 32 auf Apple Silicon lässt sich am 24.08.2026 daher nicht mit einem pauschalen Ja beantworten. Prüfen Sie die tatsächlich angebotene Installationsdatei und die ausführbaren Komponenten. Verlassen Sie sich weder auf die Versionsnummer 32 noch auf die Bezeichnung „Mac-Version“.

Was Rosetta heute für Ihre Forschungsarbeit bedeutet

Rosetta übersetzt Intel-Anwendungen für Apple-Silicon-Macs. Wenn SPSS 32.0.0 in Ihrer Installation als Intel-Anwendung vorliegt, kann Rosetta der notwendige Kompatibilitätslayer sein. Apple beschreibt in seiner Dokumentation zur Erkennung der Anwendungsarchitektur, wie Sie feststellen, ob eine Anwendung als „Intel“, „Apple“ oder „Universal“ vorliegt.

Apple hat bestätigt, dass die allgemeine Unterstützung von Rosetta bis macOS 27 fortgeführt wird. Für macOS 28 soll nur noch eine eingeschränkte Funktion für bestimmte ältere Spiele verbleiben. Diese Grenze ist für Hochschulen wichtiger als die Frage, ob eine Rosetta-Anwendung heute startet: Ein Arbeitsplatz, der nur unter einer Übergangstechnologie funktioniert, braucht einen dokumentierten Ausstiegsplan.

Das erzeugt mindestens vier konkrete Risiken:

• Betriebsrisiko: Ein künftiges macOS-Upgrade kann die bisherige Startkette, ein Plug-in oder einen Hilfsprozess anders behandeln als die Hauptanwendung.
• Ergebnisrisiko: Nicht jede Abweichung erscheint beim Programmstart. Exportformate, Zeichenkodierung, Diagramme oder Erweiterungen können erst im Forschungsablauf auffallen.
• Administrationsrisiko: Ein persönlicher Lizenztyp darf nicht automatisch auf einen Pool-Rechner, eine Fernnutzung oder mehrere Personen übertragen werden.
• Reproduzierbarkeitsrisiko: Wenn Sie die einzige funktionierende Umgebung überschreiben, fehlt bei einer späteren Rückfrage die exakte Kombination aus SPSS-Version, Syntax, Erweiterungen und macOS.

Rosetta ist damit kein Grund, ein laufendes Projekt sofort zu stoppen. Es ist aber ein Grund, die Übergangslösung nicht ungeprüft als langfristigen Standard für ein Labor festzuschreiben.

Bei einer laufenden Lehrveranstaltung, einer Dissertation oder einer Revisionsrunde zählt Kontinuität stärker als ein noch nicht veröffentlichtes Architekturmerkmal. Wenn SPSS 32.0.0 in der derzeit unterstützten Umgebung stabil arbeitet, sollten Sie die Datenanalyse nicht löschen, neu installieren oder auf eine unbestätigte Version verschieben.

Sichern Sie vor jeder Änderung mindestens:

• die genaue SPSS-Version und den Installationsweg;
• den Lizenztyp und die zuständige Hochschulstelle;
• alle Erweiterungen, Plug-ins und Integrationen;
• die vollständige SPS-Syntax einschließlich definierter Pfade;
• eine repräsentative SAV-Datei;
• die wichtigsten Ausgaben als nachvollziehbare Referenz;
• Hinweise zu Python-, R- oder automatisierten Exportprozessen.

Diese Sicherung ist keine Formalität. Sie bildet Ihre Vergleichsbasis. Ohne Baseline können Sie nach einer Migration nicht zuverlässig unterscheiden, ob ein Unterschied durch die neue Architektur, eine geänderte Syntax, ein Plug-in oder eine veränderte Datei entstanden ist.

M-Serie-Mac, SPSS 32 und Rosetta: Was müssen Sie tatsächlich prüfen?

Auf einem M-Serie-Mac kann SPSS 32.0.0 je nach Paketarchitektur Rosetta benötigen. Ob das in Ihrem konkreten Fall so ist, prüfen Sie direkt nach der Installation in den macOS-Informationen der Anwendung. Zusätzlich sollten Sie die abhängigen Komponenten untersuchen: Eine native Hauptanwendung garantiert nicht, dass Python-Module, R-Integration, Erweiterungs-Hubs oder selbst geschriebene Hilfsprogramme ebenfalls nativ arbeiten.

Gehen Sie nicht von dieser Gleichung aus:

„Apple Silicon Mac + SPSS 32 = native Ausführung“.

Die belastbare Prüfung lautet:

1. Welche Architektur weist die SPSS-Hauptanwendung aus?
2. Welche Architektur haben die verwendeten Erweiterungen?
3. Startet ein benötigter Hintergrundprozess über Rosetta?
4. Funktionieren Import, Analyse, Diagramm und Export mit derselben Datei?
5. Sind Lizenzserver, Autorisierung und Fernzugriff für diese Nutzung freigegeben?

Wenn Sie nur eine Lehrveranstaltung abschließen oder eine bestehende Auswertung reproduzieren müssen, bleibt eine funktionierende Rosetta-Installation zunächst die risikoärmere Wahl. Wenn Sie dagegen ein neues Laborabbild für einen längeren Zeitraum planen, dokumentieren Sie die Übergangslösung und testen Sie die native Migration getrennt.

Vor dem Erscheinen von SPSS 32.0.1 sollten Sie nicht auf eine Datei warten, sondern auf Ihrer realen Arbeit aufbauen. Wählen Sie einen kleinen, aber repräsentativen Datensatz aus Ihrem Forschungsbereich. Ein bloßer Programmstart ist kein Akzeptanztest.

Der Datensatz sollte mindestens diese Arbeitsanteile enthalten:

• SAV-Datei öffnen und Variablenlabels sowie Zeichencodierung kontrollieren;
• typische Datenaufbereitung und fehlende Werte ausführen;
• die zentralen statistischen Verfahren des Projekts rechnen;
• eine Tabelle und eine Grafik erzeugen;
• Ergebnisse über den im Labor verwendeten Weg exportieren;
• dieselbe Auswertung aus SPS-Syntax starten;
• vorhandene Python- oder R-Verknüpfungen separat ausführen;
• ein Ergebnis zur späteren Prüfung archivieren.

Notieren Sie dabei keine Leistungswerte, die Sie nicht selbst gemessen haben. Startzeit, Laufzeit und Speicherverbrauch sind nur dann belastbare Aussagen, wenn sie aus einem reproduzierbaren Test stammen. Für die Hochschulentscheidung ist zunächst wichtiger, ob Ergebnisse, Dateien und Erweiterungen konsistent bleiben.

Beispiel: Ein Doktorand mit laufender Datenanalyse

Angenommen, Ihre Dissertation verwendet eine gewachsene SPS-Syntax, mehrere SAV-Dateien und einen automatisierten Export für die Betreuung. Der Apple-Silicon-Mac startet SPSS 32.0.0 über Rosetta ohne sichtbare Probleme. In diesem Fall wäre ein sofortiger Wechsel wirtschaftlich und organisatorisch schwer zu begründen: Sie würden eine funktionierende Arbeitsumgebung gegen eine noch nicht veröffentlichte Version tauschen.

Die sinnvolle Vorgehensweise ist:

• laufende Analysen in der bekannten Umgebung beenden;
• die Referenzdateien und Ausgaben unverändert archivieren;
• eine getrennte Testumgebung für die spätere Version vorbereiten;
• nur nach identischen Ergebnissen und geprüften Erweiterungen umstellen.

Wenn Ihnen dafür kein eigener M-Serie-Mac zur Verfügung steht, kann eine zeitlich begrenzte unabhängige Remote-Mac-Umgebung sinnvoll sein. Voraussetzung ist, dass Ihre Hochschule die Fernnutzung der SPSS-Lizenz erlaubt. Prüfen Sie außerdem Datenschutz, Zugriffskontrolle und Speicherort der Forschungsdaten nach den Vorgaben Ihrer Einrichtung und der DSGVO.

Sobald SPSS 32.0.1 offiziell erscheint, installieren Sie nicht sofort auf dem einzigen Forschungsrechner. Beginnen Sie mit der Quellenprüfung. Öffnen Sie die offizielle IBM-Downloadseite, die Release Notes und die Installationsdokumentation. Kontrollieren Sie:

• die exakt angegebene Versionsnummer;
• das tatsächliche Veröffentlichungsdatum;
• die ausdrücklich unterstützten macOS-Versionen;
• die Architektur des Installationspakets;
• Lizenzänderungen oder neue Aktivierungsbedingungen;
• bekannte Einschränkungen und behobene Fehler.

Ein Dateiname wie „Apple Silicon“ reicht nicht als Nachweis. Prüfen Sie nach der Installation die Architektur der Hauptanwendung mit den macOS-Informationen oder den von Apple beschriebenen Systemwerkzeugen. Wenn das Paket als Universal-Anwendung ausgewiesen ist, untersuchen Sie trotzdem die Erweiterungen und Hilfsprozesse.

Für die Lizenzprüfung unterscheiden Sie zwischen Einzelplatz- und Mehrbenutzerbetrieb. Die IBM-Anleitung für autorisierte Benutzerlizenzen ist für persönliche oder einzeln autorisierte Installationen relevant. Für Laborrechner, Pools oder zentral verwaltete Arbeitsplätze ist die IBM-Anleitung für Concurrent-User-Lizenzen gesondert zu prüfen.

Achten Sie insbesondere auf diese Fehlannahmen:

• Eine persönliche Lizenz ist nicht automatisch eine Laborlizenz.
• Ein erlaubter Fernzugriff ist nicht automatisch eine Mehrbenutzerfreigabe.
• Eine vorhandene alte Lizenz bleibt nicht zwingend parallel nutzbar.
• Ein zentraler Lizenzserver löst keine inkompatiblen Erweiterungen.
• Ein Hochschulvertrag kann zusätzliche Bedingungen für private Geräte oder Remote-Sitzungen enthalten.

Nach der Installation von SPSS 32.0.1 führen Sie dieselbe Analyse in der alten und der neuen Umgebung aus. Verwenden Sie dieselbe SAV-Datei, dieselbe SPS-Syntax, dieselben Ausgabeoptionen und – falls relevant – denselben Zufallsstartwert. Ändern Sie nicht gleichzeitig Daten, Syntax und Softwareversion. Sonst verlieren Sie die Ursache möglicher Abweichungen.

Prüfen Sie in dieser Reihenfolge:

1. Datenimport: Werden Variablenlabels, Datumswerte, Dezimaltrennzeichen und Sonderzeichen identisch eingelesen?
2. Statistische Ergebnisse: Stimmen Fallzahlen, Koeffizienten, Testwerte und Rundungen mit der Baseline überein?
3. Tabellen und Grafiken: Haben sich Layout, Achsen, Schriftzeichen oder Legenden verändert?
4. Export: Lassen sich die benötigten Dateien in den Formaten des Lehrstuhls oder Journals erzeugen?
5. Syntaxlauf: Wird die gesamte SPS-Datei ohne manuelle Korrektur ausgeführt?
6. Erweiterungen: Funktionieren Python, R, Erweiterungsbefehle und eigene Hilfsskripte?
7. Fernbetrieb: Bleiben Lizenzverbindung, Benutzerrechte und Sitzungsstabilität im vorgesehenen Zugriffsszenario erhalten?

Bei einer Abweichung speichern Sie Protokoll, Minimaldatei, Syntax und genaue Fehlermeldung. Testen Sie danach nur eine Änderung. Die IBM-Liste der SPSS-32.0-Fehlerbehebungen hilft Ihnen bei der Einordnung, ersetzt aber keinen Test mit Ihren eigenen Forschungsdaten.

Das Abbruchkriterium ist klar: Wenn Kernresultate nicht reproduzierbar sind, eine zentrale Erweiterung fehlt oder die Lizenznutzung ungeklärt bleibt, bleibt die alte Umgebung aktiv. Ein Rückfall ist kein Scheitern, sondern eine kontrollierte Maßnahme zur Sicherung der Forschungsarbeit.

Verwenden Sie diese Ankreuzliste für jeden Arbeitsplatz und jedes Forschungsprojekt. Eine vollständige Freigabe liegt erst vor, wenn die Bedingungen für Ergebnisse, Erweiterungen und Lizenzen erfüllt sind.

• [ ] Läuft eine Abgabe, Lehrveranstaltung oder Begutachtungsfrist?
  Wenn ja und SPSS 32.0.0 zuverlässig arbeitet, wählen Sie die bestehende Umgebung. Warten Sie nicht auf SPSS 32.0.1 und verändern Sie den Produktionsrechner nicht.

• [ ] Sind SPSS-Version, Lizenztyp, SAV-Datei, SPS-Syntax und Referenzausgaben archiviert?
  Wenn nein, erstellen Sie zuerst die Baseline. Ein Versionswechsel ohne Vergleichsbestand ist nicht freigabefähig.

• [ ] Ist SPSS 32.0.1 bereits offiziell auf der IBM-Downloadseite und in den Release Notes erschienen?
  Wenn nein, behandeln Sie die Community-Aussage weiterhin als Planung. Installieren Sie keine Datei, deren Veröffentlichungsstatus und Architektur nicht offiziell bestätigt sind.

• [ ] Ist die Architektur der SPSS-Hauptanwendung eindeutig als Apple, Universal oder Intel festgestellt?
  Wenn nein, führen Sie die Prüfung unter macOS durch. Ein Dateiname oder eine Produktwerbung genügt nicht.

• [ ] Sind Python, R, Plug-ins, Erweiterungsbefehle und eigene Hilfsskripte getestet?
  Wenn nein, behalten Sie die alte Umgebung und richten Sie eine getrennte Testumgebung ein.

• [ ] Stimmen Import, statistische Kennwerte, Tabellen, Grafiken, Zeichenkodierung und Export mit der Baseline überein?
  Wenn nein, stoppen Sie die vollständige Umstellung, sichern Sie die Minimalreproduktion und untersuchen Sie die Abweichung.

• [ ] Ist die Lizenz für persönliche Nutzung, Fernzugriff, Poolbetrieb oder mehrere Anwender ausdrücklich freigegeben?
  Wenn nein, klären Sie die Nutzung mit der Hochschulverwaltung, bevor Forschungsdaten auf dem Testsystem verarbeitet werden.

• [ ] Wird ein langfristiges Laborabbild für eine spätere macOS-28-Planung erstellt?
  Wenn ja, priorisieren Sie die native Migration, behalten aber die bisher reproduzierbare Umgebung als Rückfalloption.

• [ ] Fehlt ein geeigneter M-Serie-Mac für den begrenzten Test?
  Wenn ja und die Lizenz Fernnutzung erlaubt, verwenden Sie für den Validierungszeitraum einen separaten Remote Mac. Entscheiden Sie erst danach über Kauf, dauerhafte Miete oder weitere Nutzung der bisherigen Umgebung.

Die Entscheidung lässt sich damit in drei Pfade übersetzen:

• Sofort weiterarbeiten: laufendes Projekt, stabile Ergebnisse, keine akute Systemmigration.
• Zweigleisig testen: SPSS 32.0.1 offiziell verfügbar, aber Erweiterungen, Lizenz oder Ergebnisse noch nicht vollständig geprüft.
• Schrittweise umstellen: alle Rückkehrtests bestanden, Lizenzierung geklärt und ein Rückfallabbild vorhanden.

So ist auch die Frage, ob Sie auf SPSS 32.0.1 warten oder jetzt installieren sollten, eindeutig nach Situation beantwortet: Installieren Sie SPSS 32.0.0 jetzt, wenn Sie eine laufende oder kurzfristige Aufgabe erledigen müssen. Warten Sie mit der endgültigen Standardisierung auf SPSS 32.0.1, wenn Sie eine langfristige native Apple-Silicon-Umgebung planen. Die beiden Entscheidungen widersprechen sich nicht, solange Sie nicht dieselbe einzige Umgebung als Test- und Produktionssystem verwenden.

Ein Remote Mac ist kein Ersatz für die Lizenzprüfung und kein Beweis für eine native SPSS-Ausführung. Er kann aber eine Beschaffungslücke schließen, wenn das Labor keinen geeigneten M-Serie-Mac besitzt und Sie nur für einen begrenzten Zeitraum eine reale macOS-Umgebung benötigen.

Gegenüber einer sofortigen Gerätebeschaffung bietet eine unabhängige Remote-Umgebung vor allem:

• keinen Kauf eines zusätzlichen Arbeitsplatzes für eine noch unklare Versionsentscheidung;
• eine getrennte Testfläche neben dem stabilen Analysegerät;
• Zugriff über VNC, SSH oder eine Webkonsole, sofern Ihre Arbeitsweise dies erlaubt;
• vollständige Administratorrechte für die Installation von SPSS-Abhängigkeiten;
• eine bessere Trennung zwischen Forschungsdaten und dem bestehenden Laborrechner.

Die Nachteile müssen Sie ebenfalls einplanen:

• Große SAV-Dateien können durch den Upload und die Netzwerkverbindung unpraktisch werden.
• Grafische Fernsitzungen sind nicht identisch mit einem lokalen Bildschirm.
• Vertrauliche Forschungsdaten dürfen nur verarbeitet werden, wenn Speicherort, Zugriff und Vertrag den Hochschulregeln entsprechen.
• Für dauerhaft hohe Nutzung kann ein eigener Mac wirtschaftlich und organisatorisch sinnvoller sein.
• Physische Geräte, spezielle Messhardware oder lokale Netzwerklaufwerke lassen sich nicht automatisch ersetzen.

Wenn Sie sich für einen eigenen Arbeitsplatz interessieren, können Sie die verfügbaren Mac-Konfigurationen für Hochschul- und Forschungsabläufe getrennt von der Versionsfrage bewerten. Für einen kurzen Rückkehrtest sollte jedoch nicht die Hardwarebeschaffung den Softwaretest verzögern.

Für Studierende und Forschende ist die wichtigste Entscheidung die Trennung von Projektkontinuität und Plattformmigration. Sie können SPSS 32.0.0 unter der aktuell funktionierenden Ausführungsart einsetzen, ohne die native SPSS-32-Version als langfristige Perspektive aufzugeben.

Für Laborverantwortliche kommen zusätzliche Aufgaben hinzu:

• ein getestetes Referenzabbild dokumentieren;
• Lizenztypen und gleichzeitige Nutzung mit der Hochschulverwaltung klären;
• ein SAV- und SPS-Testpaket für jeden Arbeitsplatz definieren;
• Python-, R- und Erweiterungsabhängigkeiten inventarisieren;
• eine Rückfallumgebung für veröffentlichte oder eingereichte Ergebnisse behalten;
• den macOS-Upgrade-Zeitpunkt mit der SPSS-Roadmap abstimmen;
• für DSGVO-relevante Daten einen genehmigten Speicher- und Löschprozess festlegen.

Die aktuelle Rosetta-Lösung hat den Vorteil, dass Sie bestehende Abläufe nicht sofort verändern müssen. Ihre Nachteile liegen in der zusätzlichen Übergangsschicht, der unklaren Zukunft einzelner Abhängigkeiten und dem späteren Prüfaufwand. Eine native Version kann diese Architekturabhängigkeit verringern, ist aber bis zur offiziellen Veröffentlichung und Ihrer eigenen Rückkehrprüfung keine belastbare Produktionsgrundlage.

Wenn Ihr Labor heute ausschließlich Linux- oder Windows-Arbeitsplätze besitzt, löst eine kurzfristige Remote-Mac-Miete das konkrete Validierungsproblem schneller als der Kauf mehrerer Geräte. Sie müssen dennoch vorab die SPSS-Lizenz, Datenschutzanforderungen und den Umfang der Forschungsdaten klären. Für einen kurzen Testzeitraum ist diese Trennung häufig sinnvoller als eine übereilte dauerhafte Anschaffung. Informationen zur Mac-Nutzung über KVMNODE können Sie anschließend mit den Vorgaben Ihrer Hochschule abgleichen.

Die klare Empfehlung lautet deshalb: Stoppen Sie keine laufende Lehr- oder Forschungsarbeit wegen einer noch nicht veröffentlichten nativen Version. Sichern Sie SPSS 32.0.0 als Referenz, bereiten Sie eine Doppelumgebung vor und prüfen Sie SPSS 32.0.1 am offiziellen Veröffentlichungstag anhand von Architektur, Ergebnissen, Erweiterungen und Lizenzbedingungen. Wenn Ihnen für diesen begrenzten Test ein geeigneter M-Serie-Mac fehlt, ist eine zeitlich passende Remote-Mac-Miete über KVMNODE eine nachvollziehbare Zwischenlösung; erst nach der Rückkehrprüfung entscheiden Sie über den dauerhaften Kauf oder die vollständige Umstellung.