We have differing definitions for boilerplate code. If a methodology requires me to write 14 initializers, each differing by only a single value, then that qualifies in my book.

And then if I'm forced to implement 14 different getters and setters or mutating actions just to update a value... then that's boilerplate code too.

Especially when, as repeatedly pointed out, Swift provides sufficient protections on struct values by enforcing COW semantics within the code itself.

And yes, breaking a Codeable struct down could be a solution... unless, and as also repeatedly pointed out, the real-world API doesn't allow for it and the app has to use what's provided.

Purely immutable structures are a "best practice" in other languages and on other platforms where objects are reference types and where changing a value here also changes the value there.

Swift structs have value semantics and as such they're... Simply. Not. Necessary.

I've pointed this out. People on the SE forums have pointed this out. But if immutable structs float your boat you can write them that way if you wish. I mean, you're creating extra work for yourself for little to no benefit, but hey, feel free.

Meanwhile, I'll write less code and fewer tests and continue to remind people that Swift has their back.