Introduction

Unknown class in Interface Builder file means a storyboard or XIB references a custom class name that the app cannot resolve at runtime. In Xcode 7.1 and Swift 2, the usual causes are wrong module settings, renamed classes, missing target membership, or stale storyboard metadata.

What Interface Builder Is Trying To Do

When a storyboard loads, UIKit reads archived class names from the Interface Builder file and tries to instantiate those classes. If the class is missing or the module name no longer matches, the loader falls back to an unknown-class error.

So the root question is not just "does the Swift file exist," but "can the compiled app resolve the exact class name stored in the storyboard?"

Check The Custom Class And Module First

Open the affected scene in Interface Builder and inspect the Identity Inspector.

Verify:

• the Custom Class name is correct
• the Module field points to the app target or correct framework
• 'Inherit Module From Target is enabled when appropriate'

A common failure happens after moving code into another target or framework. The class still exists, but the storyboard points at the old module.

Renames Often Leave Storyboard References Behind

If you renamed ProfileViewController to UserProfileViewController, the Swift compiler sees the new class, but the storyboard may still reference the old name.

A minimal class should look like this:

1import UIKit
2
3class UserProfileViewController: UIViewController {
4    override func viewDidLoad() {
5        super.viewDidLoad()
6    }
7}

If the storyboard still says ProfileViewController, loading will fail even though the project builds.

Confirm Target Membership

Open the Swift file and check the File Inspector. The file must belong to the target that builds the storyboard's app or framework.

If target membership is missing, the class compiles nowhere relevant to that app bundle, so Interface Builder cannot instantiate it at runtime.

This is especially common after copying files between targets.

Clean Old Build Artifacts After Fixing References

Xcode sometimes keeps stale build products or cached storyboard metadata around long enough to confuse debugging. After fixing the class or module mapping, do a clean rebuild.

Typical sequence:

1. clean the build folder
2. rebuild the target
3. rerun the app

If the issue started after heavy refactoring, reopening Xcode can also help flush stale state.

Storyboard XML Can Reveal The Real Class Name

If the UI inspector looks correct but the error persists, open the storyboard as source and search for the old class name. Sometimes an outdated reference remains in the XML even after visible settings appear fixed.

That is especially useful when the error comes from a nested view, table cell, or custom reusable component rather than the obvious view controller.

Common Pitfalls

The most common mistake is fixing the Swift class name but forgetting the storyboard's Custom Class entry.

Another common problem is a correct class name with the wrong module after target or framework changes.

Developers also often forget target membership, especially after copying source files.

Finally, a successful build does not prove Interface Builder can resolve the class. Runtime loading uses the archived storyboard metadata, not just the current source tree.

Summary

• The error means storyboard metadata does not resolve to a runtime class.
• Check the Custom Class name and Module field first.
• Verify the Swift file is in the correct target.
• Search storyboard XML if visible settings look correct but the error remains.
• Clean and rebuild after fixing stale Interface Builder references.