Good good. Now we’re just at the mercy of the reviewers to get it approved for the Asset Store. I’ve tested it pretty heavily. I don’t have access to an iOS device myself so I’ve relied on others to help me test but it’s been solid and no AOT errors. Both Json and Bson are working properly for serialization and deserialization. Testing for Blackberry and Android have been a bit more limited but are still underway. As a professional developer I’m also of the strong belief that you don’t roll bugs across major versions (unless it’s a limitation of the platform), so if I do get any reported bugs I’ll tackle them and roll them into a minor version update. Right now my contact is through my blog but I’m in the processing of building a website dedicated to my Assets (there will only be the one for now).
I focused on JSON .NET because it’s been a big request from the community that I’ve seen over and over and, surprisingly, no one has done an actual conversion. People have managed to get older versions working to varying degrees but still suffer from iOS and Webplayer compatibility issues so I focused on taking care of the AOT issues and getting it working properly for the Webplayer. The conversion wasn’t really that difficult for the most part, but it was time consuming and very tedious to track down every issue and get it cleaned up and I couldn’t have done it without help testing from the community.
I’ll definitely update here once it’s released (approved) on the asset store. The asset I pushed has full source code. This is necessary because there are some precompiler conditionals that modify compilation behavior based on the environment to handle support differences between platforms. I’ve also bundled a sample scene and monobehavior that demonstrates different serialization and deserialization scenarios (both JSON and BSON). It’s a pretty ugly scene that just has three GUIText labels but the important part is on the example code.
For the most part, the documentation provided for the standard JSON .NET version will hold true for this one. I’ve maintained all of the same namespacing and types that are supported by Unity (I removed some, such as the System.Data dependent functionality), so if there are other third-party assets with a JSON .NET dependency that fail with AOT errors, you can safely delete the Newtonsoft.Json.Net.dll and drop in this asset and it will work so long as they didn’t compile their assemblies with specific version dependencies, though there’s no reason they should have. Once I’ve got the Asset site finalized, I’ll add my own documentation and provide code samples that are specifically geared toward Unity users.
I also added an additional configuration setting. People will have different preferences on how they want their Enums to be serialized, so I added a global setting to the serializer settings to allow the behavior to be modified. By default, the serializer will serialize Enum properties as their Name so if you have the following:
myObject.Property = MyEnum.ValueA;
It will get serialized as “ValueA”. You can change the behavior by setting:
JsonSerializerSettings.DefaultEnumSerializationHandling = EnumSerializationHandling.Value;
The valid values for EnumSerializationHandling is “Value” and “Name”. Setting it to Value will use the integer value, so it would be serialized as 3 rather than “ValueA” (if ValueA were the fourth item in your Enum or was set to a value of 3).
Right now this is a global setting, so you can set it once and it will be maintained. No configuration change is required to deserialize as it will handle either the name or value for an Enum. There are readability reasons for using the Name rather than the Value, but sometimes you want more compact data representation so the Value might be right for you. You can set it to Value, serialize an object and set it right back to Name if you want. There are other default properties in the serializer which can be overridden so eventually I plan to make Enum handling a property that can be overridden per serialization operation or with an attribute setting but it’s minor so for now it’s just a global setting. Most likely if you want to use Value instead of Name you’re going to want to do it consistently for every serialization so the global setting is most appropriate.
If you have any questions while we wait for the Asset to be approved, feel free to post here or reach out to me and I’d be happy to answer.
No need to rely on an older version especially since there were bug fixes.
If anyone is following this and interested, one of the other big advantages of this port is that it has BSON support (Binary JSON). Processing for BSON is faster, more compact, and of course it’s binary. 
I’ve been testing BSON as well and it’s working great.