W powyższym przykładzie, pomimo dodania funkcji inicjalizującej, wyeliminowaliśmy potrzebę stosowania wielu dosłownych instrukcji „if-let” i „guard-else” podczas parsowania kodu (niezbędnych tylko podczas obsługi opcjonalnego powrotu z tworzenia adresu URL). Dodatkowo, zauważ, że zwykła, nieopcjonalna właściwość id oraz opcjonalna właściwość caption są parsowane przy użyciu tej samej składni kodu. Pierwszy parametr funkcji dekodującej dla caption określa, że oczekuje wartości opcjonalnej przez dołączenie znaku zapytania po oczekiwanym typie danych.

W tym momencie nasz kod parsujący zbliża się do długości oryginalnego obiektu non-Codable. Jednak nowy kod jest bardziej przejrzysty i oddziela obszary kodu, w których często zdarzają się literówki (łańcuchy określające klucze JSON), w łatwo identyfikowalne enum.

Dzięki oddzieleniu kluczy JSON w enum i wyeliminowaniu potrzeby większości instrukcji „if-let” i „guard-else”, protokół Codable pokazany powyżej daje nam dużo miejsca do budowania na naszych obiektach bez drastycznego zwiększania złożoności kodu.

Osoby lub zespoły, które zarządzają zarówno swoim kodem back-end, jak i front-end, generalnie mają swobodę ciągłego dostosowywania swojego modelu danych do pracy z ich modelami wizualnymi, z niewielką logistyką napowietrzną (jeśli nigdy nie byłeś na spotkaniu pomiędzy równie upartymi programistami front-end i back-end, licz się ze swoim szczęściem). Dla tych, którzy należą do tej kategorii, korzyści z wdrożenia Codable to posiadanie obiektów Swift zadeklarowanych i parsowanych z jak najmniejszą ilością kodu i nadążanie za najlepszymi praktykami i oczekiwaniami Apple. Jeśli jednak jesteś w dużym zespole programistycznym zajmującym się interfejsami API dostarczanymi przez oddzielny podmiot, w którym nie możesz kontrolować czasu lub szczegółów zmian danych, których oczekujesz, Codable może być twoją świecącą latarnią nadziei pośród szaleństwa.

Wyobraź sobie wykonanie trzech wywołań API w różnych obszarach aplikacji, gdzie każdy z nich ma zwrócić dokładnie ten sam obiekt Swift. W tym niefortunnym API, każde z tych wywołań zdarza się zwracać dane z nieco innym kluczem słownikowym; object_id, obj_id, i Object_ID, wszystkie zamierzające odnosić się do tej samej właściwości, objectId, na obiekcie, który masz na celu utworzyć. Poprzednio, funkcja dekodująca musiałaby mieć serię instrukcji „if-let”, aby sprawdzić id w każdym z tych kluczy, zanim ostatecznie zdecyduje, która, jeśli w ogóle, wartość ma być ustawiona jako właściwość.