I’d probably use a NSDictionary. The code will probably be cleaner & easier to maintain. If you get an unexpected attribute, you’ll crash if you didn’t define a property for it.

As Mike suggested, an NSDictionary is an easy way to store a ton of key/value pairs quickly. The downside to this approach is you lose convenience of access after the fact. You have to remember what every key was in order to access any values. This may mean going back to the web service API or the JSON response to get the key you need. You also get no help from the compiler.

On the other hand, creating an NSObject subclass with properties for each key/value pair gives you all the convenience but it takes time to parse the values, especially with as many as you’re talking about. I generally use the subclass approach because I like the convenience of having the compiler help with autocomplete and type checking. You can also determine which properties are read/write and which are read only. I add an initWithDictionary: method to create the subclass and parse the JSON response inside of that method. That kind of helps abstract away the data model from the application itself

As i think its better to create a class object and use properties to store attributes because that can store even NULL values instead of NSDictionary.
In NSDictionary you must have to check for NULL value before insert in it.

Class object is much cleaner, more understandable and easier to debug values during debug time.

Class objects differentiate b/w each property data type.

Both. Properties in a model object for efficient access and compiler checking help. And a Dictionary for rarely used, overflow and/or unrecognized new (or errored) attributes, making it easier to decouple changes to your download data and to the client apps in the field, without crashing or tossing data that might be needed further down the road, or for debugging.