Göksel Köksal
May 28, 2018 · 3 min read
Photo by Julian Howard on Unsplash

Originally published on Swift Post.

Codable got everyone excited because we all love parsing JSON and it’s nice to have this tool as a part of the standard library. Now it’s time to test if it’s worthy enough to be our favorite one.

Let’s see how Codable performs under rough conditions. We’re going to parse the following JSON using Codable and then compare it against the popular Unbox/Wrap implementation.

“placeName”: “İstanbul, Turkey”,
“lat”: 41.0049823,
“lon”: 28.7319958,
“dateAdded”: “2018-05-25”,
“info”: “İstanbul is a very historical city.”

We want our data model to look like the following.

struct Place: Codable {
let name: String
let coordinate: Coordinate
let dateAdded: Date
let info: String?
struct Coordinate {
let latitude: Decimal
let longitude: Decimal


  • placeName and name doesn’t match. We need to tweak coding keys.
  • Two separate keys lat and lon become a Coordinate object. Custom decoding is needed.
  • We need to use YYYY-mm-dd date format for dateAdded field.
  • We need to throw an error if name, coordinate and dateAdded fields are missing but info field is optional.

Implementation Using Codable

Implementation Using Unbox & Wrap


Their usage is almost the same. That is, of course, if we define decoder and encoder as a class property.


let place = try Place.decoder.decode(Place.self, from: jsonData)
let placeData = try Place.encoder.encode(place)


let place = try Place(unboxer: Unboxer(data: jsonData))
let placeData = try wrap(place) as Data

Comparison 🎯

  • Codable implementation is 47 lines, whereas Unbox implementation is 39 lines for this example.
  • Keys in Codable is always strongly typed (CodingKeys) while Unbox only accepts String keys.
  • While decoding properties, Unbox infers the type but Codable requires the type as a parameter. However, this can be enabled in Codable as well using a simple extension like KeyedDecodingContainer+TypeInference.
// Codable:
try container.decode(String.self, forKey: .name)
// Unbox:
name = try unboxer.unbox(key: "placeName")
  • Codable only supports one date encoding/decoding strategy. So if we had a UNIX timestamp property along with dateAdded, we would need to manually transform it into a Date object in init(from decoder:) method.
  • Codable has lots of advanced features around keys, which are not available in Unbox/Wrap. (See: Using JSON with Custom Types)
  • Unbox/Wrap is a third-party dependency while Codable is a part of standard library.

Bottom Line 🎖

While Codable requires some research and digestion before advanced usage, you can hit the ground running with Unbox in minutes. For serialization, Unbox only requires you to implement an init method which defines all the mappings.

On the other hand, Codable is black magic.

Most of the cases, it just works without any customization. Although advanced usage can sometimes be complicated due to keys being strongly typed, it’s easy to learn. Codable is like a Swiss army knife so I can’t think of any case you can’t handle with it.

I started this post thinking that Unbox is much simpler and readable compared to Codable for advanced usage, but sample code indicates otherwise. It might be time to move away from all third-party JSON parsing frameworks and make peace with Codable.

Well played, Apple.

Thanks for reading! Please let me know what you think and help spread the word. ❤️👏

Further reading: Swift 4’s Codable by Alp Avanoğlu

Developer Mind

Thoughts, experiences and knowledge sharing from software developers

Göksel Köksal

Written by

iOS developer. Serious gamer.

Developer Mind

Thoughts, experiences and knowledge sharing from software developers

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade