Introduction

init(coder:) is the initializer used when an object is being created by decoding archived data rather than by a normal constructor call. In iOS development, you encounter it most often when a view or view controller is loaded from a storyboard or nib, because Interface Builder uses an NSCoder to reconstruct the object graph.

So the short answer is: aDecoder or coder is the object that knows how to read the saved representation and rebuild the instance.

What coder Actually Is

NSCoder is an abstraction for encoding and decoding object state. During decoding, it provides the values needed to recreate the object.

A typical initializer looks like this:

required init?(coder: NSCoder) {
    super.init(coder: coder)
}

The parameter name used to be written as aDecoder in older Objective-C and Swift examples. Modern Swift usually just calls it coder.

The meaning is the same: this parameter carries the archived data source for object reconstruction.

Why Storyboards Use It

When you instantiate a custom view from code, you usually call an initializer such as init(frame:). But when the same view is created from a storyboard or nib, iOS is decoding it from an archived interface file.

That means the system calls init(coder:) instead.

1import UIKit
2
3final class BadgeView: UIView {
4    required init?(coder: NSCoder) {
5        super.init(coder: coder)
6        commonInit()
7    }
8
9    override init(frame: CGRect) {
10        super.init(frame: frame)
11        commonInit()
12    }
13
14    private func commonInit() {
15        backgroundColor = .systemBlue
16        layer.cornerRadius = 10
17    }
18}

This pattern keeps initialization logic consistent whether the view comes from code or Interface Builder.

Why It Is Often required

In UIKit subclasses, init(coder:) is often marked required because the superclass requires that subclass implementations support decoding.

If the class might be created from a storyboard or nib and you do not implement this initializer correctly, the app can crash at runtime when the archived UI is loaded.

It Is Also Related to Archiving

Outside storyboards, NSCoder is also used in object archiving and unarchiving. Historically, classes could implement encoding and decoding to save and restore their state.

Example:

1import Foundation
2
3final class Person: NSObject, NSSecureCoding {
4    static var supportsSecureCoding: Bool = true
5
6    let name: String
7
8    init(name: String) {
9        self.name = name
10    }
11
12    required init?(coder: NSCoder) {
13        guard let decodedName = coder.decodeObject(of: NSString.self, forKey: "name") as String? else {
14            return nil
15        }
16        self.name = decodedName
17    }
18
19    func encode(with coder: NSCoder) {
20        coder.encode(name as NSString, forKey: "name")
21    }
22}

Here, coder is literally the object used to decode the archived property values.

Why People Get Confused

The name aDecoder sounds mysterious if you see it without context. It is not a special magic keyword. It is just an argument name from older Cocoa conventions.

This initializer is really saying: "build this object from the data that this coder can decode."

Once you see it that way, it becomes much less intimidating.

Common Pitfalls

• Thinking aDecoder is a special language feature rather than just a parameter name for an NSCoder instance.
• Implementing init(frame:) in a custom view but forgetting init(coder:), then crashing when loading from a storyboard.
• Duplicating setup logic instead of sharing it through a common initialization method.
• Calling the wrong superclass initializer inside init(coder:).
• Assuming init(coder:) is only about storyboards when it also appears in archiving and unarchiving patterns.

Summary

• 'init(coder:) is used to initialize an object from decoded archived data.'
• In storyboards and nibs, UIKit commonly creates objects through this initializer.
• 'aDecoder is just an older name for the NSCoder parameter.'
• Custom views often need both init(frame:) and init(coder:), with shared setup logic.
• The same idea also appears in object archiving and unarchiving, not just UI loading.