Stop using Codable everywhere.

Mok5ha — Wed, 13 May 2026 11:24:57 +0000

You’ve been over-engineering your Swift models. “Should this model be Decodable or Codable? Am I doing this wrong?” — Here's how to pick the right one.

Swift doesn’t provide a single “JSON protocol.” It gives you three, each with a specific responsibility

Most networking code only needs Decodable
When your app fetches data and displays it, data flows one way — from the server into your models. The Decodable conformance is a signal to anyone reading this code: this model is read-only by design. You don’t need Codable here, just in case.

struct Article: Decodable {
    let id: Int
    let title: String
    let publishedAt: Date
    let author: Author
}

Use Codable when data moves in both directions
Two situations make Codable the right call:

You’re sending data back to a server

A request body going out as JSON, a form payload, a PUT with updated fields — anything where your Swift type needs to become JSON.

struct UpdateProfileRequest: Encodable {
    let displayName: String
    let bio: String
    let avatarURL: URL?
}

var request = URLRequest(url: endpoint)
request.httpBody = try JSONEncoder().encode(
    UpdateProfileRequest(displayName: "MG", bio: "iOS dev", avatarURL: nil)
)

Notice Encodable here, not Codable — because this request model will never be decoded from JSON. Same principle, different direction.

You’re persisting models locally

Saving user preferences, caching a response, storing settings in UserDefaults — any time you write a model to disk and read it back:


struct UserSettings: Codable {
    var theme: String
    var notificationsEnabled: Bool
    var lastSyncDate: Date
}

// Save
let data = try JSONEncoder().encode(settings)
UserDefaults.standard.set(data, forKey: "userSettings")

// Load later
if let stored = UserDefaults.standard.data(forKey: "userSettings") {
    let settings = try JSONDecoder().decode(UserSettings.self, from: stored)
}

Here Codable earns its place — you encode to save, decode to load.

A pattern worth keeping
In larger apps, separating request models from response models entirely pays off fast:

// Comes from the server — Decodable only
struct ProductResponse: Decodable {
    let id: Int
    let name: String
    let price: Double
    let inStock: Bool
}

// Goes to the server — Encodable only
struct AddToCartRequest: Encodable {
    let productId: Int
    let quantity: Int
}

// Lives locally, needs both
struct CartItem: Codable {
    let productId: Int
    var quantity: Int
    let addedAt: Date
}

Use the protocol that matches the data's actual behaviour. Nothing more.

DEV Community: Mok5ha

Stop using Codable everywhere.