Yllä olevassa esimerkissä, huolimatta alustustoiminnon lisäämisestä, olemme poistaneet tarpeen monille suullisille ”if-let”- ja ”guard-else”-lausekkeille koodia jäsentäessämme (tarpeen vain käsiteltäessä URL-osoitteen luomisesta tulevaa valinnaista paluuta). Lisäksi huomaa, että tavallinen, ei-valinnainen id-ominaisuus ja valinnainen caption-ominaisuus jäsennetään käyttäen samaa koodisyntaksia. Captionin dekoodausfunktion ensimmäinen parametri määrittää, että se odottaa valinnaista arvoa lisäämällä kysymysmerkin odotetun tietotyypin perään.
Tässä vaiheessa jäsentelykoodimme lähestyy alkuperäisen ei-koodattavissa olevan objektin pituutta. Uusi koodi on kuitenkin selkeämpi ja erottaa ne koodin osat, joissa kirjoitusvirheitä yleensä tehdään (JSON-avaimia määrittelevät merkkijonot) helposti tunnistettavaksi enumiksi.
Erottamalla JSON-avaimet enumiksi ja poistamalla useimpien if-let- ja guard-else-lausekkeiden tarpeen edellä esitetty Codable-protokolla antaa meille runsaasti tilaa rakentaa objektejamme ilman, että koodin monimutkaisuus lisääntyy dramaattisesti.
Henkilöillä tai tiimeillä, jotka hallitsevat sekä back-end- että front-end-koodia, on yleensä vapaus mukauttaa tietomalliaan jatkuvasti visuaalisten malliensa kanssa työskentelyyn ilman suurta logistiikkaa (jos et ole koskaan ollut yhtä jääräpäisten front-end- ja back-end-kehittäjien välisessä palaverissa, pidä itseäsi onnekkaana). Niille, jotka kuuluvat tähän kategoriaan, Codable-toiminnon toteuttamisen hyötyjä ovat Swift-objektien julistaminen ja jäsentäminen mahdollisimman pienellä määrällä koodia ja Applen parhaiden käytäntöjen ja odotusten noudattaminen. Jos kuitenkin kuulut laajamittaiseen kehitystiimiin, joka on tekemisissä erillisen tahon tarjoamien API-rajapintojen kanssa ja jossa et voi kontrolloida palautettavien tietojen ajoitusta tai muutosten yksityiskohtia, Codable voi olla hohtava toivon majakka hulluuden keskellä.
Kuvittele, että teet kolme API-kutsua sovelluksen eri osa-alueilla, joista jokaisen pitäisi palauttaa täsmälleen sama Swift-objekti. Tässä epäonnisessa API:ssa jokainen noista kutsuista sattuu palauttamaan dataa hieman eri sanakirja-avaimella; object_id, obj_id ja Object_ID, joiden kaikkien tarkoituksena on viitata samaan ominaisuuteen, objectId, objektissa, jonka haluat luoda. Aikaisemmin dekoodausfunktio olisi tarvinnut sarjan ”if-let”-lauseita tarkistaakseen id:n jokaisessa noista avaimista ennen kuin lopulta päätettiin, mikä, jos mikä, arvo asetetaan ominaisuudeksi.