In allen Betriebssystemen mit der Nummer 27 hat Apple die klassische Verwaltung von Software-Updates entfernt. Nicht als veraltet markiert: entfernt. Die MDM-Befehle, Abfragen und Restriktionen, mit denen Ihre Plattform seit zehn Jahren iOS- und macOS-Updates ausrollt, funktionieren unter iOS 27, iPadOS 27 und macOS 27 nicht mehr. Declarative Device Management (DDM) ist jetzt der einzige Weg, ein Update auf einem aktuellen Apple-Gerät zu erzwingen.
Diese eine Änderung macht aus DDM eine Terminsache statt einer Architekturdebatte. Dieser Leitfaden erklärt, was deklarative Verwaltung ist, was sie für die IT-Administration und für die Person am Gerät konkret verändert, und was die WWDC 2026 verschoben hat.
Das Wichtigste in sechs Punkten
- Klassisches MDM ist imperativ: Der Server schickt Befehle und fragt den Status ab. DDM ist deklarativ: Der Server schickt den Soll-Zustand, das Gerät setzt ihn um und meldet Änderungen selbst.
- Die klassische Update-Verwaltung funktioniert auf keinem 27.0-Betriebssystem mehr. Deklarative Software-Updates sind der einzige Weg.
- Die Deklaration gewinnt. Wenn eine Deklaration und ein alter MDM-Befehl dieselbe Einstellung verwalten, setzt sich die Deklaration durch.
- Die Arbeit wandert auf das Gerät. Richtlinien greifen auch offline, wirken in Sekunden und reparieren sich ohne Resynchronisierung.
- Nutzer werden vorgewarnt, nicht überfallen. Benachrichtigungen können 14 Tage vor der Frist beginnen, Aufschub ist von 1 bis 90 Tagen möglich, und der erzwungene 60-Sekunden-Countdown ist weg.
- Es ist additiv, und Ihr MDM sollte die Naht verbergen. Deklarativ, wo das Gerät es kann, imperativ, wo nicht, aus einer Richtlinie, die Sie einmal konfigurieren.
Was deklarative Verwaltung wirklich ist
Klassisches MDM ist ein Gespräch. Der Server schickt einen Befehl, das Gerät bestätigt, dann fragt der Server nach, ob der Zustand tatsächlich eingetreten ist. Jede Einstellung ist ein eigener Austausch. Multiplizieren Sie das mit einigen tausend Endgeräten, und Ihr MDM verbringt den Tag damit, Statusmeldungen nachzujagen, statt irgendetwas zu verwalten.
DDM dreht das um. Der Server schickt Deklarationen: Aussagen darüber, in welchem Zustand ein Gerät sein soll. Das Gerät speichert sie, wendet sie selbst an, hält sie durch, ob es den Server erreicht oder nicht, und meldet sich nur, wenn sich etwas ändert.
Der Unterschied ist der zwischen einer Führungskraft, die jede Stunde anruft und fragt, ob die Aufgabe fertig ist, und einer, die das Ziel übergibt und darauf vertraut, dass man sich bei Problemen meldet. Apple hat das Modell auf der WWDC 2021 mit iOS 15 eingeführt und den Umfang seither jedes Jahr erweitert. Mit den 27er-Versionen hat es begonnen, die alte Tür hinter sich zu schließen.
Die Bausteine
Eine Deklaration ist kein monolithisches Objekt. Apple teilt sie in Typen, die sich gegenseitig referenzieren. Genau das macht das Modell kombinierbar und nicht bloß schneller.
| Typ | Inhalt | Warum es zählt |
|---|---|---|
| Configurations | Die eigentlichen Einstellungen: Code-Richtlinie, VPN, Update-Regel, zu installierende App | Die Nutzlast. Eine Configuration, mehrfach in Activations verwendbar |
| Activations | Die Logik. Ein Bündel von Configurations plus optionales Prädikat, das entscheidet, wann sie greifen | Bedingte Richtlinien wandern auf das Gerät. Kein Nachbauen dynamischer Gruppen auf dem Server |
| Assets | Wiederverwendbare Daten, auf die Configurations zeigen: Zugangsdaten, Identitätszertifikate, gehostete Profile | Einmal definiert, überall referenziert. Ein Zertifikatswechsel ist kein flottenweiter Push mehr |
Darunter läuft der Statuskanal. Das Gerät abonniert die Werte, die es verwaltet, und schickt einen Bericht in dem Moment, in dem sich einer davon ändert. Der Server erfährt von Abweichungen, wenn sie passieren, nicht beim nächsten geplanten Kontakt.
Das Activation-Prädikat ist der Teil, den die meisten Teams unterschätzen. Weil Prädikate auf dem Gerät gegen Statusberichte und eigene Verwaltungseigenschaften ausgewertet werden, können Sie eine Richtlinie ausliefern, bevor die Bedingung zutrifft, und das Gerät schaltet sie später selbst ein. Eine Configuration, die erst ab einer bestimmten OS-Version greift oder nur, wenn sich ein Gerät als supervised meldet, braucht keine Serverlogik.
Imperativ gegen deklarativ, direkt verglichen
Angenommen, Sie verteilen zehn verwaltete Apps auf ein Gerät.
| Imperatives MDM | Deklarativ | |
|---|---|---|
| Was der Server sendet | Zehn Installationsbefehle | Eine Deklaration mit den zehn Apps |
| Bestätigung | Eine Rückmeldung pro Befehl, dann Abfragen | Das Gerät meldet seinen Zustand, sobald er sich ändert |
| Ein Nutzer löscht App Nummer sieben | Sie bleibt weg, bis jemand eine Resynchronisierung auslöst | Das Gerät installiert sie selbst neu |
| Ein App-Update erscheint | Ein neuer Befehl, pro Gerät in der Warteschlange | Das Gerät aktualisiert sie, ohne Serveraktion |
| Gerät im Ruhezustand oder offline | Befehle bleiben in der Warteschlange | Die Deklaration greift und hält lokal |
| Erkennung von Abweichungen | Beim nächsten Kontakt, teils Stunden später | Sofortiger Push vom Gerät |
| Ihr Dashboard | Ein Meer aus „ausstehend“ | Der aktuelle Zustand |
Eine Klarstellung, weil das häufig falsch gelesen wird: Eine Deklaration wird weiterhin an jedes Gerät einzeln ausgeliefert. Der Gewinn ist nicht eine Nachricht für die ganze Geräteflotte. Der Gewinn ist, dass eine einzige Deklaration einen Strom von Befehlen und eine Abfrageschleife ersetzt, pro Gerät, für die gesamte Lebensdauer dieser Richtlinie.
Was sich für die IT-Administration ändert
Updates, die tatsächlich ankommen
Imperative macOS-Updates waren notorisch unzuverlässig. Befehle, die stillschweigend hängen blieben, Geräte, die die Frist ignorierten, Nutzer, die endlos aufschoben, und ein Compliance-Bericht, dem man nur halb glaubte. Das deklarative Software-Update übergibt dem Mac eine Zielversion und ein Durchsetzungsdatum, und der Mac steuert selbst. Er lädt im Hintergrund, plant um den Nutzer herum und meldet seinen Fortschritt über den Statuskanal.
Der praktische Unterschied zeigt sich im Reporting. Sie fragen nicht mehr, ob der Befehl durchkam, sondern lesen einen Zustand, den das Gerät über sich selbst behauptet.
Compliance, die sich in der Gegenwart belegen lässt
Statusabfragen tragen eine Lüge in sich. Zwischen zwei Abfragen wissen Sie nicht, was ein Gerät tut. Jemand deaktiviert eine Einstellung, verlässt das Netz, fällt aus der Richtlinie, und Sie erfahren es bei der nächsten Abfrage, die vier Stunden entfernt sein kann.
Der Statuskanal schließt dieses Fenster. Für ein Audit ist der Sprung von „wir haben heute Morgen geprüft“ zu „wir wissen es jetzt“ mehr wert als der Geschwindigkeitsgewinn. Es ist auch die Antwort auf die Frage, die Prüfer wirklich stellen: nicht, ob es eine Richtlinie gibt, sondern ob Sie durchgehende Durchsetzung nachweisen können. Für NIS2-Nachweise über die Geräteflotte ist genau das der Punkt.
Weniger Objekte zu pflegen
Weil Assets referenziert und nicht eingebettet werden und Configurations über mehrere Activations hinweg wiederverwendet werden, wächst die Objektzahl nicht länger im Gleichschritt mit Ihrer Richtlinienmatrix. Ein Identitätszertifikat zu erneuern wird zum Asset-Update statt zum erneuten Push aller Profile, die es enthielten. Eine Richtlinie stillzulegen wird zum Entfernen einer Activation.
App-Verwaltung, die sich selbst repariert
App-Management-Deklarationen haben das Fehlerbild verändert. Unter imperativem MDM blieb eine App, deren Installation scheiterte, die ein Nutzer löschte oder die mitten im Update hängen blieb, kaputt, bis jemand es merkte und eine Resynchronisierung auslöste. Eine deklarativ verwaltete App trägt ihren Soll-Zustand mit sich. Fehlt sie, installiert das Gerät sie neu. Ist sie veraltet und Auto-Update erzwungen, aktualisiert das Gerät sie. Ohne Ticket, ohne Resync, ohne Administration in der Schleife.
Die zugehörigen Steuerungen sind die, nach denen Administratoren namentlich fragen: Auto-Update erzwingen, unabhängig von der App-Store-Einstellung des Nutzers, Downloads auf WLAN beschränken, damit ein Außendienst-Team sein Datenvolumen nicht für ein 400-MB-Update verbraucht, und eine verwaltete App sperren oder verbergen, damit sie nicht entfernt werden kann.
Weniger Server, weniger Fehlersuche
Die Serverlast sinkt, was wie eine Fußnote der Infrastruktur klingt, bis Sie einige tausend Endgeräte überschreiten und Ihr MDM unter seinen eigenen Abfragen zu keuchen beginnt. Und wenn doch etwas bricht, sagt Ihnen ein spontaner Statusbericht, was sich geändert hat und wann, ohne dass Sie eine Abfrage bauen müssen.
Was sich für die Person am Gerät ändert
Über DDM wird fast immer von der Konsole aus gesprochen. Aber die Menschen, die diese Geräte tragen, spüren die Veränderung ebenfalls, und was sie erleben, entscheidet darüber, ob Ihr Rollout als Verbesserung in Erinnerung bleibt oder als Störung.
Updates hören auf, aus dem Hinterhalt zu kommen
Das alte Ende war ein 60-Sekunden-Countdown und ein Neustart, oft mitten in etwas Wichtigem. Das deklarative Software-Update ersetzt den Hinterhalt durch eine Landebahn. Benachrichtigungen können bis zu 14 Tage vor der Frist beginnen, und Sie bestimmen Häufigkeit und Wortlaut. Aufschubfenster reichen von 1 bis 90 Tagen, und Sie können für ein kleines Update und für ein großes OS-Upgrade unterschiedliche Fristen setzen.
Das gute Ergebnis ist das langweilige: Der Mac lädt und installiert in einem Zeitfenster, in dem ihn niemand braucht, und der Nutzer sieht überhaupt keinen Countdown. Sein Rechner ist einfach aktuell. Und wenn die Frist doch kommt, kommt sie als letzter Schritt eines Gesprächs, an dem der Nutzer seit zwei Wochen beteiligt ist, nicht als Überraschung.
Apps, die sich leise reparieren
Aus Nutzersicht bedeutet selbstheilendes Deployment: Die App, die man braucht, ist da, in der vorgesehenen Version, ohne ein Ticket mit der Erklärung, dass sie verschwunden ist. Die WLAN-Beschränkung zählt hier ebenfalls. Niemand möchte sein privates Datenvolumen am Flughafen für das Update einer verwalteten App ausgeben.
Weniger Unklarheit darüber, was die IT sieht
Dieser Punkt ist subtil und gehört laut ausgesprochen, gerade in Deutschland, wo BYOD zuerst eine Datenschutzfrage ist und erst danach eine technische. Deklarationen beschreiben eine Absicht und sind durch die Management-Deklaration begrenzt. Auf einem privaten Gerät wird die Grenze zwischen verwaltet und privat vom Registrierungstyp gezogen, nicht von der Abfragefrequenz des Servers. Diese Grenze klar erklären zu können, ist die halbe Arbeit in einem BYOD-Programm, und sie ist auch der Kern der Nachweispflichten, die wir im Leitfaden zu NIS2 und mobilen Endgeräten aufschlüsseln.
Software-Updates: der Fall, der sich selbst löst
Das ist der Bereich mit dem höchsten Nutzen, derjenige, dessen imperativen Weg Apple geschlossen hat, und der am leichtesten vorzeigbare.
Eine deklarative Update-Configuration nimmt eine Ziel-OS-Version und ein Durchsetzungsdatum. Von da an gehört dem Gerät der Ablauf: Verfügbarkeit prüfen, im Hintergrund laden, den Nutzer nach Ihrem Zeitplan benachrichtigen, installieren, neu starten. Fortschritt und Fehlerzustände kommen über den Statuskanal zurück, ein hängendes Gerät ist also als Zustand sichtbar und nicht als fehlende Bestätigung.
Wie schnell aus einer nicht aktualisierten App eine Schwachstelle wird, zeigt unsere Analyse zu veralteten Apps in der Geräteflotte.
Was in iOS 27, iPadOS 27 und macOS 27 neu ist
Die WWDC 2026 war die Ausgabe, auf der Apple aufgehört hat, DDM zu erweitern, und angefangen hat, Dinge dorthin zu verschieben. Angekündigt am 8. Juni 2026 und ausgeliefert im September 2026, bringen die 27er-Versionen die bislang größte Verlagerung von Funktionen aus klassischen Profilen heraus.
Das Netzwerk ist umgezogen. Sechs neue Configurations ersetzen die alten Netzwerk-Payloads: network.vpn-plugin, network.ikev2, network.ipsec, network.always-on, network.dns-proxy, network.dns-settings und network.relay. Wenn Sie VPN-Profile von Hand pflegen, verändert diese Arbeit dieses Jahr ihre Form.
Der Web-Content-Filter ist umgezogen, nach webcontent-filter.plugin. Content Caching auf supervised Macs wechselt zu content-cache.settings und ersetzt das alte Profil com.apple.AssetCache.managed.
Siri, Apple Intelligence und Tastatureinstellungen verlassen das Restriktionen-Payload in Richtung siri.settings, intelligence.settings, external-intelligence.settings und keyboard.settings. Die entsprechenden Restriktionsschlüssel gelten seit den 26.4-Versionen als veraltet, das Migrationsfenster ist also schon eine Weile offen.
Klassische Profile lassen sich jetzt als Assets ausliefern. Ein ProfileAssetReference lässt eine Legacy- oder Interactive-Profildeklaration auf ein gehostetes Profil zeigen. Damit wird „wir haben noch vierzig nicht konvertierte Profile“ zur Zwischenstufe statt zum Blocker.
Neue Statuselemente sind dazugekommen: mdm.enrollment-type, mdm.is-awaiting-configuration, mdm.is-return-to-service, device.system.health und security.lockdown-mode. Das ist Treibstoff für Prädikate. Eine Configuration am Registrierungstyp oder am Lockdown-Modus festzumachen, ausgewertet auf dem Gerät, streicht eine ganze Kategorie serverseitiger Gruppenlogik.
Und die Schlagzeile noch einmal, weil an ihr ein Datum hängt: Die klassische Verwaltung von Software-Updates funktioniert in keinem 27.0-Betriebssystem mehr, samt der zugehörigen Befehle, Abfragen und Restriktionen.
Was DDM nicht ändert
Die Registrierung. Geräte kommen weiterhin über Automated Device Enrollment und Apple Business Manager herein, und DDM läuft auf diesem Fundament. Wenn Ihre ABM-Einrichtung unordentlich ist, wird deklarative Verwaltung sie nicht aufräumen.
Ihr MDM bleibt außerdem das, was die Deklarationen ausliefert. Das ist also kein Werkzeug, das Sie ablegen. Was sich ändert, ist die Art, wie Ihr bestehendes Werkzeug mit Geräten spricht. Und DDM läuft neben imperativem MDM, statt es über Nacht zu ersetzen. Wenn die umliegenden Abkürzungen verschwimmen, ordnet unser Leitfaden zu Apple MDM Registrierung, Richtlinien und App-Verteilung ein.
Was Appaloosa für Sie übernimmt
Die Migrationsreihenfolge, den Konflikt zwischen einer Deklaration und einem alten Profil, die Frage, welches Gerät was kann: Darum kümmert sich Appaloosa transparent. Richtlinien, die Sie bereits konfiguriert haben, werden auf kompatiblen Geräten deklarativ ausgeliefert, Geräte auf älteren Versionen bekommen weiterhin die imperative Entsprechung. Sie wählen kein Modell pro Gerät und pflegen keine zwei Richtliniensätze.
Zwei Entscheidungen bleiben bei Ihnen, weil sie betrieblich und nicht technisch sind. Zielen Sie auf eine konkrete OS-Version statt auf „die neueste“, damit Ihre Geräteflotte auf einem bekannten Build landet und der Support eine Konfiguration diagnostiziert statt sechs. Und staffeln Sie die Durchsetzungsfristen nach Gruppe, damit eine Pilotgruppe die Frist zwei Wochen vor allen anderen erreicht und die interne App findet, die bricht, bevor 3.000 Menschen sie für Sie finden.
Häufige Fragen
Müssen Geräte für DDM neu registriert werden?
Nein. DDM läuft über die bestehende MDM-Registrierung. Ist ein Gerät registriert und auf einem unterstützten OS, kann es Deklarationen empfangen.
Welche OS-Versionen brauche ich?
Die Basis für Deklarationen ist iOS 17, iPadOS 17 und macOS 14. Die Abdeckung wächst mit jeder folgenden Version, und in den 27er-Versionen werden mehrere Bereiche ausschließlich deklarativ.
Ist DDM nur für supervised Firmengeräte?
Nein, aber der Umfang unterscheidet sich. Supervised Firmengeräte haben die breiteste Abdeckung, einschließlich App-Installation. Private Geräte in der User Enrollment bekommen einen bewusst engeren Satz.
Wohin die Reise geht
Apple deutet nicht mehr an. Neue Verwaltungsfunktionen erscheinen jetzt zuerst deklarativ, bestehende wandern Version für Version mit, und mit den 27er-Betriebssystemen hat der imperative Weg begonnen zu verschwinden, statt bloß aus der Mode zu kommen. Wenn Sie Apple-Geräte in relevanter Zahl verwalten, ist die Frage nicht mehr, ob Sie DDM übernehmen. Sie ist, ob die Plattform, die Sie bereits bezahlen, es getan hat.
Appaloosa unterstützt Declarative Device Management. Der Statuskanal ist aktiv, Geräte melden Zustandsänderungen also in Echtzeit statt auf eine Abfrage zu warten, und die deklarativen Configurations decken Software-Update, verwaltete Apps, Siri und Tastatureinstellungen ab. Die Abdeckung wächst Deklaration für Deklaration und nicht in einem Block, was der ehrliche Weg ist, den Stand jeder Plattform heute zu beschreiben. Appaloosa verwaltet iPhones und iPads sowie Macs über Apple Business Manager und Automated Device Enrollment, das Registrierungsfundament, auf dem DDM aufsetzt, steht also bereits.