XML to Objective-C
Paste XML and instantly get Objective-C model classes with typed properties inferred from your data.
Example
Input XML:
<person>
<name>Jane</name>
<age>34</age>
</person>
Generated Objective-C:
@interface Root : NSObject
@property (nonatomic, copy) NSString *name;
@property (nonatomic, assign) NSInteger age;
@end
How it works
The tool parses XML with the browser's DOMParser, infers a type model from elements and attributes, then emits matching Objective-C @interface and @implementation definitions. Nested elements become their own classes and repeated elements become NSArray properties.
Good to know
XML to Objective-C turns a sample XML document into ready-to-use Objective-C model classes, generating both the @interface declarations with typed @property lines and matching empty @implementation blocks. It is aimed at iOS and macOS developers who need to map a legacy XML feed, SOAP response, or configuration file onto Foundation model objects without hand-writing every property by hand.
Reach for it when you are scaffolding a model layer from an existing API payload and want a fast first draft of the class structure. Paste one representative XML sample, click Convert, and the tool walks the parsed DOM tree: each element with children or attributes becomes its own class, repeated sibling tags collapse into a single NSArray property, and leaf text values are sampled to pick a concrete scalar type.
Read the output by checking three things: the root class is always named Root regardless of your top-level tag; scalar properties use memory qualifiers that signal the inferred type (copy for NSString, assign for NSInteger, double, and BOOL, strong for nested objects and arrays); and the status line reports how many classes were generated, which is a quick sanity check that nesting was detected the way you expected.
One practical caveat: types are inferred from the single sample you provide, so an integer that could legitimately exceed NSInteger range, an optional field that happened to be empty (defaulting to NSString), or an array tag that appeared only once (emitted as a single object rather than a collection) may all need manual adjustment. The generated @implementation blocks are intentionally empty stubs, so you will still add your own parsing, initializers, or NSArray element typing before shipping.
Frequently asked questions
How are nested and repeated XML elements handled?
Each nested element with children or attributes becomes its own Objective-C class with a strong property on its parent. When the same tag appears more than once under a parent, it is emitted as an NSArray property to represent the collection.
How does the tool decide between NSString, NSInteger, BOOL, and double?
It inspects each element's text: pure integers map to NSInteger, decimals to double, true/false/yes/no to BOOL, and anything else (or empty values) to NSString. Conflicting values across repeated elements widen to the safest common type, usually NSString.
Is my data uploaded anywhere?
No — this tool runs entirely in your browser. Your input never leaves your device and it works offline once loaded.
Is it free?
Yes, completely free with no sign-up and no limits.
People also ask
Does the generated Objective-C include parsing code to read the XML back in?
No. The tool emits only the class structure: @interface declarations with typed properties and empty @implementation blocks. You add your own NSXMLParser, init methods, or mapping logic separately.
Why is my top-level class always named Root instead of my XML tag name?
The converter normalizes the document's root element to a class called Root so the entry point is predictable. Nested element classes keep names derived from their own tag names, capitalized and sanitized to valid identifiers.
How does it pick between strong, copy, and assign for property attributes?
Object and array properties use strong, NSString uses copy (the standard convention for string-like values), and scalar value types such as NSInteger, double, and BOOL use assign because they are not objects.
What happens if my XML has an element that only appears once but is really a list?
Because collection detection is based on a tag appearing more than once in the sample, a list with a single element is treated as a single nested object, not an NSArray. Provide a sample with at least two repeated entries, or change the property type manually.
Will element attributes show up as properties too?
Yes. Attributes on an element are converted into scalar properties on that element's class, with their type inferred from the attribute value the same way element text is.
What type does an empty XML element get?
Empty or whitespace-only values fall back to NSString, since there is no value to infer a numeric or boolean type from. Adjust it manually if you know the field is numeric.
Can I paste an entire large XML file or just a small sample?
You can paste any size that the browser can parse, but the type inference only needs one representative sample. A trimmed example covering each distinct element and at least two list items is usually enough to produce a complete class set.
Is the NSArray property typed to its element class?
No. Repeated elements become a plain NSArray property without a documented element type in the declaration, so you will typically add a comment or lightweight typing in code to indicate which class the array holds.
Related tools