Convertisseur Swift vers XML
Colle des structs Swift ou une instance remplie. Récupère du XML propre.
Ce que fait cet outil
Si tu as déjà dû écrire à la main du XML qui reflète un struct Swift — pour un plist, un client SOAP qui cause avec un ERP legacy ou un fixture de test XMLParser — tu sais combien d'accolades tu finis par taper. Colle le Swift ici et récupère du XML bien formé en une passe. Un seul struct, un fichier avec plusieurs structs et enums, ou une instance remplie let order = Order(...) — même résultat : un document XML complet avec chaque propriété préservée.
Ce n'est pas du remplacement de chaînes bête. Le convertisseur sait comment Swift sérialise vraiment — à peu près comme un XMLEncoder piloté par Codable le ferait. Les valeurs Decimal sortent en texte numérique brut, Date devient une chaîne ISO-8601, UUID devient le format hex standard 8-4-4-4-12, et Optional<T> avec nil devient un élément vide plutôt que de disparaître. Les tableaux suivent une forme de conteneur cohérente — chaque tableau devient un élément wrapper avec un enfant par item, nommé d'après le type d'élément.
Les personnalisations de Coding sont aussi respectées. Un enum CodingKeys: String, CodingKey imbriqué renomme les propriétés dans la sortie, donc orderId peut apparaître en OrderId dans le XML sans que tu touches au struct. Les structs et enums imbriqués sont développés en ligne. Si tu colles plusieurs types, chacun atterrit dans la sortie avec sa forme intacte — le convertisseur suit les mêmes grands objectifs que les Swift API Design Guidelines, donc les noms et le casing restent prévisibles.
Comment l'utiliser
Trois étapes. Ça marche pareil que tu colles un struct de cinq lignes ou un fichier de modèle complet.
Colle ton Swift (ou essaie l'exemple)
Balance ton Swift tel quel dans l'éditeur de gauche. Un struct, un enum avec valeurs associées, une instance let remplie ou un fichier avec plusieurs types — tout passe. Clique sur Charger un exemple si tu veux voir d'abord un cas réaliste.
Pas besoin d'enlever les instructions import, de retirer les @propertyWrappers ni de nettoyer la syntaxe Swift. Laisse le code comme il est dans Xcode. Colle, c'est tout.
Clique sur Convertir
Clique sur le bouton vert Convertir. L'outil lit le Swift, préserve chaque type et propriété, et construit le XML en une passe. Un court indicateur de chargement s'affiche pendant le traitement.
Copie le XML
Le panneau de droite se remplit de XML indenté et bien formé que n'importe quel parser XML standard (XMLParser, lxml, System.Xml, au choix) acceptera. Copie-le direct dans ton plist, ton body SOAP ou ton fixture de test.
Quand ça sert vraiment
Génération de plist iOS / macOS
Prends un struct de settings Swift et récupère un document XML façon Info.plist que tu peux déposer direct dans Xcode — pas de paires <code><key></key></code> tapées à la main, pas de bugs d'espaces. Ça se marie bien avec les APIs <a href="https://developer.apple.com/documentation/foundation/propertylistserialization" target="_blank" rel="noopener">PropertyListSerialization</a> d'Apple côté décodage.
Clients SOAP sur plateformes Apple
Un type de requête Swift doit sortir de l'app en SOAP. Colle le struct, balance le body XML dans SoapUI ou Postman, vérifie le contrat sans écrire l'enveloppe à la main.
Seeding de fixtures de test
Transforme un <code>let order = Order(...)</code> rempli dans un test unitaire en fichier XML de seed pour des tests d'intégration XCTest, des mock servers ou des systèmes backend qui causent encore XML.
Garder la doc synchro
Génère des exemples XML pour un README, un wiki interne ou une doc de schéma XSD direct depuis tes vrais modèles Swift, pour que la doc ne se désynchronise jamais du code.
Questions fréquentes
Je peux coller plusieurs structs d'un coup ?
Oui — colle un fichier entier. Chaque struct ou enum de niveau supérieur passe avec les types imbriqués développés et les valeurs par défaut remplies. Rien n'est jeté en silence.
Ça respecte les CodingKeys ?
Oui. Un enum CodingKeys: String, CodingKey imbriqué renomme les propriétés dans la sortie XML — case orderId = "OrderId" émettra <OrderId> au lieu de <orderId>. Les propriétés non listées dans CodingKeys retombent sur leur nom Swift. Ça colle avec le fonctionnement de Codable en pratique.
Comment gère-t-il Decimal, Date et Optional ?
Decimal sort en texte numérique brut. Date devient une chaîne ISO-8601. UUID devient une chaîne hex standard 8-4-4-4-12. Optional<T> avec nil devient un élément vide au lieu de disparaître — la forme reste cohérente pour les consommateurs qui valident contre un XSD.
Et les enums avec valeurs associées et les tableaux ?
Les enums à valeurs associées sont émis avec un attribut discriminant qui nomme le case, plus des éléments enfants pour les valeurs associées — assez pour les round-tripper. Les tableaux deviennent un élément conteneur avec un enfant par item, nommé d'après le type d'élément. Dictionary<K,V> devient un conteneur de <Entry><Key/><Value/></Entry>.
Mon code est-il stocké ?
Ton code est envoyé au backend pour la conversion et n'est pas persisté — on ne logue pas le payload. Comme toujours avec un outil en ligne, si le code est vraiment sensible, jette-lui un œil avant de coller.
Et si le Swift a des property wrappers, des protocoles ou des propriétés calculées ?
Les property wrappers sont déballés vers la valeur sous-jacente dans la sortie. Les protocoles définissent une forme, pas un contenu, donc ils ne produisent pas de XML directement — mais les types qui s'y conforment, si. Les propriétés calculées sont ignorées puisqu'elles sont dérivées, pas de l'état. Si le code a des erreurs de syntaxe, corrige d'abord les plus évidentes — le parser est tolérant mais pas devin.
D'autres outils qui peuvent te servir
Swift vers XML n'est qu'une pièce du puzzle. Ceux-là vont bien avec :