iOS ViewManager: Native UI Bridge Factory

WHY IT EXISTS: React Native draws most UI with JavaScript and Yoga layout, yet some pixels only iOS can produce. Core Animation layers, camera buffers, and MapKit tiles live inside UIKit and cannot be rebuilt with cross-platform primitives. The ViewManager exists so JavaScript can request, configure, and position these native surfaces without leaving the React programming model. It keeps the native view hierarchy synchronized with the React shadow tree.

THE MENTAL MODEL: Treat the ViewManager as a remote factory, not the product. JavaScript holds a component tag, but the actual UIView is manufactured and owned by the native side. The manager receives prop updates like a configuration sheet and applies them to the view it previously vended. It does not render pixels itself; it tells an existing native widget how to behave inside a React Native screen.

HOW IT WORKS: You subclass RCTViewManager in Objective-C or Swift and implement the view method to return a new UIView instance. You export writable properties with RCT_EXPORT_VIEW_PROPERTY, which wires setters so prop changes from JavaScript automatically invoke native methods. The React Native bridge maintains a registry mapping React component tags to these native views. When the shadow tree diff runs, the bridge dispatches creation, update, and deletion commands to the manager on the appropriate queues. If you need imperative commands, expose methods via RCT_EXPORT_METHOD and target them by tag.

WHEN TO USE IT: Use a ViewManager when you need an iOS-specific visual primitive that JavaScript cannot approximate with acceptable performance. Good candidates include wrapping MKMapView for native maps, exposing AVCaptureVideoPreviewLayer for camera input, embedding a WKWebView for complex web content, or surfacing a Metal renderer for high-frequency drawing. It is also the right choice when you must respect platform behavior like UIKit gesture exclusivity or Core Animation timing.

WHEN NOT TO USE IT: Do not build a ViewManager for visuals that React Native can already draw with standard components. If you only need to trigger an action or fetch data, use a native module instead, because ViewManagers are for views, not logic. Avoid them when the component is purely presentational and cross-platform, since maintaining separate managers for iOS and Android duplicates effort without benefit. Also skip this path if you need to share complex state across many native views, because the manager pattern isolates each view instance.

ONE CANONICAL EXAMPLE: A video player overlay is the textbook use case. You create a VideoViewManager that returns an AVPlayerLayer-backed UIView. JavaScript passes a source URL prop, which the manager maps to an AVPlayerItem. The manager also exposes a seek command so JavaScript can scrub playback without re-rendering the entire subtree. The video frames decode on the GPU through AVFoundation, something JavaScript could never do directly, while React Native handles the surrounding layout and gestures.