# The future of serialization & deserialization APIs

**URL:** <https://forums.swift.org/t/the-future-of-serialization-deserialization-apis/78585>\
**Category:** Discussion\
**Tags:** foundation, codable, macros\
**Created:** [March 17, 2025, 8:25pm UTC](https://forums.swift.org/t/the-future-of-serialization-deserialization-apis/78585 "2025-03-17T20:25:29Z")\
**Posts on this page:** 1\
**Showing post:** 20

<div class="post-metadata">

**Author:** ![nicklockwood](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/nicklockwood/32/3056_2.png) [@nicklockwood](https://forums.swift.org/u/nicklockwood)\
**Post date:** [March 18, 2025, 7:43am UTC](https://forums.swift.org/t/the-future-of-serialization-deserialization-apis/78585/20 "2025-03-18T07:43:28Z")

</div>

> [@kperryua](#):
>
> This design does not include support for encoding and decoding cyclical objects graphs. Relatedly, there's still no intention to include encoding of runtime type information in serialization formats for any purpose—all concrete types must be specified by the client doing the encoding or decoding.

I was really disappointed to see this, because these are probably my two major pain points with Codable.

If we are going to the trouble of making a brand new, backwards-incompatible replacement for Codable then it should try to correct all the major deficiencies of the existing design, not just performance.

NSCoding (for all its faults) supports both or heterogeneous data and cyclical references. If this new system doesn't support those then we are saying from the outset that it is still isn't going to be capable of dealing with a lot of real-world use-cases.

I understand the security implications of including type information in serialized data, but it's a super-common real-world use-case and if it's not a built-in feature then it should at the very least have first-class support for people who want to create their own such systems without starting from scratch.

Two very common patterns that I'd like to see supported out of the box are:

@JSONCodable  
enum PolymorphicPrimitive {  
case string(String)  
case int(Int)  
}

and:

@JSONCodable  
protocol PolymorphicObject {  
@CodableTypeKey  
let type: String  
...  
}

If CodableTypeKey needs to be an enum, or accept a fixed array of types as a parameter then so be it (although it would ideally allow any type that conforms to the protocol to support runtime registration of new types via plugins, etc).

---

_[View the full topic](https://forums.swift.org/t/the-future-of-serialization-deserialization-apis/78585)._