UIHostingController: Bridge SwiftUI into UIKit Apps

WHY IT EXISTS: Most large, mature iOS apps are built with UIKit. A complete rewrite in SwiftUI is often too costly and risky. UIHostingController was created to provide a migration path, enabling developers to adopt SwiftUI incrementally within their existing UIKit codebase.

THE MENTAL MODEL: Think of UIHostingController as a container or an adapter. It takes a SwiftUI View—which UIKit doesn't understand on its own—and places it inside a standard UIViewController subclass. This wrapped controller can then be presented, pushed, or embedded just like any other view controller in a UIKit application.

HOW IT WORKS: You initialize a UIHostingController with a root SwiftUI view. The controller then manages the lifecycle of this view, automatically translating UIKit events (like viewWillAppear or viewDidLayoutSubviews) into updates for the SwiftUI view hierarchy. It renders the SwiftUI content into a UIView that serves as the controller's main view.

WHEN TO USE IT: Use it when you want to introduce SwiftUI into a UIKit project. Three common scenarios are: first, building an entire new screen in SwiftUI and pushing it onto a UINavigationController; second, replacing the content of a UITableViewCell with a declarative SwiftUI view; third, embedding a small SwiftUI component (like a custom chart) inside a larger UIKit screen.

WHEN NOT TO USE IT: Do not use UIHostingController in a pure SwiftUI application; it's exclusively a bridging tool for mixed codebases. Also, be cautious about performance when embedding many hosting controllers or when data changes frequently across the UIKit-SwiftUI boundary, as the bridging layer has some overhead.

ONE CANONICAL EXAMPLE: To present a SwiftUI SettingsView from a UIKit button tap, you would write: let swiftUIView = SettingsView(); let hostingController = UIHostingController(rootView: swiftUIView); self.present(hostingController, animated: true);. The hostingController behaves exactly like a standard UIViewController here.