Introduction

This Swift runtime error means the program tried to bridge an Objective-C array into a strongly typed Swift array, but the contents did not match the expected element type. The problem is rarely "Swift hates Objective-C." It is usually that an NSArray was declared too loosely, contained mixed objects, or was force-cast into a Swift array type that the actual data could not satisfy at runtime.

Understand What Swift Is Trying to Bridge

Objective-C arrays are typically NSArray or NSMutableArray. They store Objective-C object references, but they do not enforce Swift-style generic element safety at runtime.

Example Objective-C style return:

- (NSArray *)fetchItems {
    return @[@"A", @"B", @"C"];
}

On the Swift side, this is usually fine if you cast to the correct type:

if let items = obj.fetchItems() as? [String] {
    print(items)
}

The crash appears when the actual array contents do not match the assumed Swift type.

The Most Common Failure Pattern

This is the usual problem:

let items = obj.fetchItems() as! [String]

If fetchItems() returns an NSArray containing anything other than bridged String objects, the forced cast can crash.

For example, if the array actually contains:

• 'NSString'
• 'NSNumber'
• 'NSNull'
• custom Objective-C objects

and Swift is told it must be [String], the bridge fails if any element is incompatible with that exact array type.

Fix the Objective-C Side First When Possible

The best fix is often to make the Objective-C API more specific and predictable.

Modern Objective-C supports lightweight generics:

- (NSArray<NSString *> *)fetchItems {
    return @[@"A", @"B", @"C"];
}

This improves Swift import behavior and communicates the intended element type clearly.

If the array may contain null placeholders, use a better model instead of sneaking NSNull into a supposedly typed collection. Mixed-type arrays are legal in Objective-C but awkward in Swift because Swift wants an actual element type.

Cast Safely on the Swift Side

If you do not fully control the Objective-C source, cast defensively:

1if let rawItems = obj.fetchItems() as? [Any] {
2    let strings = rawItems.compactMap { $0 as? String }
3    print(strings)
4}

This avoids a fatal crash and makes the type mismatch visible in code.

If all elements should truly be strings, using compactMap may hide a data-quality problem. In that case, fail explicitly instead of silently dropping bad values.

For example:

guard let items = obj.fetchItems() as? [String] else {
    fatalError("Expected NSArray of NSString-compatible values")
}

This is still strict, but at least the error reflects your real contract instead of happening unexpectedly deeper in the code.

Watch for Nested Collections and Bridging Assumptions

Bridging gets even trickier with nested collections. An NSArray of NSArray values does not automatically become [[String]] unless every nested array also satisfies the expected type.

Likewise, bridging custom Objective-C model objects into Swift arrays works only if you cast to the imported Objective-C class type, not to a structurally similar Swift type that happens to have the same fields.

The general rule is:

• bridge to the actual imported object type first
• then transform into native Swift models if needed

That produces clearer and safer code than forcing a deep bridge in one step.

Common Pitfalls

• Force-casting an Objective-C NSArray to a Swift array type without validating the actual element contents.
• Returning loosely typed Objective-C arrays when the API really expects one concrete element type.
• Letting NSNull leak into collections that Swift code expects to be ordinary values.
• Assuming nested arrays or custom objects bridge automatically to arbitrary Swift generic shapes.
• Debugging the Swift cast only, when the real problem is that the Objective-C API contract is underspecified.

Summary

• This bridging crash usually means the Objective-C array contents do not match the Swift array type being demanded.
• The cleanest fix is often to make the Objective-C API more strongly typed with lightweight generics.
• Avoid force-casting unless you truly control and trust the array contents.
• Bridge to broad types first when needed, then transform deliberately into native Swift values.
• Treat array bridging as an API-contract problem, not just a casting syntax problem.