Swift-zu-XML-Converter
Swift-Structs oder eine befüllte Instanz reinpasten. Sauberes XML zurückbekommen.
Was dieses Tool macht
Wer schon mal XML per Hand schreiben musste, das einen Swift-Struct abbildet — für ein plist, einen SOAP-Client, der mit einem Legacy-ERP redet, oder eine XMLParser-Testfixture — weiß, wie viele geschweifte Klammern man da am Ende tippt. Swift hier reinpasten und du bekommst in einem Durchgang wohlgeformtes XML. Ein einzelner Struct, eine Datei mit mehreren Structs und Enums, oder eine befüllte let order = Order(...)-Instanz — das Ergebnis ist dasselbe: ein komplettes XML-Dokument, in dem jede Property erhalten bleibt.
Das ist kein dummes String-Ersetzen. Der Converter weiß, wie Swift wirklich serialisiert — ungefähr so, wie es ein Codable-getriebener XMLEncoder handhaben würde. Decimal-Werte kommen als schlichter Zahlentext raus, Date wird zu einem ISO-8601-String, UUID zum Standard-Hexformat 8-4-4-4-12, und Optional<T> mit nil wird zu einem leeren Element statt einfach zu verschwinden. Arrays folgen einer konsistenten Container-Form — jedes Array wird zu einem Wrapper-Element mit einem Kind pro Item, benannt nach dem Element-Typ.
Coding-Anpassungen werden ebenfalls respektiert. Ein verschachteltes enum CodingKeys: String, CodingKey mappt die Property-Namen in der Ausgabe um — so kann orderId im XML als OrderId auftauchen, ohne dass du den Struct anfasst. Verschachtelte Structs und Enums werden inline expandiert. Wenn du mehrere Typen reinpastest, landet jeder mit seiner Form intakt in der Ausgabe — der Converter folgt denselben großen Designzielen wie die Swift API Design Guidelines, also bleiben Namen und Casing vorhersehbar.
So benutzt du es
Drei Schritte. Funktioniert gleich, egal ob du einen Fünf-Zeilen-Struct reinpastest oder eine komplette Model-Datei.
Swift reinpasten (oder Beispiel ausprobieren)
Pack dein Swift einfach in den linken Editor. Ein struct, ein enum mit associated values, eine befüllte let-Instanz oder eine Datei mit mehreren Typen — alles okay. Klick auf Beispiel laden, wenn du erst ein realistisches Beispiel sehen willst.
Du musst weder import-Statements rausnehmen, noch @propertyWrappers entfernen oder die Swift-Syntax aufräumen. Lass den Code so, wie er in Xcode aussieht. Einfach reinpasten.
Auf Konvertieren klicken
Klick auf den grünen Konvertieren-Button. Das Tool liest das Swift, behält jeden Typ und jede Property und baut das XML in einem Durchlauf. Während es läuft, siehst du einen kurzen Ladeindikator.
XML kopieren
Das rechte Panel füllt sich mit eingerücktem, wohlgeformtem XML, das jeder standardkonforme XML-Parser (XMLParser, lxml, System.Xml, was auch immer) akzeptiert. Kopier es direkt in dein plist, deinen SOAP-Body oder deine Testfixture.
Wann das wirklich was bringt
plist-Generierung für iOS / macOS
Nimm einen Settings-Struct in Swift und bekomme ein Info.plist-artiges XML-Dokument, das du direkt in Xcode fallen lassen kannst — keine handgetippten <code><key></key></code>-Paare, keine Whitespace-Bugs. Passt gut zu Apples <a href="https://developer.apple.com/documentation/foundation/propertylistserialization" target="_blank" rel="noopener">PropertyListSerialization</a>-APIs auf der Decoding-Seite.
SOAP-Clients auf Apple-Plattformen
Ein Swift-Request-Typ muss als SOAP aus der App raus. Struct reinpasten, XML-Body in SoapUI oder Postman kippen und den Vertrag prüfen, ohne den Envelope per Hand zu schreiben.
Seeding von Testfixtures
Wandle ein befülltes <code>let order = Order(...)</code> aus einem Unit-Test in eine XML-Seed-Datei um — für XCTest-Integrationstests, Mock-Server oder Backend-Systeme, die immer noch XML sprechen.
Docs synchron halten
Generier XML-Beispiele für ein README, ein internes Wiki oder XSD-basierte Schema-Docs direkt aus deinen echten Swift-Models, damit die Doku nie aus dem Takt mit dem Code gerät.
Häufige Fragen
Kann ich mehrere Structs gleichzeitig reinpasten?
Ja — pack eine ganze Datei rein. Jeder Top-Level-Struct und jedes Top-Level-Enum kommt mit ausgeklappten verschachtelten Typen und befüllten Defaults durch. Nichts wird still fallengelassen.
Werden CodingKeys berücksichtigt?
Ja. Ein verschachteltes enum CodingKeys: String, CodingKey mappt Property-Namen in der XML-Ausgabe um — case orderId = "OrderId" gibt <OrderId> statt <orderId> aus. Properties, die nicht in CodingKeys stehen, fallen auf ihren Swift-Namen zurück. Genauso, wie Codable in der Praxis funktioniert.
Wie werden Decimal, Date und Optional behandelt?
Decimal kommt als schlichter Zahlentext raus. Date wird zu einem ISO-8601-String. UUID wird zu einem Standard-8-4-4-4-12-Hex-String. Optional<T> mit nil wird zu einem leeren Element statt zu verschwinden — die Form bleibt konsistent für Konsumenten, die gegen ein XSD validieren.
Was ist mit Enums mit associated values und Arrays?
Enums mit associated values werden mit einem Discriminator-Attribut ausgegeben, das den Case benennt, plus Kind-Elementen für die associated values — genug, um sie round-zu-trippen. Arrays werden zu einem Container-Element mit einem Kind pro Item, benannt nach dem Element-Typ. Dictionary<K,V> wird zu einem Container aus <Entry><Key/><Value/></Entry>.
Wird mein Code gespeichert?
Dein Code wird zur Konvertierung ans Backend geschickt und nicht persistiert — wir loggen den Payload nicht. Wie immer bei Online-Tools: Wenn der Code wirklich sensibel ist, vor dem Einfügen nochmal drüberschauen.
Was, wenn das Swift Property Wrapper, Protokolle oder computed properties hat?
Property Wrapper werden in der Ausgabe auf den darunterliegenden Wert entpackt. Protokolle definieren Form, nicht Inhalt, produzieren also kein XML direkt — aber konforme Typen schon. Computed properties werden übersprungen, weil sie abgeleitet sind und keinen State enthalten. Wenn der Code Syntaxfehler hat, behebe erst die offensichtlichen — der Parser ist tolerant, aber kein Hellseher.
Andere Tools, die du vielleicht brauchst
Swift zu XML ist nur ein Puzzlestück. Diese hier passen gut dazu: