Introduction

In Swift, you generally cannot override a superclass property and change its type in the subclass. Swift keeps inheritance type-safe, so if the base class promises that a property is one type, callers must be able to rely on that promise even when they are holding an instance of a subclass.

Why Swift Rejects the Different-Type Override

Suppose the base class defines a property like this:

class Animal {
    var name: String = ""
}

Trying to override it with a different type fails:

1class NumberedAnimal: Animal {
2    override var name: Int {
3        get { 1 }
4        set { }
5    }
6}

This is not allowed because code written against Animal expects name to be a String. If Swift allowed a subclass to silently replace that with Int, ordinary polymorphism would break.

The important idea is that inheritance is a subtype relationship. A subclass must still behave like the superclass from the outside. Changing a property type violates that contract.

Use the Same Type or a Different Design

If the property is genuinely the same concept, keep the same type and customize behavior through getters, setters, or validation:

1class Animal {
2    var name: String = ""
3}
4
5class TrimmedAnimal: Animal {
6    override var name: String {
7        get { super.name }
8        set { super.name = newValue.trimmingCharacters(in: .whitespacesAndNewlines) }
9    }
10}

This is a valid override because the public type contract remains String.

If the subclass truly needs a different kind of value, that is usually a sign that the property should not be part of the shared superclass API in the first place.

Better Alternatives When Types Differ

One common alternative is to redesign the hierarchy with generics:

1class Box<Value> {
2    var item: Value
3
4    init(item: Value) {
5        self.item = item
6    }
7}
8
9let stringBox = Box(item: "hello")
10let intBox = Box(item: 42)

Now the varying type is part of the class definition instead of something the subclass tries to replace later.

Another option is to move the shared API behind a protocol:

1protocol NamedEntity {
2    associatedtype Value
3    var value: Value { get }
4}
5
6struct StringEntity: NamedEntity {
7    let value: String
8}
9
10struct IntEntity: NamedEntity {
11    let value: Int
12}

This is often a better fit when the real commonality is behavior rather than a fixed property type.

Use a New Property Instead of a Fake Override

If you must subclass an existing framework type and also expose a more specific representation, add a separate property instead of pretending the inherited one changed type.

1class Animal {
2    var name: String = ""
3}
4
5class TaggedAnimal: Animal {
6    var numericTag: Int = 0
7}

This may feel less elegant at first, but it is honest. The inherited API remains valid, and the subclass adds new information without violating the superclass contract.

You can also bridge between representations with computed properties:

1class Animal {
2    var name: String = ""
3}
4
5class TaggedAnimal: Animal {
6    var numericTag: Int? {
7        get { Int(name) }
8        set { name = newValue.map(String.init) ?? "" }
9    }
10}

Here the inherited name property still exists as a String, and the subclass offers a typed view for callers who want it.

Common Pitfalls

The biggest mistake is assuming methods and properties have the same flexibility for covariant typing. Swift is much stricter about property overrides because writable properties must preserve both read and write type safety.

Another issue is trying to force the design with Any in the superclass. That can compile, but it usually throws away useful type information and makes the API harder to reason about.

Developers also sometimes choose inheritance when composition or generics would model the domain more clearly. If two subclasses need fundamentally different property types, the shared superclass may be the wrong abstraction.

Finally, be careful with framework types. If you subclass something from UIKit or another Apple framework, changing the meaning of inherited properties through awkward workarounds can create confusing behavior for future maintainers.

Summary

• Swift does not generally allow overriding a superclass property with a different type.
• The reason is type safety: subclass instances must still satisfy the superclass contract.
• Valid overrides keep the same public property type and only change behavior.
• If the type truly differs, prefer generics, protocols, composition, or a new property.
• A failed different-type override is usually a design signal, not just a syntax obstacle.