Answer.

Extensions in Swift were introduced as a means to extend types — both standard (e.g., String, Array) and custom — without the need to create subclasses or modify the original source code. This allows adding new methods, computed properties, protocol subscriptions, and even conformances to protocols while maintaining readability and a unified architecture of the code.

The issue arises with excessive or disorganized usage of extensions: it can be easy to lose control over the original behavior of types, leading to name clashes, and it becomes harder to trace where something comes from, especially in large projects or when integrating third-party libraries.

The solution consists of a clear structure, organizing extensions into meaningful groups, explicit documentation, and avoiding conflicts with existing names, as well as limiting the scope when necessary (e.g., through fileprivate or internal).

Code example:

extension String {
    var isEmail: Bool {
        return self.contains("@") && self.contains(".")
    }
    func trimmed() -> String {
        return trimmingCharacters(in: .whitespacesAndNewlines)
    }
}

Key features:

Allows adding new methods, properties, and conformances to protocols without access to the source code.
Does not support the storage of new stored properties — only computed properties and functions.
Can be scoped using fileprivate/internal.

Trick questions.

Can you add a stored property through an extension?

No, an extension only allows adding computed properties and methods. Stored properties cannot be added through an extension. Try it — the compiler will throw an error immediately.

What happens if two different extensions declare methods with the same names for one type in different files?

There will be a name conflict, and Swift will not be able to determine which method to call, resulting in a compilation error.

Can extensions implement private methods that are only visible within the extension?

Yes, if you declare a method as private, it will be visible only within the extension itself and the file in which it is declared (if fileprivate is used).

extension Int {
    private func isEvenInternal() -> Bool {
        return self % 2 == 0
    }
    func publicCheckEven() -> Bool {
        return isEvenInternal()
    }
}

Common mistakes and anti-patterns

Anti-pattern: Adding a large number of different functions in one extension without logical grouping.
Mistake: Ignoring scope (e.g., a public extension for a function that uses internal details).
Name conflicts when working with libraries or writing extensions for the same type by different developers without a coordinated scope.

Real-life example

Negative case

In a large project, methods are added to String through extensions for everything — from email validation to JSON parsing. A year later, no one can understand where everything comes from: methods overlap in names, someone adds a new function without knowing about an old one, and breaks the behavior of dependencies.

Pros:

Quickly adds new functionalities without touching the main type.

Cons:

Confusion, duplication, errors, unpredictable behavior, difficulty in maintenance.

Positive case

The team uses extensions for logical groups: a separate extension for validation, another for formatting, with private helpers inside. All methods are documented, the use of new methods is discussed, and code reviews are conducted.