A fenti példában az inicializáló függvény hozzáadása ellenére megszüntettük a sok bőbeszédű “if-let” és “guard-else” utasítás szükségességét a kód elemzése során (csak az URL létrehozásából származó opcionális visszatérés kezelésénél van rá szükség). Továbbá vegye észre, hogy a szokásos, nem opcionális id tulajdonságot és az opcionális caption tulajdonságot ugyanazzal a kódszintaxissal elemezzük. A feliratra vonatkozó dekódoló függvény első paramétere a várható adattípus után egy kérdőjel hozzáadásával adja meg, hogy opcionális értéket vár.

Az elemző kódunk ezen a ponton már közelít az eredeti, nem kódolható objektum hosszához. Az új kód azonban áttekinthetőbb, és a kód azon területeit, ahol gyakran előfordulnak elgépelések (a JSON kulcsokat specifikáló karakterláncok), egy könnyen azonosítható enumba választja szét.

A JSON kulcsok enumba való szétválasztásával és a legtöbb “if-let” és “guard-else” utasítás szükségességének kiküszöbölésével a fent bemutatott Codable protokoll bőséges teret biztosít az objektumaink továbbfejlesztéséhez anélkül, hogy a kód bonyolultsága drasztikusan növekedne.

A back-end és front-end kódjukat egyaránt kezelő egyéneknek vagy csapatoknak általában megvan a szabadságuk arra, hogy folyamatosan hozzáigazítsák az adatmodelljüket a vizuális modelljükhöz, kevés logisztikai többletköltséggel (ha még sosem voltál egy ugyanolyan makacs front-end és back-end fejlesztők közötti megbeszélésen, tartsd magad szerencsésnek). Azok számára, akik ebbe a kategóriába tartoznak, a Codable implementációjának előnye, hogy a Swift objektumokat a lehető legkevesebb kóddal deklarálják és elemzik, és lépést tartanak az Apple legjobb gyakorlatával és elvárásaival. Ha azonban egy nagyszabású fejlesztőcsapat tagja vagy, amely egy különálló entitás által biztosított API-kkal foglalkozik, ahol nem tudod ellenőrizni a visszaadandó adatok időzítését vagy változásainak részleteit, a Codable lehet a remény fénylő jelzőfénye az őrület közepette.

Képzeld el, hogy egy alkalmazás különböző területein három API-hívást hajtasz végre, ahol mindegyiknek pontosan ugyanazt a Swift-objektumot kell visszaadnia. Ebben a szerencsétlen API-ban történetesen mindegyik ilyen hívás kissé eltérő szótárkulccsal ad vissza adatokat; object_id, obj_id és Object_ID, amelyek mindegyike ugyanarra a tulajdonságra, az objectId-re kíván hivatkozni a létrehozni kívánt objektumon. Korábban egy dekódoló függvénynek egy sor “if-let” utasítással kellett ellenőriznie az azonosítót minden egyes ilyen kulcsban, mielőtt végül eldöntötte volna, hogy melyik értéket, ha egyáltalán, állítsa be a tulajdonságként.