So lokalisieren Sie Ihre iOS-App: SwiftUI-Internationalisierungs-Guide

Bereiten Sie Ihre Xcode-App vor, übersetzen Sie .xcstrings mit KI und laden Sie dann Screenshots hoch, damit die PTC (Private Translation Cloud) die gerenderte iOS-App in jeder Sprache prüft. Dieser Leitfaden führt Sie durch den kompletten Workflow mit SwiftUI und Xcode 15+ String Catalogs, dem modernen, von Apple empfohlenen Weg. Eine plattformübergreifende Service-Übersicht für iOS und Android finden Sie unter iOS- und Android-Apps mit KI übersetzen.

Teil 1: Wie die iOS-Lokalisierung funktioniert

Die iOS-Lokalisierung ist der Prozess der Anpassung von Text, Formatierung und Assets Ihrer App zur Unterstützung mehrerer Sprachen und Regionen. Mit den in Xcode 15 eingeführten String Catalogs ist der Workflow wesentlich einfacher als beim alten .strings / .stringsdict-Ansatz.

Internationalisierung vs. Lokalisierung

Dies sind zwei getrennte Phasen, und sie müssen in dieser Reihenfolge ablaufen:

• Internationalisierung (i18n) ist die technische Vorarbeit. Sie strukturieren Ihren Code so, dass Text, Bilder und Formatierungen je nach Locale ohne Codeänderungen variieren können. Dies geschieht einmalig, idealerweise vor Ihrem ersten Release.
• Lokalisierung (l10n) ist die fortlaufende Arbeit, die danach folgt. Das Schreiben von Übersetzungen, das Anpassen von Layouts und die Bereitstellung Locale-spezifischer Assets für jede neue Sprache.

Der häufigste Fehler besteht darin, die Lokalisierung als eine Aufgabe für die Zeit nach dem Launch zu behandeln, nur um dann festzustellen, dass die Codebasis nicht dafür bereit ist. Im Nachhinein hardcodierte Strings, Layouts mit fester Richtung und Formatierer ohne Locale-Unterstützung in einer bestehenden App zu korrigieren, dauert viel länger, als die App von Anfang an mit Blick auf die Lokalisierung zu entwickeln.

Wie Xcode 15+ Localizable.xcstrings als Single Source of Truth nutzt

Apples Lokalisierungsmodell in Xcode 15+ konzentriert sich auf eine einzige Datei pro Target: Localizable.xcstrings. Diese Datei ist ein JSON-formatierter String Catalog, der Ihre Ausgangssprache sowie jede Übersetzung enthält, einschließlich Plural-Variationen, gerätespezifischen Variationen und Ersetzungen.

Xcode extrahiert automatisch lokalisierbare Strings aus Ihrem SwiftUI-Code (jedes Text("..."), Label("...", systemImage:), Button("...") und jede String-Interpolation, die LocalizedStringKey verwendet). Wenn Sie den Build Ihrer App ausführen, wird Localizable.xcstrings mit jedem extrahierten Quellstring gefüllt.

Apple unterstützt mehrere Formate. .strings (veraltetes Key-Value-Format), .stringsdict (veraltete Pluralformen) und .xcstrings (modern). Neue Projekte sollten mit .xcstrings beginnen. Bestehende Projekte, die auf .strings basieren, können über File > New > File > String Catalog und die Importoption von Xcode migriert werden. Apples offizielle Lokalisierungsdokumentation behandelt die gesamten Hintergründe.

Teil 2: Ihr Xcode-Projekt für die Lokalisierung einrichten

Schritt 1: Lokalisierung aktivieren. Öffnen Sie Ihr Projekt in Xcode und wählen Sie die Projektdatei im Navigator aus. Scrollen Sie unter dem Tab Info zu Localizations. Englisch ist bereits als Basissprache aufgeführt. Klicken Sie auf +, um jede Zielsprache (Spanisch, Französisch, Arabisch usw.) hinzuzufügen.

Schritt 2: Einen String Catalog erstellen. Klicken Sie mit der rechten Maustaste auf Ihr Projekt und wählen Sie New File from Template. Suchen Sie nach String Catalog und fügen Sie ihn hinzu. Behalten Sie den Standardnamen Localizable.xcstrings bei. Führen Sie den Build des Projekts einmal mit Cmd+B aus. Xcode scannt Ihren Code, findet jeden lokalisierbaren String und füllt den Katalog automatisch.

Schritt 3: Strings für die Lokalisierung markieren. In SwiftUI wird jeder literale String, der an Text(_:), Label, Button-Aktionslabels, Navigationstitel usw. übergeben wird, automatisch als LocalizedStringKey behandelt:

import SwiftUI

struct WelcomeView: View {
    let userName: String
    let unreadCount: Int

    var body: some View {
        VStack {
            Text("Welcome, \(userName)!")
            Text("You have \(unreadCount) unread messages")
            Button("Get Started") {
                // action
            }
        }
    }
}

Es gibt zwei Muster, bei denen Xcode Strings nicht automatisch extrahieren kann. Beide schlagen stillschweigend fehl:

Tipp 1: Vermeiden Sie die Übergabe von Variablen an Text. Wenn Sie eine Variable anstelle eines String-Literals an eine Text-View übergeben, behandelt SwiftUI diese als einfachen String und überspringt den Katalog-Lookup vollständig:

// NOT localized - SwiftUI treats the variable as a plain String
let title = "welcome_title"
Text(title)

// Localized correctly
Text(LocalizedStringKey(title))

Tipp 2: Verwenden Sie String(localized:) außerhalb von Views. Für Strings, die Sie in einem View-Model, einer Hilfsfunktion oder an einer beliebigen Stelle außerhalb einer SwiftUI-View lokalisieren müssen, verwenden Sie String(localized:) anstelle eines einfachen Strings:

let errorMessage = String(localized: "error_generic")

Schritt 4: Plural- und Gerätevarianten hinzufügen. Strings benötigen je nach Kontext oft unterschiedliche Formen.

Für die Pluralisierung beginnen Sie mit dem String in Ihrer SwiftUI-View:

Text("\(bookCount) books on your shelf")

Öffnen Sie den String Catalog, klicken Sie mit der rechten Maustaste auf den Key und wählen Sie Vary by Plural. Xcode generiert die Pluralkategorien automatisch und füllt sie mit dem Quellstring voraus. Für Englisch sehen Sie One und Other. Korrigieren Sie das Feld One zu "%lld book on your shelf". Markieren Sie beide als geprüft.

Wenn Sie den Katalog später an die PTC senden, wird die Pluralstruktur mit der Datei übertragen. Für Arabisch generiert die PTC Übersetzungen für alle sechs Pluralkategorien (zero, one, two, few, many, other), da die arabische Grammatik alle sechs erfordert. Spanisch benötigt zwei, genau wie Englisch.

Für Gerätevariationen (z. B. „Tap to continue“ auf dem iPhone vs. „Click to continue“ auf dem Mac) klicken Sie mit der rechten Maustaste auf den Key und wählen Sie Vary by Device. Fügen Sie die Geräte hinzu, die Sie anpassen möchten, und geben Sie für jedes den entsprechenden String ein. iOS liefert zur Laufzeit die Version aus, die zum aktuellen Gerät passt.

Teil 3: Ihre .xcstrings mit der PTC übersetzen

Bei kleinen Projekten könnten Sie jede Sprachspalte im Katalog öffnen und Übersetzungen direkt eintippen. Wenn Ihre App wächst, ist das bei Hunderten von Keys und Dutzenden von Sprachen nicht mehr machbar. Die PTC übernimmt das Hochladen, Übersetzen und Synchronisieren.

Schritt 1: Ihren String Catalog aus Xcode exportieren. Gehen Sie zu Product > Export Localizations. Xcode verpackt Ihren String Catalog in eine .xcloc-Datei pro Zielsprache. Für die PTC benötigen Sie nur die Datei .xcstrings innerhalb des Pakets .xcloc. Klicken Sie im Finder mit der rechten Maustaste auf die exportierte .xcloc und wählen Sie Show Package Contents, um Localizable.xcstrings zu finden.

Wenn Sie die Benachrichtigung „Unable to build project for localization string extraction“ sehen, verwendet Ihr Projekt reine iOS-APIs, die Xcode während der String-Extraktion nicht gegen sein internes macOS-SDK kompilieren kann. Die Lösung: Wählen Sie das Projekt-Target unter TARGETS aus, gehen Sie zu Build Settings, suchen Sie nach „Use Compiler to Extract Swift Strings“ und setzen Sie es auf No. Exportieren Sie dann erneut.

Schritt 2: Für die PTC registrieren. Die Testphase deckt 20.000 Wörter in 2 Sprachen ab, was ausreicht, um die meisten Apps zu lokalisieren. Nach der Testphase läuft die PTC über nutzungsbasierte Bezahlung (Pay-As-You-Go). Kein Abonnement, die ersten 500 Wörter jeden Monat sind kostenlos.

Schritt 3: Ihr Projekt einrichten und übersetzen. Ziehen Sie Localizable.xcstrings in die PTC. Belassen Sie den Ausgabedateinamen als Localizable.xcstrings. Xcode erwartet genau diesen Namen beim Auflösen lokalisierter Strings. Wählen Sie Ihre Zielsprachen aus.

Die PTC generiert automatisch eine Produktbeschreibung Ihrer App aus der hochgeladenen Datei. Prüfen Sie diese und bearbeiten Sie sie bei Bedarf. Wenn Sie bereits vorhandene Übersetzungsdateien haben, laden Sie diese hoch, damit die PTC Ihre Markenstimme übernehmen kann. Andernfalls übersetzen Sie von Grund auf. Fügen Sie Begriffe zum Glossar hinzu. Die PTC fügt Ihren App-Namen automatisch hinzu. Ergänzen Sie jegliche markenspezifische Terminologie, die auf eine bestimmte Weise oder gar nicht übersetzt werden soll. Klicken Sie auf Start Translation.

Schritt 4: Prüfen und herunterladen. Sobald die Übersetzung abgeschlossen ist, zeigt der Tab Translations jeden Quellstring neben seiner Übersetzung. Jeder, den Sie zum Projekt hinzufügen, kann Übersetzungen direkt bearbeiten. Wenn etwas nicht stimmt, melden Sie ein Problem mit einer bestimmten Übersetzung und fordern Sie eine kostenlose KI-Neuübersetzung an. Die PTC lernt aus dem Feedback und wendet es auf zukünftige Strings im selben Projekt an.

Wenn ein übersetzter String seine Längenbegrenzung überschreitet, wird er hervorgehoben. Sie haben drei Optionen. Akzeptieren Sie die längere Übersetzung, wenn Ihre UI Platz dafür bietet. Fordern Sie eine Neuübersetzung an, die in das aktuelle Limit passt. Passen Sie das Limit unter Einstellungen > Übersetzungslängen an.

Teil 4: Übersetzte .xcstrings in Ihr Xcode-Projekt integrieren

Sie haben drei Optionen.

Option 1: Dateien manuell von der PTC herunterladen. Gehen Sie zum Tab Resource Files und laden Sie die ZIP-Datei herunter. Sie enthält eine einzige Localizable.xcstrings mit Ihren englischen Quellstrings und allen Übersetzungen. Schließen Sie Xcode, ersetzen Sie die bestehende Localizable.xcstrings in Ihrem Projektordner durch die von der PTC und starten Sie Xcode dann neu. Ihre Übersetzungen erscheinen im String Catalog mit einem Häkchen neben jeder vollständig übersetzten Sprache.

Option 2: Mit Git integrieren. Wenn Ihr Projekt auf GitHub, GitLab oder Bitbucket gehostet wird, verbinden Sie die PTC direkt. Die Git-Integration ist eine Pro-Funktion. Aktivieren Sie Pay-As-You-Go, um darauf zuzugreifen. Gehen Sie in Ihrem PTC-Dashboard zu Einstellungen > Merge Requests und klicken Sie auf Add Git Integration. Geben Sie Ihre Repository-URL an, gewähren Sie der PTC Zugriff und wählen Sie Ihren Branch sowie die Quelldateien aus. Die PTC sendet einen Merge Request mit den Übersetzungen.

Option 3: Die API nutzen. Die API der PTC gibt Ihnen die volle Kontrolle darüber, wann und wie Übersetzungen in Ihre Build-Pipeline gezogen werden. Gehen Sie bei aktiviertem Pay-As-You-Go zu Einstellungen > API-Tokens verwalten, klicken Sie auf Add access token und konsultieren Sie dann die PTC-API-Referenz für die Endpunkte.

Ein In-App-Sprachumschalter (einige Apps benötigen dies) kann das System-Locale pro View über die SwiftUI-Umgebung überschreiben:

import SwiftUI

@MainActor
class LocaleManager: ObservableObject {
    @Published var currentLocale: Locale = .current

    func setLocale(_ identifier: String) {
        currentLocale = Locale(identifier: identifier)
        UserDefaults.standard.set([identifier], forKey: "AppleLanguages")
    }
}

struct LanguageSettingsView: View {
    @EnvironmentObject var localeManager: LocaleManager

    var body: some View {
        List {
            Button("English") { localeManager.setLocale("en") }
            Button("Español") { localeManager.setLocale("es") }
            Button("Français") { localeManager.setLocale("fr") }
        }
        .environment(\.locale, localeManager.currentLocale)
    }
}

Die Änderung von AppleLanguages zur Laufzeit erfordert für einige System-Strings einen Neustart der App. Das Überschreiben der SwiftUI-Umgebung wird für Views innerhalb dieses Scopes sofort wirksam.

Teil 5: Ihre lokalisierte iOS-App testen

Mit der Scheme-Spracheinstellung testen. Der schnellste Weg, eine bestimmte Sprache zu testen, führt über Ihr Xcode-Scheme. Gehen Sie zu Product > Scheme > Edit Scheme, klicken Sie auf den Tab Options, ändern Sie App Language und App Region in das gewünschte Locale und starten Sie mit Cmd+R. Das funktioniert für die meisten Sprachen gut. Sie sollten das gleiche Layout und Design wie auf Englisch sehen, wobei der gesamte Text ausgetauscht ist.

Arabisch und andere RTL-Sprachen testen. Die Scheme-Spracheinstellung kann im Simulator für RTL-Sprachen unzuverlässig sein. Verwenden Sie die eigenen Spracheinstellungen des Simulators:

1. Führen Sie die App mit Cmd+R aus, um den Simulator zu öffnen.
2. Drücken Sie Cmd+Home, um zum Home-Bildschirm zu gelangen.
3. Öffnen Sie Einstellungen > Allgemein > Sprache & Region.
4. Tippen Sie auf Sprache hinzufügen, wählen Sie Arabisch und legen Sie es als primäre Sprache fest.
5. Der Simulator startet neu. Öffnen Sie Ihre App vom Home-Bildschirm aus.

Prüfen Sie, ob der Text auf Arabisch erscheint und ob der Simulator das Layout korrekt spiegelt, wobei Navigationstitel und Inhalt rechtsbündig ausgerichtet sind. Für Vorschautests, ohne sich auf eine Sprache festzulegen, ist Edit Scheme > Options > Application Language > Right-to-Left Pseudolanguage eine schnellere Überprüfung. Für Tests der Textexpansion verwenden Sie Double-Length Pseudolanguage, um zu sehen, wie Layouts mit 30–40 % längeren Strings umgehen, bevor Sie sich auf eine Zielsprache festlegen.

Best Practices für die iOS-Lokalisierung

• Prüfen Sie Ihre UI auf unterschiedliche Textlängen. Deutsch ist etwa 30 % länger als Englisch. Französisch und Spanisch etwa 20 %. Nutzen Sie das flexible Layoutsystem von SwiftUI, lassen Sie Labels natürlich wachsen und umbrechen, vermeiden Sie feste Breitenbeschränkungen für Textelemente und testen Sie während der Entwicklung in einigen verschiedenen Sprachen.
• Lassen Sie Pluralisierungsvarianten nicht aus. Russisch hat drei Pluralkategorien, Arabisch hat sechs, Japanisch hat keine. String Catalogs übernehmen dies, wenn Sie die Sprache hinzufügen. Stellen Sie sicher, dass alle generierten Felder ausgefüllt sind, bevor Sie veröffentlichen.
• Lokalisieren Sie Bilder und Assets. Bilder mit Text oder kulturspezifischen visuellen Elementen benötigen lokalisierte Varianten. Wählen Sie das Bild in Assets.xcassets aus und klicken Sie im Attributes Inspector auf Localize. Wählen Sie die Sprachen aus, für die Sie Varianten wünschen, und ersetzen Sie jede durch die entsprechende Version. iOS liefert basierend auf dem Locale des Benutzers das richtige Bild aus.
• Halten Sie Ihre Basissprache vollständig. Ihre Basissprache (meistens Englisch) ist der Fallback für jede fehlende Übersetzung. Eine unvollständige Basis kann selbst in ansonsten vollständig übersetzten Sprachen zu unerwarteten Fallbacks führen. Xcode kennzeichnet fehlende oder veraltete Basis-Strings während des Builds.
• Lokalisieren Sie Ihren App-Store-Eintrag. Eine lokalisierte App mit einem rein englischen Eintrag verliert Nutzer bei der Entdeckung. In App Store Connect können Sie App-Namen, Untertitel, Beschreibung und Keywords pro Gebiet lokalisieren. Keywords sind besonders wertvoll. Apple indexiert Keywords aus mehreren Locales pro Gebiet, was Ihr Keyword-Zeichenbudget effektiv über die standardmäßigen 100 Zeichen hinaus vervielfacht. Nutzen Sie die PTC-Funktion Paste to Translate für App-Store-Inhalte.
• Verwenden Sie Locale-bewusste Formatierer. Date.FormatStyle, Decimal.FormatStyle und Locale-bewusste Formatierer. Hardcodieren Sie niemals "$" oder "MM/DD/YYYY".
• Verwenden Sie %lld für ganzzahlige Zählwerte und String(localized: "You have ^[\(count) message](inflect: true)") dort, wo Apples automatische grammatikalische Übereinstimmung greift.

Visuelle Übersetzungsprüfung Ihrer übersetzten iOS-App – veröffentlichen Sie ohne manuelle QA pro Sprache

Nachdem die PTC Ihre .xcstrings übersetzt hat, müssen Sie die laufende App immer noch in jeder Sprache verifizieren. Traditionell ein mehrtägiger manueller QA-Durchlauf pro Release. Ein übersetztes Label könnte auf Deutsch das Layout einer Navigationsleiste sprengen. „Send“ könnte im Französischen als Substantiv übersetzt werden, wenn der Button ein Verb benötigte. Ein hardcodierter englischer String außerhalb von Text(_:) wird in der laufenden iOS-App unübersehbar unübersetzt bleiben.

Die AI Visual QA der PTC ersetzt diesen Durchlauf. Verwenden Sie für native iOS-Apps (der Workflow über die Browser-Erweiterung gilt hier nicht) den Screenshot-Upload. Erfassen Sie die kritischen Bildschirme der laufenden App in jeder Zielsprache (Anmeldung, Haupt-Tab, Einstellungen, Edge-Cases) und laden Sie diese in die PTC hoch. Die Vision-KI der PTC inspiziert jeden Bildschirm und:

• Behebt Fehler in der .xcstrings, wenn die PTC diese kontrolliert. Sie übersetzt eine falsche Wortart neu, wählt ein kürzeres Synonym, das in eine Navigationsleiste passt, und generiert eine Pluralform mit korrekter grammatikalischer Übereinstimmung neu.
• Generiert einen Prompt für Cursor / Claude Code, wenn das Problem in Ihrem Swift-Code liegt. Ein fehlendes LocalizedStringKey, ein hardcodierter String außerhalb des Lokalisierungssystems oder ein Satz, der durch Verkettung statt Ersetzung gebildet wurde.

Das Ergebnis: eine verifizierte iOS-App pro Release. Nicht eine übersetzte .xcstrings, bei der die manuelle QA noch bevorsteht.

Ihren App-Store-Eintrag, Release Notes und Push-Benachrichtigungen übersetzen

Ihre App-Store-Beschreibung, die „What's new“-Release-Notes und der Text der Push-Benachrichtigungen befinden sich außerhalb von Localizable.xcstrings. Die Funktion Paste to Translate der PTC verarbeitet diesen Text im selben Projekt. Fügen Sie den Ausgangstext im PTC-Dashboard ein, wählen Sie die Zielsprachen aus und erhalten Sie Übersetzungen zurück, die dasselbe Glossar und dieselbe Markenstimme wie Ihre In-App-Strings verwenden. Apple indexiert Keywords aus mehreren Locales pro Gebiet, sodass lokalisierte Einträge für die Entdeckung besonders wertvoll sind.

In-App-Benutzerinhalte mit der PTC-API übersetzen

In-App-Chats, Social-Media-Beiträge und Nutzerbewertungen erfordern eine Übersetzung, sobald die Inhalte eintreffen. Die PTC-REST-API übersetzt diese Inhalte bei Bedarf mit Bearer-Token-Authentifizierung und verwendet dabei dasselbe Glossar und dieselbe Markenstimme wie Ihre .xcstrings-Übersetzungen.

Nicht funktionierende iOS-Lokalisierung beheben

Die häufigste Ursache ist, dass die Lokalisierungsdatei nicht im App-Target enthalten ist. Klicken Sie im Navigator auf Localizable.xcstrings, öffnen Sie den File Inspector und prüfen Sie, ob Ihr App-Target unter Target Membership angekreuzt ist. Bestätigen Sie auch, dass die Sprache im Abschnitt Localizations Ihres Projekts unter dem Tab Info aufgeführt ist. Wenn beides korrekt aussieht, bereinigen Sie den Build-Ordner mit Shift+Cmd+K und führen Sie den Build erneut aus.

iOS-Lokalisierungsdateiformate: .xcstrings, .strings, .stringsdict, .xliff

.xcstrings (String Catalog) ist seit Xcode 15 der aktuelle Standard. Eine einzige JSON-basierte Datei, die alle Strings, Pluralregeln und gerätespezifischen Varianten konsolidiert. .strings ist das veraltete Key-Value-Format, das in älteren Codebasen noch gültig ist, gepaart mit .stringsdict für Pluralformen. .xliff und .xcloc sind Exportformate für die Übergabe an Übersetzer. Sie sind keine Speicherformate.

Ihren App-Namen mit InfoPlist.strings lokalisieren

Erstellen Sie eine InfoPlist.strings-Datei und lokalisieren Sie diese für jede unterstützte Sprache. Fügen Sie in jeder Sprachversion CFBundleDisplayName = "Your Translated App Name"; hinzu. Wählen Sie die Datei im Navigator aus, öffnen Sie den File Inspector und klicken Sie auf Localize, um Sprachvarianten hinzuzufügen. iOS zeigt basierend auf der Gerätesprache den korrekten App-Namen an.

Die Sprache der iOS-App ohne Neustart ändern

iOS bietet hierfür keine native API. Der Standardansatz besteht darin, AppleLanguages in UserDefaults zu setzen und den Benutzer zu bitten, die App neu zu starten:

UserDefaults.standard.set(["es"], forKey: "AppleLanguages")
UserDefaults.standard.synchronize()

Die Änderung wird beim nächsten Start der App wirksam. Wenn Sie eine Umschaltung während der Sitzung ohne Neustart benötigen, müssen Sie die Lokalisierung manuell verwalten, indem Sie das entsprechende Bundle für die ausgewählte Sprache laden.

Warum iOS bei nicht unterstützten Sprachen auf Englisch zurückgreift

iOS verwendet Ihre Basissprache als Fallback, wenn eine Übersetzung nicht verfügbar ist. Dies ist das erwartete Verhalten. Um Fallbacks zu minimieren, stellen Sie sicher, dass Ihr String Catalog vor jedem Release keine fehlenden oder veralteten Strings aufweist.

Wie genau ist die KI-Lokalisierung für eine komplette iOS-App?

Die PTC nutzt KI, um .xcstrings-, .strings- und .stringsdict-Dateien in Minuten zu übersetzen, wobei Pluralregeln und Platzhalter automatisch beibehalten werden. Die Mehrheit der übersetzten Strings geht ohne Bearbeitungen live. Für die besten Ergebnisse sollten Sie der PTC bei der Einrichtung Informationen über Ihre App geben, damit die Übersetzungen die richtige Tonalität und Terminologie widerspiegeln.

In welche iOS-Sprachen Sie zuerst lokalisieren sollten

Spanisch, Französisch, Deutsch, Japanisch und Chinesisch (vereinfacht) sind neben Englisch häufige Startpunkte. Wenn Ihre App bereits Nutzer in einer bestimmten Region hat, priorisieren Sie deren Sprache zuerst. Für die geringsten Anpassungskosten beginnen Sie mit Sprachen, die Ihrem Basismarkt geografisch oder kulturell nahe stehen.

Ihre eigene iOS-App lokalisieren

Starten Sie mit der 30-Tage-Testphase der PTC – 20.000 Wörter gehen auf uns, keine Kreditkarte erforderlich. Laden Sie Ihre Localizable.xcstrings hoch, übersetzen Sie sie in Minuten, laden Sie dann Screenshots hoch und lassen Sie die PTC die gerenderte App verifizieren.

Verwandte Themen:

• iOS- und Android-Apps mit KI übersetzen – plattformübergreifende Service-Übersicht.
• So lokalisieren Sie Ihre Android-App – der entsprechende Leitfaden für Android Studio.
• PTC-API-Referenz – REST-Endpunkte für die CI-Integration.