/* Page prose (de) */
"DistributedWhenItMatters" = "# Wann das für App-Entwickler wirklich wichtig ist\n\nSetzen wir ehrliche Erwartungen. **Die meisten iOS-App-Entwickler werden Jahre verbringen, ohne einen verteilten Actor zu schreiben**, und das ist völlig normal. Dein alltägliches Nebenläufigkeits-Werkzeug ist der Rest dieses Buchs: `async`/`await`, Tasks, Actors, `@MainActor`. Verteilte Actors sind ein Spezialistenwerkzeug, kein tägliches.\n\nWo sie *sich* ihren Platz verdienen:\n\n* **Serverseitiges Swift.**  \nWenn du Backend-Dienste in Swift baust, bieten verteilte Actors und Clustering (über Distributed Cluster) einen nativen Weg, um zustandsbehaftete Arbeit über eine Flotte von Prozessen zu verteilen.\n* **Geclusterte oder Mehrknoten-Systeme.**  \nAlles, wo identische Logik auf vielen Maschinen läuft, die sich koordinieren müssen: Das Modell wurde für genau das entworfen.\n* **Geräteübergreifende Funktionen.**  \nZukunftsgewandte Szenarien, in denen Actors auf verschiedenen Geräten direkt miteinander sprechen, könnten sich auf dieselbe Abstraktion stützen, sofern ein Actor-System vorhanden ist, das den richtigen Transport spricht.\n\nWenn nichts davon beschreibt, was du gerade baust, brauchst du keine verteilten Actors, und zu wissen, dass es sie gibt, und *wie sie denken*, ist der wertvolle Teil. Wenn du eines Tages in einer serverseitigen Codebasis auf `distributed actor` triffst, wird es kein Rätsel sein: Es ist der Actor, den du bereits verstehst, mit einem Netzwerk in der Mitte und `try` vor jedem Aufruf.\n\n[Zurück](@previous)  |  Seite 8 von 9  |  [Weiter: Zusammenfassung](@next)";
