Objective-C to XML Converter
Paste Objective-C interfaces or objects. Get clean XML back.
What this tool does
If you have ever had to hand-build an XML payload that matches an Objective-C model — for an old SOAP service, a plist file, a Cocoa config, or a test fixture — you know the drill. You count @property lines, strip the type qualifiers, remember which ones are NSArray containers, and hope the shape is right. Paste the Objective-C here and you get back well-formed XML in one pass. A single alloc/init snippet, a whole header file with several @interface blocks, or a deeply nested model — same result.
It is not naive text replacement. The converter follows how Cocoa actually maps to XML. NSString values become text nodes (escaped properly). NSNumber and NSDecimalNumber drop their wrapper and become plain numeric text — so [NSDecimalNumber decimalNumberWithString:@"249.99"] comes out as 249.99. BOOL values become true / false or the YES / NO variant if that is what your schema expects. NSArray<OrderItem *> becomes a container element with one child per item, named after the element type — the same shape NSXMLElement trees emit.
Instance variable backing is handled too. If your @property uses @synthesize customerName = _customerName;, the element is still named customerName, not _customerName — that iVar naming is an implementation detail, not part of the wire format. Nested objects (an Order with an Address @property) get expanded in place, and nil values become empty elements so the shape stays consistent. If you paste several @interface blocks, every one lands in the output. Paste it the way it sits in your .h file — no cleanup needed — and check the result against what NSXMLDocument would produce.
How to use it
Three steps. Works the same whether you paste one class or a whole header bundle.
Paste your Objective-C (or try the sample)
Drop your Objective-C into the left editor as-is. An @interface block, an alloc/init object literal, multiple classes, or nested types — all fine. Click Load Sample to see a realistic Order / OrderItem / Address example first.
You do not need to strip @property attributes, remove pragmas, or clean up import statements. Leave the code the way it looks in Xcode. The parser knows how to read a real .h or .m file.
Hit Convert
Click the green Convert button. The tool reads the Objective-C, keeps every @property, preserves nested objects, and builds the XML in one pass. A short loading indicator runs while it works.
Copy the XML
The right panel fills with indented, well-formed XML that any standards-compliant parser — including NSXMLParser — will accept. Copy it into a plist, a SOAP request body, a test fixture, or your documentation.
When this actually comes in handy
Building iOS plist fixtures
You have an Objective-C model and need a matching Info.plist or data-seed plist. Paste the class, get the XML, drop it into your bundle — no hand-writing <code><dict></code> / <code><key></code> pairs.
Cocoa XML config files
Old desktop Cocoa apps still ship XML config. Turn your <code>Settings</code> class into a ready-to-edit template so your config matches the code that reads it.
Legacy SOAP / WCF clients on iOS
If your iOS app still talks to a SOAP endpoint, you can paste the request contract class and get the XML envelope body — easier than hand-building <code>NSXMLElement</code> trees.
Seeding Mac OS XML workflows
Old AppleScript / Automator / XML-RPC integrations expect XML. Paste the Objective-C model, get the XML, feed it into the workflow — no manual translation.
Common questions
Can I paste multiple @interface declarations at once?
Yes. Paste a whole header file. Each @interface comes through with nested types expanded. If your @interface declares ivars explicitly (inside { }) or uses modern @property-only style, both work the same.
How are @property attributes handled?
Attributes like (nonatomic, copy), (strong), (weak), (readonly), and (assign) are metadata for the runtime — they do not change the serialized shape. The element name is the property name. readonly properties are still emitted (they still hold a value). Computed properties from custom getters are treated like any other property.
What about iVar naming — do I get _underscore elements?
No. If your property is customerName and the backing iVar is _customerName, the XML element is <customerName>. The underscore is an Objective-C convention, not a wire format. If you want to rename an element, rename the @property itself and re-paste.
How are NSString, NSNumber, NSDecimalNumber, BOOL, and NSDate treated?
NSString becomes a text node with proper XML escaping. NSNumber and NSDecimalNumber lose their wrapper and become plain numeric text. BOOL becomes true / false (or YES / NO if the source code uses the plist convention). NSDate comes out as an ISO-8601 string. nil values become empty elements rather than being dropped.
What about NSArray, NSDictionary, and nested objects?
NSArray<OrderItem *> becomes a container element with one child per item, named after the element type: <items><OrderItem/><OrderItem/></items>. NSDictionary becomes a container of <entry><key/><value/></entry>. Nested objects (a property whose type is another @interface) are expanded in place with every field intact.
Is my code stored?
Your code is sent to the backend for conversion and is not persisted — we do not log the payload. As always with online tools, if the code is genuinely sensitive, look it over before pasting.
Other tools you may need
Objective-C to XML is one piece of the puzzle. These tools pair well with it: