Native JSON support in iOS?

42,622

Solution 1

As of iOS5 JSON is been natively supported, no need for 3rd party frameworks. This is supported by the NSJSONSerialization Class!

Solution 2

Updated answer for iOS 5:

JSON support is now native to iOS with NSJSONSerialization, but in terms of performance, it pales in comparison to JSONKit, as John Englehart stated in the JSONKit README:

UPDATE: (2011/12/18) The benchmarks below were performed before Apples NSJSONSerialization was available (as of Mac OS X 10.7 and iOS 5). The obvious question is: Which is faster, NSJSONSerialization or JSONKit? According to this site, JSONKit is faster than NSJSONSerialization. Some quick "back of the envelope" calculations using the numbers reported, JSONKit appears to be approximately 25% to 40% faster than NSJSONSerialization, which is pretty significant.

enter image description here

Here's a blog post which delves into more specific benchmarks: JSON Libraries for iOS Comparison

Solution 3

There are several JSON libraries for the iPhone listed in this thread: https://stackoverflow.com/questions/286087/best-json-library-to-use-when-developing-an-iphone-application

Share:
42,622
Moshe
Author by

Moshe

iOS Engineer Website | GitHub | Careers | App Store

Updated on November 27, 2020

Comments

  • Moshe
    Moshe over 3 years

    Is there a class to parse JSON from a server in the iOS SDK? (similar to NSXML for XML and by extension RSS.)

  • Tommy
    Tommy over 12 years
    For anyone finding this question via Google or some other similar source: boz's answer below supersedes this one. JSON support is now native to iOS.
  • Doug
    Doug about 12 years
    Would you recommend using the native classes or JSONKit - i've heard performance reasons for why you would use the non-native classes, and would love some feedback
  • umassthrower
    umassthrower about 12 years
    For anyone hoping to use JSONKit with your app that uses iOS's reference counting based garbage collection, you're out of luck here (in other words the JSONKit documentation goes out of its way to mention that the behavior of JSONKit when being used with an ARC app is undefined). But, if you're using ARC, you probably don't care too much about memory and performance anyway :-)
  • ThomasW
    ThomasW almost 12 years
    @Doug according to this: bonto.ch/blog/2011/12/08/… JSONKit is faster, but unless you're working with a massive amount of JSON I don't think it will make much of a difference.
  • umassthrower
    umassthrower almost 12 years
    Indeed, that's why I said "the documentation goes out of its way" bit.ly/LCRu0x : "JSONKit is not designed to be used with Objective-C Automatic Reference Counting (ARC). The behavior of JSONKit when compiled with -fobjc-arc is undefined. The behavior of JSONKit compiled without ARC mixed with code that has been compiled with ARC is normatively undefined since at this time no analysis has been done to understand if this configuration is safe to use. At this time, there are no plans to support ARC in JSONKit. Although tenative, it is extremely unlikely that ARC will ever be supported"
  • umassthrower
    umassthrower almost 12 years
    I. E. it may work or it may not, but if you have any trouble you're going to have to fork JSONKit and fix it yourself, because it's not going to be fixed for you.
  • LightningStryk
    LightningStryk almost 11 years
    NSJSONSerialization has a bug in iOS 5 only (I never found it in 6) and will sometimes throw an error on perfectly valid JSON. The error says Error Domain=NSCocoaErrorDomain Code=3840 "The operation couldn’t be completed. (Cocoa error 3840.)" (Duplicate key for object around character 126.) I don't know what fully causes the error, as I can't always reproduce it.
  • William Denniss
    William Denniss almost 11 years
    @umassthrower I've not seen any problems with several ARC-enabled production apps. My understanding is that this is more of a compiler issue than anything else, and mixing of ARC and non-ARC code is supported by the compiler.
  • ioopl
    ioopl about 8 years
    Link is broken. Page not found!