Wie erstellen Sie mehrsprachige UI-Vorschauen in Xcode 27? Lokalisierungsabnahme 2026

Die Xcode-27-Release-Notes führen Vorschauen in unterschiedlichen Lokalisierungsumgebungen ausdrücklich auf.

Symptom: Eine übersetzte Beschriftung passt nicht in die Schaltfläche oder die Anordnung wirkt in einer anderen Sprache falsch.
Schnellster Weg: Bereiten Sie zuerst die Zielsprache vor, prüfen Sie das Layout in der Xcode-Vorschau und bestätigen Sie Sprache, Region und Verhalten anschließend im Simulator oder auf einem Gerät. Eine Vorschau ersetzt keine Laufzeitabnahme.

Diese Anleitung ist für Sie, wenn Sie Übersetzungen für eine App ergänzen oder aktualisieren und die Oberfläche vor einem Build prüfen möchten.
Sie verwenden SwiftUI oder Interface Builder und möchten wissen, welcher Vorschauweg zu Ihrem Projekt passt.
Oder Sie arbeiten in einem kleinen Team und möchten entscheiden, welche Lokalisierungsprüfungen auf einem Remote Mac sinnvoll sind.

Zuletzt geprüft am 14.10.2026 anhand der Xcode-27-Release-Notes und der aktuellen Apple-Dokumentation zu Vorschau, Lokalisierung und Laufzeittests.

Vorschau und Laufzeit: zwei verschiedene Abnahmen

Die mehrsprachige UI-Vorschau in Xcode 27 ist der schnelle Weg, um sichtbare Layoutprobleme während der Entwicklung zu finden. Sie beantwortet jedoch nicht allein, ob die App beim tatsächlichen Start die richtige Sprache und Region verwendet oder ob alle Ressourcen korrekt eingebunden sind. Behandeln Sie Vorschau und Laufzeittest daher als getrennte Prüfschritte.

Das ist wichtig, weil ähnliche Symptome verschiedene Ursachen haben können. Ein abgeschnittener Text kann auf eine zu starre Breite hindeuten; eine unverändert englische Beschriftung kann bedeuten, dass die Übersetzung fehlt oder die Vorschau noch in der Standardsprache läuft. Eine falsch ausgerichtete arabische Oberfläche kann wiederum ein Layoutproblem sein, obwohl die übersetzten Texte angezeigt werden.

Für die Abnahme sollten Sie drei Ergebnisse auseinanderhalten:

• Vorschau bestanden: Die betrachteten Ansichten zeigen keine offensichtlichen Text- oder Anordnungsfehler.
• Laufzeitprüfung bestanden: Die App wurde mit der vorgesehenen Sprache und Region gestartet und verhält sich in dieser Umgebung wie erwartet.
• Für die Lokalisierungsfreigabe bereit: Zusätzlich sind Ressourcen, Übersetzungsqualität und relevante Abläufe geprüft.

Die Apple-Anleitung zu Lokalisierungsvorschauen beschreibt, wie Sie Ansichten in unterschiedlichen Lokalisierungsumgebungen prüfen. Für die tatsächliche Ausführung nennt Apple einen gesonderten Ablauf zum Testen der Lokalisierung beim Start der App. Das sind keine austauschbaren Prüfungen.

Vor der Vorschau: Ressourcen und Zielumgebung abgleichen

Bevor Sie eine Ansicht umstellen, kontrollieren Sie, ob die gewünschte Sprache im Projekt vorgesehen ist und die zugehörigen Ressourcen verfügbar sind. Wenn Sie Übersetzungen aus einem Lokalisierungsprozess übernehmen, prüfen Sie auch, ob sie in das richtige Projekt beziehungsweise Target importiert wurden. Apples Dokumentation zum Importieren von Lokalisierungen in Xcode beschreibt diesen Schritt; die Übersicht zum Hinzufügen von Sprachen und Regionen hilft bei der Projektkonfiguration.

Unterscheiden Sie vor dem Test drei Fehlerbilder:

• Ressource fehlt: Ein Schlüssel oder eine Übersetzung ist im Projekt nicht vorhanden oder nicht dem erwarteten Target zugeordnet.
• Vorschau nicht umgestellt: Die Ansicht zeigt weiterhin die Standardsprache, obwohl Sie eine andere Lokalisierung prüfen möchten.
• Übersetzung vorhanden, aber ungeeignet: Der Text erscheint in der Zielansicht, ist jedoch zu lang, unklar oder im Kontext fachlich falsch.

Diese Trennung verhindert, dass Sie eine fehlende Übersetzung als Fehler der Vorschaufunktion behandeln. Sie verhindert auch den umgekehrten Irrtum: Eine korrekt umgestellte Vorschau beweist nicht, dass die Qualität der Übersetzung stimmt.

Wie wählen Sie die gewünschte Sprache für eine Xcode-Vorschau?

Wählen Sie die Sprache, die Sie tatsächlich abnehmen möchten, und notieren Sie zusätzlich die Region, wenn Formatierung oder regionale Varianten für die App relevant sind. Sprache und Region können unterschiedliche Auswirkungen haben: Übersetzte Beschriftungen betreffen den Text, während regionale Einstellungen beispielsweise Datums- oder Zahlenformate beeinflussen können. Prüfen Sie deshalb nicht nur, ob der richtige Text erscheint.

Wenn eine Sprache im Vorschau-Menü nicht verfügbar ist, gehen Sie nicht sofort von einem Xcode-Fehler aus. Kontrollieren Sie zuerst, ob die Lokalisierung im Projekt eingerichtet und die passende Ressource vorhanden ist. Prüfen Sie anschließend, ob Sie in der Vorschau tatsächlich die gewünschte Umgebung ausgewählt haben. Xcode-Versionen und Projektkonfigurationen können sich unterscheiden; wenn eine Funktion fehlt, gleichen Sie die verfügbaren Optionen mit den Release-Notes für Ihre installierte Xcode-Version ab.

Für ein Projekt mit gemeinsam verwendeten Zeichenfolgen ist es außerdem sinnvoll, einzelne Ansichten mit denselben Lokalisierungsbedingungen zu vergleichen. So erkennen Sie, ob ein Problem nur in einer bestimmten Ansicht auftritt oder ob eine Ressource projektweit nicht wie erwartet aufgelöst wird. Halten Sie die Testbedingung fest, bevor Sie die Ansicht ändern: Sprache, Region, betroffene Ansicht und sichtbares Symptom gehören zusammen.

SwiftUI oder Interface Builder: den passenden Prüfweg wählen

Beide Wege helfen Ihnen bei der Layoutkontrolle, aber sie passen zu unterschiedlichen Projektteilen. Die SwiftUI-Vorschau ist auf deklarative Ansichten ausgerichtet. Interface Builder zeigt dagegen die in Storyboards oder XIB-Dateien aufgebauten Oberflächen. Wählen Sie nicht einen Weg für das gesamte Projekt, wenn darin beide UI-Techniken vorkommen.

Die Tabelle ist eine Auswahlhilfe, kein Qualitätsurteil über ein UI-Framework. Für ein gemischtes Projekt prüfen Sie jede Ansicht im Werkzeug, in dem sie gepflegt wird, und führen danach die Laufzeitprüfung in der App durch.

SwiftUI Preview localization: Wie stellen Sie die App-Sprache um?

Bei SwiftUI prüfen Sie die View mit der vorgesehenen Locale. Eine Vorschau kann die Umgebung über die Locale-Eigenschaft erhalten; das folgende Beispiel zeigt eine Ansicht mit einer arabischen Locale und einer ausdrücklich gesetzten Rechts-nach-links-Richtung:

#Preview {
    ContentView()
        .environment(\.locale, Locale(identifier: "ar"))
        .environment(\.layoutDirection, .rightToLeft)
}

Verwenden Sie in Ihrem Projekt die Locale, die Sie tatsächlich abnehmen möchten. Die gesetzte Locale beeinflusst lokalisierte Inhalte in der Vorschau; die Layout-Richtung ist eine gesonderte Umgebungsbedingung. Apples Dokumentation zur SwiftUI-Eigenschaft für die Layout-Richtung beschreibt diese Einstellung. Verlassen Sie sich bei RTL-Sprachen nicht darauf, dass sich die gesamte Anordnung allein durch den Austausch des Textes korrekt umkehrt.

Gehen Sie die Ansicht systematisch durch. Prüfen Sie zuerst, ob der lokalisierte Text angezeigt wird. Beobachten Sie anschließend, ob längere Bezeichnungen umbrechen oder abgeschnitten werden, ob Schaltflächen ihre Funktion noch verständlich vermitteln und ob die Reihenfolge der Inhalte eine klare Hierarchie erhält. Bei RTL kontrollieren Sie zusätzlich Ausrichtung, Navigationsrichtung, Symbole mit Richtungsbedeutung und die Position von Bedienelementen. Ein links gerichteter Pfeil ist nicht in jedem Kontext automatisch passend, nur weil der Text nun von rechts nach links läuft.

Wenn die Vorschau eine unerwartete Zeichenfolge zeigt, unterscheiden Sie zwischen einem fehlenden Eintrag und einer bewusst nicht lokalisierten Ressource. Apples Dokumentation zum Vorbereiten einer Oberfläche für die Lokalisierung behandelt die Vorbereitung lokalisierbarer Oberflächen. Die Vorschau ist dann nützlich, wenn sie Ihnen eine konkrete Stelle zum Nachbessern zeigt; sie kann keine fehlende Übersetzungsentscheidung für Sie treffen.

Kann Interface Builder Pseudosprachen für die Layoutprüfung anzeigen?

Eine Pseudolokalisierung kann beim Auffinden von Layoutannahmen helfen, ohne dass Sie für jeden Durchlauf eine fertige Übersetzung benötigen. Ob und wie eine solche Option in Ihrer installierten Xcode-Version für das jeweilige Interface-Builder-Projekt verfügbar ist, prüfen Sie in den Vorschauoptionen und in der zugehörigen Apple-Dokumentation. Die von Apple dokumentierten Vorschau- und Lokalisierungsfunktionen finden Sie in der Anleitung zu Lokalisierungsvorschauen.

Behandeln Sie eine Pseudolokalisierung als Belastungstest für die Oberfläche, nicht als Ersatz für die gewünschte Zielsprache. Sie kann sichtbar machen, ob ein Label zu wenig Platz hat oder ein Constraint keine längere Zeichenfolge zulässt. Sie belegt jedoch nicht, dass die echte Übersetzung korrekt, natürlich oder kulturell angemessen ist. Prüfen Sie Storyboards und XIB-Dateien in der passenden Vorschau und starten Sie die App anschließend mit der vorgesehenen Sprache und Region.

Vom sichtbaren Fehler zur reproduzierbaren Korrektur

Eine Vorschauabweichung hilft erst dann, wenn Sie sie nachvollziehbar festhalten. Notieren Sie für jedes Problem die betroffene Ansicht, die gewählte Sprache und Region sowie die Bedingung, unter der es auftritt. Formulierungen wie „Layout kaputt“ reichen nicht: Schreiben Sie beispielsweise auf, dass die Beschriftung in einer bestimmten Schaltfläche bei der ausgewählten Sprache abgeschnitten wird oder dass ein richtungsabhängiges Symbol in der RTL-Ansicht unpassend bleibt.

Ordnen Sie den Befund einer Ursache zu, bevor Sie Änderungen vornehmen:

• Text wird abgeschnitten: Prüfen Sie feste Breiten, einzeilige Beschränkungen und den verfügbaren Platz für Übersetzungen.
• Layout kann sich nicht anpassen: Prüfen Sie Constraints, Abstände und die Annahme, dass jede Bezeichnung dieselbe Länge hat.
• RTL-Richtung passt nicht: Prüfen Sie Layout-Richtung und richtungsabhängige Bedienelemente unabhängig vom Text.
• Ressource fehlt oder bleibt unverändert: Prüfen Sie Lokalisierungsdateien, Schlüssel und Zuordnung zum richtigen Projektbereich.

Ändern Sie gezielt die vermutete Ursache und kehren Sie danach zu denselben Vorschau-Bedingungen zurück. Wenn Sie gleichzeitig Locale, Layout und Textressourcen ändern, lässt sich schwer erkennen, welche Änderung den Fehler behoben hat. Bei einem Layoutproblem sollte die Prüfung nach der Korrektur dieselbe View und dieselbe Zielsprache verwenden. Bei einer fehlenden Ressource muss die Vorschau nach dem Import beziehungsweise der Anpassung erneut kontrolliert werden.

Checkliste: Ist die Vorschau als Layoutprüfung aussagekräftig?

• [ ] Die Zielsprache ist im Projekt eingerichtet und die benötigten Ressourcen sind vorhanden.
• [ ] Die Vorschau zeigt die gewünschte Lokalisierung und nicht versehentlich die Standardsprache.
• [ ] Sprache und Region sind für den Prüffall festgehalten.
• [ ] Längere Texte, Umbrüche, Schaltflächen und Inhaltshierarchie wurden geprüft.
• [ ] Bei einer RTL-Sprache wurden Layout-Richtung und richtungsabhängige Symbole gesondert kontrolliert.
• [ ] Für Storyboards oder XIB-Dateien wurde Interface Builder verwendet; SwiftUI-Views wurden in ihrer SwiftUI-Vorschau geprüft.
• [ ] Jeder gefundene Fehler ist mit Ansicht, Sprache, Region und Reproduktionsbedingung dokumentiert.
• [ ] Nach der Korrektur wurde dieselbe Vorschau-Bedingung erneut geprüft.
• [ ] Die Laufzeitprüfung im Simulator oder auf einem Gerät ist separat eingeplant.

Diese Liste ist bestanden, wenn Sie die Bedingungen reproduzieren und die sichtbaren Layoutmängel nachvollziehbar beurteilen können. Sie bescheinigt weder korrekte Übersetzungen noch die vollständige Laufzeitfunktion der App.

Vorschau bestanden oder App abgenommen: im Simulator weiterprüfen

Nach einer erfolgreichen Vorschau starten Sie die App mit der vorgesehenen Sprache und Region im Simulator oder auf einem Gerät. Prüfen Sie dort die tatsächliche Navigation und die Ansichten, die Sie zuvor in der Vorschau kontrolliert haben. Achten Sie auf fehlende Ressourcen, abweichende Texte und Formatierungen, die erst beim Start oder innerhalb eines Ablaufs sichtbar werden. Apples Anleitung zum Testen von Lokalisierungen beim Ausführen der App beschreibt diesen getrennten Laufzeitschritt.

Bei RTL-Sprachen reicht eine statische Kontrolle einzelner Textblöcke besonders wenig aus. Navigieren Sie durch die relevanten Ansichten und prüfen Sie, ob Bedienelemente, Symbole und Bewegungsrichtungen zur gewählten Sprache passen. Wenn Sie eine Sprache nicht sicher beurteilen können, lassen Sie die Übersetzungsqualität von einer Person mit passenden Sprachkenntnissen prüfen. Eine technisch korrekte Darstellung garantiert keine idiomatische Formulierung.

Auch der Begriff „Abnahme“ sollte deshalb präzise bleiben. „Vorschau bestanden“ heißt, dass die geprüfte Darstellung im Vorschaukontext keine bekannten Layoutfehler zeigt. „Laufzeitprüfung bestanden“ heißt, dass Sie die App unter den vorgesehenen Sprach- und Regionsbedingungen tatsächlich ausgeführt haben. Erst wenn zusätzlich die Ressourcen und die sprachliche Qualität geprüft sind, ist die Lokalisierung für eine Veröffentlichung ausreichend vorbereitet.

Xcode läuft auf macOS. Wenn Sie keinen geeigneten Mac für die regelmäßige Vorschau und Laufzeitprüfung zur Verfügung haben, können Sie lokale Mac-Hardware, eine andere macOS-Umgebung oder einen Remote Mac gegeneinander abwägen. Ein eigener Mac ist sinnvoll, wenn Sie dauerhaft eine feste Entwicklungsmaschine benötigen; andere Umgebungen können bei Datenschutzvorgaben, Verbindungsbedingungen oder dem Bedarf an lokal angeschlossenen Geräten besser passen. Für die Einordnung von Hardwarezugriff und Virtualisierung lesen Sie den Vergleich von Bare Metal und macOS-Virtualisierung.

Wenn Sie eine entfernte Mac-Umgebung erwägen, prüfen Sie vorab, ob die benötigte Xcode-Version verfügbar ist, wie Sie auf den Mac zugreifen und ob Ihre Projekt- und Datenschutzvorgaben damit vereinbar sind. Details zu den möglichen Kosten können Sie anhand der Übersicht zu Bare-Metal-macOS-Preisen prüfen. Eine Mietlösung ist nicht automatisch die richtige Wahl für dauerhaft hohe Auslastung oder für Tests, die lokale physische Anschlüsse voraussetzen.

Für wiederkehrende Lokalisierungsprüfungen ohne eigenen geeigneten Mac kann ein von MacDate gemieteter Mac eine flexible Testumgebung sein. Prüfen Sie zuerst die verfügbare Xcode-Umgebung und den angebotenen Fernzugriff, bevor Sie Ihre Abnahme darauf verlagern. Wenn Sie nur gelegentlich eine Ansicht kontrollieren und bereits einen passenden Mac besitzen, ist die lokale Prüfung meist der direktere Weg; wenn Ihnen dagegen eine nutzbare Mac-Umgebung fehlt, vergleichen Sie die Bedingungen bei MacDate mit Ihrem tatsächlichen Testbedarf.