Die Widget-Oberfläche von iOS 26: Ein App Intent, viele Orte

Jahrelang war ein Widget eine Momentaufnahme. Das System renderte Ihre Ansicht auf einer Timeline, die Benutzer sahen sie an, und jeder Tippvorgang öffnete die App. Dieses Modell ist Geschichte. Seit iOS 17 kann ein Widget Buttons und Schalter tragen, die Code ausführen, ohne irgendetwas zu starten – und der Code, den sie ausführen, ist ein App Intent¹. Dasselbe gilt für Control-Center-Steuerelemente und für die Buttons innerhalb einer Live Activity. Sobald Ihnen das klar wird, hört die Widget-Oberfläche von iOS 26 auf, wie drei separate APIs auszusehen, und beginnt, wie eine einzige zu wirken: eine Reihe von Orten, an denen das System Ihre App Intents rendert, jeder mit anderem Platzangebot und derselben Mechanik darunter.

Genau diese Neubetrachtung ist der Kern dieses Beitrags. Lernen Sie den App Intent einmal, und Sie aktivieren den Home Screen, den Lock Screen, das Control Center, den Action Button, die Dynamic Island und (derselbe Intent erneut) Siri sowie Apple Intelligence. Schreiben Sie drei voneinander getrennte Funktionen, leisten Sie die vierfache Arbeit für ein schlechteres Ergebnis.

Kurzfassung

• Interaktive Widgets (iOS 17+): Platzieren Sie einen Button(intent:) oder Toggle(isOn:intent:) in einer Widget-Ansicht; das System führt die perform()-Methode des App Intent in Ihrer Widget-Extension aus, außerhalb der App, und lädt anschließend die Timeline neu¹.
• Control-Center-Steuerelemente (iOS 18+): Ein ControlWidget, aufgebaut aus ControlWidgetButton oder ControlWidgetToggle und gestützt auf dieselben App Intents, erscheint im Control Center, auf dem Lock Screen und auf dem Action Button².
• Live Activities (ActivityKit): ActivityAttributes zusammen mit einer ActivityConfiguration treiben den Lock Screen und die Dynamic Island an; serverseitig gesteuerte Aktualisierungen treffen über Push ein, und auch die Buttons darin sind App Intents³.
• iOS 26 fügt das Rendering hinzu, nicht das Modell: Widgets übernehmen die Liquid-Glass-Darstellung und akzentuierte Rendering-Modi, doch die Architektur „App Intents als Oberfläche” ist gegenüber iOS 18 unverändert⁴.
• Die verbindende Tatsache: Ein Widget-Button, ein Steuerelement, ein Siri-Satz und eine Apple-Intelligence-Aktion können alle derselbe App Intent sein. Entwerfen Sie die Fähigkeit ein einziges Mal.

Interaktive Widgets: Der Button, der die App nicht öffnet

Der Mechanismus ist schlank und verdient eine genaue Beschreibung. Sie fügen einer Widget-Ansicht einen SwiftUI-Button oder -Toggle hinzu, übergeben aber statt eines Aktions-Closures einen App Intent¹:

struct WaterWidgetView: View {
    let logged: Int

    var body: some View {
        VStack {
            Text("\(logged) glasses")
            Button(intent: LogWaterIntent()) {
                Label("Add", systemImage: "plus")
            }
        }
    }
}

Wenn die Benutzer tippen, führt das System LogWaterIntent.perform() innerhalb Ihrer Widget-Extension aus. Die App startet nicht. Der Intent erledigt seine Arbeit (in den geteilten Speicher schreiben, einen Zähler aktualisieren), und die Widget-Timeline lädt neu, um das Ergebnis anzuzeigen.

Ein Toggle funktioniert auf dieselbe Weise über einen SetValueIntent, der den neuen Ein-/Aus-Wert empfängt, den die Benutzer gerade gesetzt haben:

struct ToggleReminderIntent: SetValueIntent {
    static let title: LocalizedStringResource = "Toggle Reminder"

    @Parameter(title: "Enabled")
    var value: Bool

    func perform() async throws -> some IntentResult {
        ReminderStore.shared.enabled = value
        return .result()
    }
}

Das Widget bindet Toggle(isOn: store.enabled, intent: ToggleReminderIntent()), das System setzt value auf den neuen Zustand, führt perform() aus und lädt neu. Dieselbe Form wie der Button, ein zusätzlicher Parameter¹.

Zwei Einschränkungen bestimmen, was hier möglich ist, und beide lassen sich leicht verletzen. Erstens läuft perform() in der eingeschränkten Umgebung der Widget-Extension mit einem knappen Ausführungsbudget; es ist für eine schnelle Zustandsänderung gedacht, nicht für einen Netzwerk-Upload oder schwere Berechnungen. Zweitens spiegelt das Widget einen Zustand wider, es animiert keine beliebige UI. Sie ändern Daten, und die Timeline rendert neu; Sie führen keinen eigenen Übergang aus. Entwerfen Sie die Interaktion als „einen Wert umlegen, den neuen Wert anzeigen”, und sie funktioniert. Greifen Sie nach mehr, kämpft das System gegen Sie.

Control-Center-Steuerelemente: Derselbe Intent, ein anderer Raum

iOS 18 öffnete das Control Center, den Lock Screen und den Action Button für Steuerelemente von Drittanbietern, und die API ist bewusst parallel zu Widgets aufgebaut². Ein Steuerelement ist ein ControlWidget, und sein Body ist ein ControlWidgetButton oder ControlWidgetToggle, der mit einem App Intent verdrahtet ist:

struct LogWaterControl: ControlWidget {
    var body: some ControlWidgetConfiguration {
        StaticControlConfiguration(kind: "com.example.logWater") {
            ControlWidgetButton(action: LogWaterIntent()) {
                Label("Log Water", systemImage: "drop.fill")
            }
        }
    }
}

Wenn LogWaterIntent bereits Ihr interaktives Widget antreibt, kostet das Steuerelement nahezu nichts: derselbe Intent, eine neue Hülle. Genau hier zahlt sich die Architektur aus. Das Steuerelement ist keine zweite Implementierung der Funktion; es ist ein zweiter Montagepunkt für jene, die Sie bereits geschrieben haben. Ein Toggle-Steuerelement nutzt SetValueIntent genauso wie der Widget-Toggle, sodass eine einmal gebaute Fähigkeit für „Stummschalten”, „Sitzung starten” oder „Dark Mode umschalten” im Control Center, auf dem Lock Screen und auf dem Action Button erscheint – ohne neue Logik².

Live Activities: Die Oberfläche, die sich selbst aktualisiert

Live Activities sind der dritte Ort, und der mit den meisten beweglichen Teilen. Ein ActivityAttributes-Typ definiert die statischen und dynamischen Inhalte, eine ActivityConfiguration rendert die Darstellung auf dem Lock Screen und die Bereiche der Dynamic Island, und ActivityKit startet, aktualisiert und beendet die Activity³. Die Buttons innerhalb einer Live Activity sind, wiederum, App Intents, sodass ein „Pause”- oder „Weiter”-Steuerelement in der Dynamic Island dieselbe Art von Intent ausführt wie der Widget-Button.

Was Live Activities zu einer eigenen Disziplin macht, ist der Aktualisierungspfad. Ein Timer, den Sie lokal aktualisieren, ist einfach. Eine Activity, die von Ereignissen auf einem Server gesteuert wird (eine Lieferung, die sich bewegt, ein Spielstand, der sich ändert), aktualisiert sich über Push: Sie registrieren sich für pushTokenUpdates, senden ActivityKit-Push-Payloads von Ihrem Backend, und das System aktualisiert den Lock Screen und die Dynamic Island, ohne dass Ihre App überhaupt läuft³. Das ist wahrhaft mächtig und wahrhaft leicht falsch zu machen, denn nun hängt die Korrektheit Ihrer Activity von einem Serververtrag, der Zuverlässigkeit der Pushes und einer Veralterungsrichtlinie ab, nicht nur von lokalem Code.

Was iOS 26 tatsächlich geändert hat

Die Schlagzeile für die Widgets in iOS 26 lautet Darstellung, nicht Architektur. Widgets übernehmen das Liquid-Glass-Material und erhalten akzentuierte Rendering-Modi, sodass sie zur neuen Designsprache des Systems passen und in den Kontexten, in denen das OS Inhalte umfärbt, korrekt eingefärbt werden⁴. Das ist wichtig dafür, wie ein Widget über Home Screen, Lock Screen und StandBy hinweg aussieht, und einen Design-Durchgang wert. Es ändert nichts daran, wie Interaktivität funktioniert. Wenn Sie interaktive Widgets und Steuerelemente auf iOS 18 gebaut haben, ist der Schritt zu iOS 26 eine optische Auffrischung, kein Neuaufbau. Begegnen Sie Behauptungen, iOS 26 habe interaktive Widgets „eingeführt”, mit Misstrauen; die Interaktivität kam in iOS 17, die Steuerelemente in iOS 18, und iOS 26 ließ sie wie den Rest des Systems aussehen.

Die gestalterische Konsequenz von Liquid Glass ist allerdings real. Ein Widget ist Inhalt, den das System über das Hintergrundbild komponiert und durch eine Glas-Chrome bricht, sodass dieselben Regeln gelten, die Liquid Glass in einer App bestimmen: Respektieren Sie die Schichtung von Funktion und Inhalt, und kämpfen Sie nicht gegen das Material mit schweren, eigenen Hintergründen, die das Glas nicht lesen kann.

Die Architektur, schlicht ausgesprochen

Hier ist das Modell, das es zu behalten lohnt. Ein App Intent ist eine benannte, typisierte, beschriebene Fähigkeit. iOS gibt Ihnen eine wachsende Anzahl von Orten, an denen Sie diese Fähigkeit montieren können:

• Ein Button oder Toggle innerhalb eines Widgets.
• Ein ControlWidget im Control Center, auf dem Lock Screen und auf dem Action Button.
• Ein Button innerhalb einer Live Activity und ihrer Dynamic Island.
• Ein Siri-Satz und eine Shortcuts-Aktion.
• Eine Aktion, die Apple Intelligence im Auftrag der Benutzer aufrufen kann⁵.

Jeder einzelne davon ist derselbe AppIntent-Typ mit einer perform()-Methode. Die Arbeit liegt darin, diese Fähigkeit gut zu entwerfen: ein klarer Name, typisierte Parameter, eine schnelle und idempotente perform()-Methode und ein sinnvolles Ergebnis. Tun Sie das einmal, und die Oberflächen sind bloße Hüllen. Das ist dasselbe Argument, das ich über App Intents als die eigentliche API zu Ihrer App und über die drei Oberflächen vorgebracht habe, die eine iOS-App heute freilegt: Die Widget-Oberfläche ist keine Funktion, die Sie bauen, sie ist ein Ort, an dem Ihre Fähigkeiten auftauchen, sobald sie existieren.

Wann es sich nicht lohnt

Die Widget-Oberfläche belohnt Apps mit echtem, auf einen Blick erfassbarem Zustand und schnellen Aktionen: einen Tracker, einen Timer, einen Schalter, ein Now-Playing-Steuerelement. Sie belohnt nicht alles.

• Kein auf einen Blick erfassbarer Zustand, kein Widget. Wenn Ihre App nichts zu zeigen hat, das ohne Öffnen einen Wert hätte, ist ein Widget Dekoration, die Sie Wartung und ein zusätzliches Extension-Ziel kostet.
• Schwere oder langsame Aktionen gehören hier nicht in perform(). Die Ausführungsumgebung von Widget und Steuerelement ist eingeschränkt. Braucht die Aktion echte Zeit oder echte Rechenleistung, sollte der Button die App in einen vorbereiteten Zustand öffnen, nicht vorgeben, die Arbeit in der Extension zu erledigen.
• Eine Live Activity für etwas, das nicht live ist. Live Activities sind für zeitlich begrenzte, sich aktiv verändernde Ereignisse gedacht. Eine als dauerhaftes Status-Abzeichen einzusetzen, verkennt die Oberfläche und ist ein schneller Weg auf die schwarze Liste des Systems beim Activity-Budget.

Das Können besteht nicht darin, drei APIs zu lernen. Es besteht darin, App Intents zu entwerfen, die es wert sind, montiert zu werden, und sie dann dort zu montieren, wo die Benutzer ohnehin schon sind: auf dem Home Screen, den sie prüfen, im Control Center, zu dem sie wischen, in der Dynamic Island, die ihnen bereits etwas zeigt. Bauen Sie die Fähigkeit einmal, mit Geschmack, und iOS reicht Ihnen die Oberflächen gratis.