The synthesized Codable implementation relies exclusively on static type information available at compile time. When encoding a heterogeneous collection of class instances through a base class reference, the compiler generates encode(to:) code that only serializes properties visible to the base class type. Consequently, subclass-specific properties are omitted from the JSON output, and during decoding, the runtime lacks the necessary metadata to instantiate the correct subclass, defaulting to the base class instead and losing type-specific data.
We were building a financial analytics dashboard that processed various transaction types for portfolio management. The domain model used a class hierarchy where Transaction was the base class, with subclasses like StockTrade, DividendPayment, and FeeCharge adding specific properties such as tickerSymbol or dividendRate. The backend API returned a mixed JSON array of these transactions, each containing a transactionType discriminator field.
We initially relied on Swift's automatic Codable synthesis, assuming it would handle the polymorphic array [Transaction]. However, during integration testing, we discovered that encoding a [StockTrade] array cast to [Transaction] resulted in JSON that only contained base class fields like id and amount, completely omitting tickerSymbol. Conversely, decoding this JSON recreated only base Transaction instances, causing the app to crash when attempting to access subclass-specific properties that were expected to exist.
We considered three distinct approaches to resolve this limitation. The first involved manual Codable implementation where we explicitly added the transactionType field to the encoding container and implemented a custom init(from:) that switched on this discriminator to instantiate the correct subclass. This approach offered complete type safety and preserved the existing object graph, but required writing and maintaining significant boilerplate code for every new transaction type, increasing the risk of developer error when adding features.
The second solution explored using a type-erased AnyCodable wrapper or a protocol-oriented approach with existential types (any TransactionProtocol). While this allowed storing heterogeneous types in an array without inheritance, it sacrificed compile-time type safety and introduced runtime overhead from existential boxing and dynamic dispatch. It also complicated the API contract by forcing consumers to handle type erasure artifacts and casting, reducing code clarity.
The third option was refactoring the class hierarchy into a single enum with associated values, such as enum Transaction { case stock(StockData), case dividend(DividendData) }. Enums naturally support polymorphic serialization through synthesized Codable, as the compiler automatically generates a discriminator field. However, this would have required a massive refactor of the existing Core Data model and business logic throughout the application, carrying unacceptable regression risk for a production system.
We selected the first solution—manual Codable implementation with a discriminator field—because it localized changes to the serialization layer without disrupting the existing architecture or database schema. We implemented a factory method in the base class that decoded the type identifier first, then delegated to the appropriate subclass initializer based on the string value.
The result was a robust serialization pipeline that correctly handled the polymorphic API responses with full type fidelity. While it required approximately 200 lines of manual parsing code, it maintained backward compatibility with existing features and provided clear compile-time errors when developers added new transaction types but forgot to update the decoding logic, preventing runtime failures.
Why does casting a [Subclass] to [BaseClass] before encoding with JSONEncoder cause data loss for subclass-specific properties?
The synthesized encode(to:) method is dispatched statically based on the compile-time type of the value in the collection. When you cast to [BaseClass], the compiler selects BaseClass's synthesized implementation, which only iterates over properties declared in BaseClass. Subclass properties are invisible to this implementation because the static dispatch mechanism does not consult the dynamic type's metadata for synthesized methods. To preserve all properties, you must either encode using the concrete type or implement dynamic type resolution manually through a discriminator field.
How does the requirement for a required initializer interact with Decodable conformance in class hierarchies, and why does this prevent automatic subclass instantiation?
Decodable requires an init(from: Decoder) initializer. For classes, this must be marked required in the base class to allow subclasses to inherit the conformance. However, the synthesized implementation in the base class cannot dynamically determine which subclass to instantiate based on external data like a discriminator field. When the decoder encounters data representing a subclass, it calls the base class's init(from:), which only knows how to initialize the base class portion. To support polymorphic decoding, developers must override init(from:) in every subclass and implement a factory method that inspects the decoder's container to determine the concrete type before instantiation.
What is the fundamental difference between how Swift's synthesized Codable handles enums with associated values versus class inheritance, and why does this make enums suitable for polymorphic serialization?
Swift generates a discriminator key when synthesizing Codable for enums with associated values. The encoding includes the case name as a string key, and the decoding implementation switches on this key to reconstruct the correct case and its associated payload. This works because enums form a closed, sealed type hierarchy known exhaustively at compile time, allowing the compiler to generate a complete switch statement. In contrast, classes form an open hierarchy where new subclasses can be added in different modules. The compiler cannot generate an exhaustive switch for all possible subclasses when synthesizing the base class's Codable conformance, making it impossible to automatically handle the polymorphism without manual intervention.