Ever since Swift was first released there has been an endless stream of new libraries to simplify writing Swift code that consumes JSON data. Since this is such a common and tedious aspect of developing apps, it’s an important topic to many Swift developers. In the Swift projects I’ve worked on, we have naturally gravitated toward an implementation pattern quite similar to the approach that Apple advocates. This style does not make use of a third-party library, and is reasonably simple and effective.
Regardless of which approach you take to writing code to consume JSON you still must spend time writing, testing, and fixing code. And let’s face it, writing code to turn JSON into data objects is grunt work. Boring, error-prone, grunt work. Ain’t nobody got time for that!
That’s why I created json2swift; a command line tool that writes your Swift code for you. You provide it with a sample of the JSON data your app consumes, it generates all the Swift code needed to consume that data. You just drop the generated Swift files into your project, rename and rearrange the shiny new code to your heart’s content, and move on to more interesting tasks.
But what about all those sweet JSON libraries that help you write code to turn JSON into Swift objects? Where do they fit in?
A fellow named Vivien recently opened an issue in my json2swift Github repository to ask what I thought about adding support for generating Swift code that uses the popular Unbox JSON library. I understood what he meant, but not why he would ask for such a thing. After a brief discussion, he and I came to an agreement that if you use json2swift there’s no need to continue using a third-party library to turn JSON into Swift data objects. There’s certainly no reason for the tool to generate code that uses a third-party JSON API!
For developers who are not accustomed to working with code generation tools, it might take some getting used to. Think about it this way…
If JSON libraries are a way to make yourself run faster; json2swift is a race car.
Yes, we do not need any third party json libraries. And I have written a similar tool https://github.com/nixzhu/Coolie
Thanks Josh! This approach shows a lot of wisdom and experience. Your contributions to the community are appreciated.
Thank you, Kerry.
I did successfully use json2swift for a JSON structure that was handed to me. Worked the first time. Amazing!
I do have a question about the way createRequiredInstances() should work. If I decode into Swift a JSON struct that is itself a array of structs that represent the RootType, then I get a [[String:Any]] structure. That is, I already have the variable you call jsonDictionaries. I wrote a supplemental version of createRequiredInstances() that dispenses with its first line of code, and just takes the jsonDictionaries and proceeds to iterate. It did successfully parse my JSON data into an array of RootTypes.
I thought that was what your original createRequiredInstances() was supposed to do. I don’t understand what its json parameter is supposed to represent. A dict of JSON arrays? Seems like one too many layers here. Can you elucidate?
We can take this offline if you would prefer, but I could certainly paste in some lengthy expository code snippets here if you want.
But anyway, thanks! You saved me from the tedious hand-parsing… and taught me something.
Thank you! Your question clarified something that had been bothering me for a while now. The methods in the CreatableFromJSON protocol extension which take both a JSON dictionary and arrayKey argument exist to help make the generated failable initializers simple & clean. The array is extracted from the dictionary in those methods so that such code doesn’t need to exist more than once in the generated code.
But, as you pointed out, that’s not very helpful in other contexts. So, I added two new helper methods that do what you’re describing.
Here’s the commit:
Aha I see, that makes sense. I’m glad I wasn’t missing some fundamental idea. Thanks for your new commit. In fact, just today I got some design mods that make your original one more appropriate. Room for both approaches!