Personally I’ve never been entirely happy with the implementation provided by Apple, and in particular their decision to build their API around NSData instead of NSString. Granted there’s probably a reason why Apple chose to go that route, and also a reason why they didn’t bother to provide convenience methods that allow people to work with whichever type they prefer. But as far as I’m concerned, JSON is a textual/non-binary data format, so therefore the natural iOS data structure to use for outputting and inputting JSON data is an NSString. Using NSData instead is counter-intuitive, and clunky as a result.

So because of that clunkiness, I’ve stuck with the tried and true SBJson library, even though the author of that library himself recommends just using Apple’s implementation. This preference is largely based around the very helpful (and also very deprecated) ‘NSObject+SBJson‘ category that is included in the library. This category imbues objects with a couple of very convenient methods:

- (NSString*)JSONRepresentation;
- (id)JSONValue;

These methods can be used to turn an appropriate object (i.e. an NSArray or an NSDictionary) into a JSON string, and to turn a JSON string back into a proper object, respectively. No parameters, no options, no boxing to or unboxing from NSData; just a simple API that is basically just ‘[thing turnIntoJson];‘ and ‘[json turnBackIntoThing];‘. It doesn’t get much more convenient than that.

And that was all well and good, until I wanted to build a framework which internally used SBJson, and then use that framework within a project that also needs to make its own use of SBJson. Linker hell was the result. And long story short, I decided that it would be faster to build a shim around Apple’s JSON API to preserve the convenience I’m after than it would be to appease the linker gods.

So in case anyone else has been avoiding Apple’s JSON implementation because it’s too clunky to work with (or too painful to migrate away from SBJson), here’s my 5-minute shim:

NSObject+SimpleJson.h

#import <Foundation/Foundation.h>

@interface NSObject (SimpleJson)

- (NSString *)JSONRepresentation;  //turns an object into a JSON string
- (id)JSONValue;                           //turns a JSON string back into an object

@end

NSObject+SimpleJson.m

#import "NSObject+SimpleJson.h"

@implementation NSObject (SimpleJson)

- (NSString*)JSONRepresentation {
    //write ourself to a JSON string; only works if we're a type that 'NSJSONSerialization' supports
    NSError* error = nil;
    NSData* tempData = [NSJSONSerialization dataWithJSONObject:self options:kNilOptions error:&error];
    if (error) {
        return nil;
    }
    
    return [[NSString alloc] initWithData:tempData encoding:NSUTF8StringEncoding];
}


- (id) JSONValue {
    //converts from a string back into a proper object; only works if we're an NSString or NSData instance
    if (! [self isKindOfClass:[NSString class]] && ! [self isKindOfClass:[NSData class]]) {
        return nil;
    }
    
    NSData* jsonData = nil;
    if ([self isKindOfClass:[NSData class]]) {
        jsonData = (NSData*)self;
    }
    else {
        //we must be an NSString
        jsonData = [((NSString*)self) dataUsingEncoding:NSUTF8StringEncoding];
    }
    
    return [NSJSONSerialization JSONObjectWithData:jsonData options:kNilOptions error:nil];
}

@end

If you have code that uses SBJson’s ‘NSObject+SBJson‘ category, the above category should be drop-in compatible. And just as importantly (in my case) does not invoke linker hell when used as part of an iOS framework.

Note that the above code assumes you are using ARC. If not, you’ll want to add an ‘autorelease‘ call in there.

https://github.com/kstenerud/iOS-Universal-Framework

This project provides a single installation shell script that will add a new Project Template to XCode, one that can be used to build universal iOS frameworks. Now this wouldn’t be a big deal (and in all rights, shouldn’t be a big deal), if not for the fact that for some unspecified and frustrating reason, XCode has no built-in ability to create such frameworks. This means that up until recently if you had an iOS library that you wanted to use across many projects, or that you wanted to distribute for other developers to use in their projects, you had only a few not-very-good options:

• Include your source code in every project that uses your library (increased compilation time, hooray!).
• Build two library versions, one for armv6/armv7 and one for x86.
• Screw with the linker to manually create a “fat” library.
• Use the Bundle Hack and hope that it works.

It’s worth noting here that the first three options listed above do nothing to help with the management of any shared header files needed to actually make use of the library code. The fourth option does allow you to include public headers in your build artifact, but the setup to do so is tedious, and the entire thing is basically a giant hack besides. None of these options are really very convenient or useful from the developer’s point of view.

What developers really need, what they should have access to, and what XCode should have supported at least since the release of iOS 4.0, is the ability to build true universal iOS frameworks that are “real” frameworks in the same sense that UIKit and CoreGraphics are real frameworks. And that’s exactly what the iOS-Universal-Framework project gives you. Just install it and you get a handy XCode Project Template that can be used to build a universal iOS framework. This lets you build real iOS frameworks that include libraries for both x86 and armv6/armv7 in a single package, automatically bundled with your public header files. You (or anyone else) can then use the generated framework inside of other projects in the same way as any other iOS framework; just add it to your “Link With Binary Libraries” build phase, and away you go.

All told, the iOS-Universal-Framework Project Template is great and works exactly as advertised. Just install it and you’re good to go. I’ve only come across one minor caveat worth mentioning, which is that although the template does correctly produce a universal iOS framework, the build product shown in XCode will actually point to an architecture-specific version of the framework. In order to find the correct, universal framework it is necessary to do a “Show in Finder” on the build product shown in XCode (or otherwise navigate to your project output directory), and then go up a level (or two) in the filesystem to find the folder that contains the universal version of the framework (edit: as per Karl’s comment below, this has now been fixed. Hooray!).

Apart from that minor annoyance this little XCode extension is really quite excellent, and I encourage you to give it a try. My personal thanks to Karl Stenerud for putting this together.