macOS Tahoe nervt? Update-Hinweise verschieben und Major-Upgrade sauber ausbremsen

Es gibt so Dinge, die sind eigentlich klein, nerven aber im Alltag jedes Mal wieder. Bei mir ist das gerade macOS und der sehr dezente Hinweis von Apple, dass ich doch bitte endlich auf die nächste große Version aktualisieren soll.

Natürlich kann man jetzt sagen: Updates sind wichtig. Stimmt auch. Aber zwischen einem Security Update und einem Major Upgrade liegen in der Praxis eben Welten.

Ich will Security Updates zeitnah haben. Ein Major Upgrade möchte ich aber dann installieren, wenn Backup, Tools und Timing passen. Gerade auf einem produktiv genutzten MacBook ist “einfach mal klicken” aus meiner Sicht keine besonders gute Betriebsstrategie.

Vielleicht bin ich mit 38 inzwischen einfach altmodisch. Kann sein. Aber ich finde immer noch, dass ein Rechner, mit dem man produktiv arbeitet, nicht wie ein iPhone-Spielzeug behandelt werden sollte. Wenn ich ein Major Upgrade mache, dann bewusst.

Also kurz gesucht, einen guten Hinweis bei Steiger Legal gefunden und dann natürlich nicht nur den einen Befehl übernommen, sondern gleich weiter getestet.

Der eigentliche Mehrwert ist für mich die Kombination aus:

• macOS-Defaults-Key gegen die nervige Upgrade-Benachrichtigung
• Gegenprüfung im Terminal
• zusätzlichem stop-tahoe-update-Profil
• eigener Anpassung auf 360 Tage
• klare Grenze: 90 Tage sind offiziell, 360 Tage sind mein Versuch

Ausgangslage

Apple möchte verständlicherweise, dass möglichst viele Systeme auf der aktuellen macOS-Version laufen. Aus Security- und Support-Sicht ist das auch nachvollziehbar.

Nur ist ein Major Upgrade eben nicht das Gleiche wie ein kleines Security Update.

Bei mir hängen an dem MacBook unter anderem:

• tägliche Arbeit
• Terminal- und SSH-Workflows
• lokale Tools
• VPN- und Netzwerk-Setups
• Kamera-/Audio-/Streaming-Themen
• diverse kleine Helferlein, die irgendwann mal eingerichtet wurden und nun einfach funktionieren sollen

Und genau deshalb möchte ich nicht am ersten Tag auf Tahoe springen, nur weil macOS mir das freundlich, aber hartnäckig anbietet.

Das Ziel ist also nicht:

Updates komplett ignorieren.

Sondern:

Security Updates weiter ernst nehmen, aber Major-Upgrades kontrolliert und später installieren.

Das ist ein Unterschied.

Quelle / Fundstück: Steiger Legal und der einfache defaults-Ansatz

Der Ausgangspunkt war ein kurzer Artikel bei Steiger Legal zu nervigen macOS-Aktualisierungsbenachrichtigungen.

Die Idee ist erfreulich simpel: macOS merkt sich über com.apple.SoftwareUpdate ein Datum, bis wann die Major-Upgrade-Benachrichtigung nicht mehr erscheinen soll.

Der Befehl sieht im Prinzip so aus:

defaults write com.apple.SoftwareUpdate MajorOSUserNotificationDate -date "2026-09-30 12:00:00 +0000"

Wichtig dabei: gerade Anführungszeichen verwenden.

Also so:

"2026-09-30 12:00:00 +0000"

Nicht irgendwelche typografischen Quotes, die durch WordPress, Copy/Paste oder den Browser aus dem Befehl plötzlich etwas anderes machen.

Das klingt banal, ist aber genau die Sorte Fehler, nach der man sonst wieder zehn Minuten völlig unnötig sucht.

Status prüfen

Nach dem Setzen kann man den Wert kontrollieren:

defaults read com.apple.SoftwareUpdate MajorOSUserNotificationDate

Wenn der Key gesetzt ist, sollte macOS ein Datum zurückgeben.

Falls man den Wert wieder entfernen möchte:

defaults delete com.apple.SoftwareUpdate MajorOSUserNotificationDate

Das ist die kleine, schnelle Variante.

Für einen einzelnen Mac ist das schon mal völlig in Ordnung: nachvollziehbar, reversibel, keine Zusatzsoftware.

Aber mir war das ehrlich gesagt noch etwas zu wenig.

Warum mir der einzelne defaults-Key nicht reicht

Viele Blogposts hören an dieser Stelle auf.

Ein Befehl, fertig, danke, Quelle unten dran.

Kann man machen. Aber in der Praxis bleiben dann die spannenden Fragen offen:

• Greift das wirklich auf meiner macOS-Version?
• Was passiert mit Tahoe konkret?
• Ist das nur ein Hinweis oder wirklich eine Sperre?
• Was ist mit Configuration Profiles?
• Kann man das sauber zurückbauen?
• Wo ist die Grenze zwischen “praktischer Workaround” und “ich betreibe mein System unsauber”?

Genau deshalb habe ich mir zusätzlich stop-tahoe-update angeschaut.

Mein zusätzlicher Test: stop-tahoe-update

Das Projekt travisvn/stop-tahoe-update stellt ein Configuration Profile bereit, das Major-Upgrades wie Sequoia → Tahoe verzögern soll. Dazu kommen kleine Scripts für Installation, Status und Uninstall.

Also kurz lokal vorbereitet:

mkdir -p ~/Documents/Tools
cd ~/Documents/Tools

git clone https://github.com/travisvn/stop-tahoe-update.git
cd stop-tahoe-update

Einmal schauen, was drin ist:

ls

Bei mir sah das entsprechend überschaubar aus:

docs
LICENSE
profiles
README.md
scripts

Dann die Scripts ausführbar machen:

chmod +x ./scripts/*.sh

Das Standard-Profil liegt unter profiles/:

ls profiles/

Im Normalfall ist dort ein 90-Tage-Profil vorhanden:

deferral-90days.mobileconfig

Die Installation läuft dann über:

./scripts/install-profile.sh profiles/deferral-90days.mobileconfig

macOS installiert Profile nicht mehr einfach still

Hier kam bei mir ein wichtiger Punkt:

profiles tool no longer supports installs.
Use System Settings Profiles to add configuration profiles.
Opening profile in System Settings for manual approval...
Press Enter after you've approved (or declined) the profile in System Settings.

Das ist nicht automatisch ein Fehler im Script.

macOS erlaubt auf aktuellen Versionen nicht mehr, dass Profile einfach still per profiles-Tool installiert werden. Stattdessen wird das Profil in den Systemeinstellungen geöffnet und muss manuell bestätigt werden.

Also:

1. Script starten
2. Systemeinstellungen öffnen lassen
3. Profil prüfen
4. Profil manuell installieren
5. zurück ins Terminal
6. Enter drücken

Eigentlich finde ich das gar nicht schlecht. Ein .mobileconfig-Profil sollte man nicht blind installieren. Damit kann man durchaus relevante Einstellungen am System setzen.

Was im Profil wichtig ist

Das Profil arbeitet mit Apples Software-Update-Deferral-Mechanismus.

Relevant sind vor allem diese Keys:

<key>forceDelayedMajorSoftwareUpdates</key>
<true/>

<key>enforcedSoftwareUpdateMajorOSDeferredInstallDelay</key>
<integer>90</integer>

Die Idee ist: Major-Upgrades werden für eine bestimmte Anzahl Tage verzögert beziehungsweise in Software Update nicht direkt angeboten.

Der wichtige Punkt dabei: Apple dokumentiert für solche Deferrals normalerweise 1 bis 90 Tage. Das GitHub-Projekt setzt deshalb sauber auf 90 Tage.

Das ist der offizielle Bereich.

Mein zusätzlicher Versuch: 360 Tage

Nun der Teil, der für mich den Artikel überhaupt erst interessant macht.

Ich habe nicht nur das Standardprofil getestet, sondern das Profil zusätzlich auf 360 Tage angepasst.

Also im Prinzip:

cp profiles/deferral-90days.mobileconfig profiles/deferral-360days.mobileconfig

Danach die Datei mit einem Editor öffnen:

nano profiles/deferral-360days.mobileconfig

Und den Wert anpassen:

<key>enforcedSoftwareUpdateMajorOSDeferredInstallDelay</key>
<integer>360</integer>

Danach kann man kurz prüfen, ob die erwartete Stelle enthalten ist:

grep -n "enforcedSoftwareUpdateMajorOSDeferredInstallDelay\|forceDelayedMajorSoftwareUpdates" profiles/deferral-360days.mobileconfig

Installation dann entsprechend:

./scripts/install-profile.sh profiles/deferral-360days.mobileconfig

Wichtig: Das ist kein offiziell garantierter Apple-Weg.

Apple nennt 90 Tage als dokumentierten Bereich. Alles darüber ist ein eigener Versuch und muss auf dem konkreten System geprüft werden.

Sauber formuliert:

• 90 Tage sind die belastbare Basis.
• 360 Tage sind ein praktischer Versuch.
• macOS kann den Wert akzeptieren, ignorieren oder künftig anders behandeln.
• Nach macOS-Updates sollte man erneut prüfen.
• Ich würde daraus keine Enterprise-Policy bauen.

Für meinen eigenen Mac ist es aber genau die Art Experiment, die ich ausprobieren möchte. Klein, reversibel und nachvollziehbar.

Status prüfen

Das Projekt bringt ein Status-Script mit:

./scripts/status.sh

Zusätzlich kann man Profile auch über macOS anzeigen lassen:

profiles show

Oder etwas gezielter nach Software-Update-relevanten Stellen suchen:

profiles show | grep -i -A6 -B6 "SoftwareUpdate\|Major\|Deferred\|Tahoe"

Je nach macOS-Version ist die Ausgabe nicht besonders schön. Aber sie reicht, um zu sehen, ob überhaupt ein Profil aktiv ist.

Zusätzlich lohnt sich natürlich der Blick in:

Systemeinstellungen → Allgemein → Softwareupdate

Wenn dort weiterhin sehr aggressiv das Major Upgrade angeboten wird, ist entweder das Profil nicht aktiv, nicht korrekt bestätigt oder macOS ignoriert den gesetzten Wert.

Rollback

Rollback ist wichtig, sonst ist es keine saubere Lösung.

Den Defaults-Key entfernt man mit:

defaults delete com.apple.SoftwareUpdate MajorOSUserNotificationDate

Das Profil entfernt man über das Projekt-Script:

./scripts/uninstall-profile.sh

Alternativ geht es natürlich auch über:

Systemeinstellungen → Datenschutz & Sicherheit → Profile

Je nach macOS-Version liegt der Profilbereich an leicht anderer Stelle. Apple verschiebt solche Menüs ja gerne mal, weil offensichtlich sonst Langeweile aufkommt.

Was ich damit nicht lösen möchte

Wichtig ist die Abgrenzung.

Das hier soll kein vollständiges Patch-Management ersetzen.

Ich möchte damit nicht:

• Security Updates dauerhaft blockieren
• XProtect/Gatekeeper/Systemdaten ignorieren
• einen Firmen-MDM-Prozess ersetzen
• andere Macs ungeprüft mit irgendeinem Profil beglücken
• so tun, als wäre 360 Tage offiziell dokumentiert

Das Ziel ist kleiner:

Ich möchte das Major Upgrade ruhigstellen, bis ich bewusst upgrade.

Mehr nicht.

Status dieser Notiz

Tested on my setup: yes, defaults command and profile installation flow were tested
Based on external source: yes, Steiger Legal and stop-tahoe-update
Officially documented: 90-day software update deferral range
Experimental: 360-day profile value
Rollback documented: yes

Praktische Empfehlung

Für einen privaten oder kleinen Lab-Mac würde ich es so sehen:

Minimalvariante

defaults write com.apple.SoftwareUpdate MajorOSUserNotificationDate -date "2026-09-30 12:00:00 +0000"
defaults read com.apple.SoftwareUpdate MajorOSUserNotificationDate

Gut, wenn man nur die Benachrichtigung verschieben möchte.

Sauberere Variante

git clone https://github.com/travisvn/stop-tahoe-update.git
cd stop-tahoe-update
chmod +x ./scripts/*.sh
./scripts/install-profile.sh profiles/deferral-90days.mobileconfig
./scripts/status.sh

Gut, wenn man mit einem Configuration Profile arbeiten möchte.

Meine Testvariante

cp profiles/deferral-90days.mobileconfig profiles/deferral-360days.mobileconfig
nano profiles/deferral-360days.mobileconfig
./scripts/install-profile.sh profiles/deferral-360days.mobileconfig
./scripts/status.sh

Gut, wenn man bewusst testen möchte, ob ein längerer Deferral-Wert auf dem eigenen System greift.

Aber nochmal: 360 Tage sind mein Versuch, nicht Apples offizielles Versprechen.

Fazit

Der Steiger-Legal-Hinweis mit MajorOSUserNotificationDate ist ein guter kleiner Fix gegen nervige macOS-Upgrade-Benachrichtigungen.

Für mich war das aber nur der Anfang.

Ich habe zusätzlich stop-tahoe-update getestet, das 90-Tage-Profil installiert und für mein Setup eine 360-Tage-Variante gebaut. Genau das ist für mich der Unterschied zwischen einem reinen Link-Post und einer brauchbaren XpressLabs-Notiz:

• Quelle gefunden
• selbst ausprobiert
• erweitert
• Stolperfallen dokumentiert
• Rollback notiert
• Grenzen klar benannt

Unterm Strich bleibt es ein kleiner Fix. Aber ein nützlicher.

Und manchmal sind genau diese kleinen Fixes die Dinge, die den Alltag angenehmer machen.

Quellen

• Steiger Legal: "Tipp: Nervige Benachrichtigungen für Aktualisierung auf MacOS Sonoma deaktivieren"
  https://steigerlegal.ch/2024/02/10/macos-aktualisierung-benachrichtigungen/
• GitHub: travisvn/stop-tahoe-update
  https://github.com/travisvn/stop-tahoe-update
• Apple Deployment Guide: "Install and enforce software updates for Apple devices"
  https://support.apple.com/guide/deployment/install-and-enforce-software-updates-depd30715cbb/web