Skip to main content
This guide covers how to embed the bridge-connected WebView in your iOS application, including SwiftUI and UIKit integration patterns.

SwiftUI Integration

For SwiftUI apps, BridgeWebView is the fastest path: drop it into a view, give it a URL and a host, and you have a fully wired bridge. Use the patterns below for state observation, child-view passing, and dynamic URLs.

Using BridgeWebView

BridgeWebView is the recommended way to embed a bridge-connected WebView in SwiftUI. It handles all setup automatically.

Observing Bridge State

Because BridgeHost is an ObservableObject, you can react to state changes directly in your SwiftUI views.

Passing the Host to Child Views

Use @ObservedObject in child views that receive the host as a parameter.

Dynamic URL Changes

BridgeWebView supports URL changes. If you update the URL binding, the WebView navigates to the new URL.

UIKit Integration

For UIKit apps (or SwiftUI apps that need a custom WKWebViewConfiguration), use BridgeWebViewConfigurator to wire the bridge into a WebView you create yourself.

Using BridgeWebViewConfigurator

For UIKit-based apps, use BridgeWebViewConfigurator to configure a WKWebView with the bridge.

Configuring an Existing WebView

If you have a WKWebView created with a custom WKWebViewConfiguration, use BridgeWebViewConfigurator.configure(_:host:).
This approach is useful when you need custom WebView settings (media playback, data detection, process pools, etc.) that makeWebView doesn’t configure.

Lifecycle Considerations

The BridgeHost and the WebView have different ownership semantics β€” the host holds a weak reference to the WebView, and handlers should be set up before content loads. Keep these in mind to avoid leaks, attachment errors, and missed messages.

Host Lifetime

The BridgeHost should live at least as long as the WebView. In SwiftUI, use @StateObject to ensure the host isn’t recreated on view updates. In UIKit, hold a strong reference as a property.

WebView Detachment

BridgeHost holds a weak reference to the WebView. If the WebView is deallocated while the host is still alive, attempts to send messages will set lastError to "WebView not attached". This is by design β€” it prevents retain cycles.

Re-attaching a WebView

If you need to replace the WebView (e.g., after a navigation reset), call BridgeWebViewConfigurator.configure(_:host:) with the new WebView. The host automatically updates its internal reference.

Setting Up Handlers

Set handlers on typed slots or register custom capabilities before the WebView loads content. If the web journey sends a request before a handler is available, the request goes to pendingRequests.
BridgeWebView provides a basic WKNavigationDelegate via its Coordinator. If you need custom navigation behavior (e.g., intercepting links, handling authentication challenges), you have two options:
  1. UIKit path: Use BridgeWebViewConfigurator and set your own navigation delegate on the WebView.
  2. SwiftUI path: Build a custom UIViewRepresentable that uses BridgeWebViewConfigurator internally.

Next Steps