In Flutter on iOS, how does a UiKitView platform view compose with Flutter content, and which composition limits should you expect?

## One mode on iOS On Android, Flutter offers texture layer, hybrid composition, virtual display and experimental HCPP. On iOS there is only one: **hybrid composition**. The docs put it plainly — the native `UIView` is appended to the view hierarchy. What that means in practice: - The native view is a real `UIView` among Flutter's own layers, so it renders with full native fidelity. - Flutter content that overlaps the platform view from above is drawn into extra overlay layers on top of it. Every overlap adds composition work. - There is no texture copy of the native view in normal rendering, so there is no "switch to texture mode" to try. ## Creating one On the Dart side: ```dart UiKitView( viewType: 'com.example.property/map', creationParams: const <String, Object?>{'lat': 52.37, 'lng': 4.89}, creationParamsCodec: const StandardMessageCodec(), ) ``` On the Swift side, a class conforming to `FlutterPlatformViewFactory` creates a `FlutterPlatformView` whose `view()` returns the `UIView`; the factory is registered with the plugin registrar under the same `viewType`. SwiftUI content can be hosted by wrapping it in a `UIHostingController` and returning its `view`. ## Composition limits | Flutter effect over or on the native view | Status on iOS | |---|---| | Transforms, clips, opacity | Applied | | `ShaderMask` | Not supported | | `ColorFiltered` | Not supported | | `BackdropFilter` | Supported with limitations | If a design asks for a gradient fade (`ShaderMask`) over a map or a colour filter on a web view, plan an alternative on iOS — for example a Flutter-drawn overlay gradient placed above the view instead of a mask applied to it. ## Gestures on iOS The general forwarding model is the same as on Android: `gestureRecognizers` decides which gestures the native view may win. The extra iOS detail is **blocking** the `UIView`'s own `UIGestureRecognizer`s when Flutter wins. `UiKitView` exposes `gestureBlockingPolicy`, an enum `UiKitViewGestureBlockingPolicy`: 1. `eager` — block native recognizers as soon as Flutter decides they should be blocked; only `touchesBegan` is guaranteed to reach them. 2. `waitUntilTouchesEnded` — native recognizers see the whole touch sequence but never recognise; may let through touches that should have been blocked. 3. `doNotBlockGesture` — block based on hit testing only, without the gesture arena; a workaround for recognizers stuck in stale state, at the risk of recognising gestures that should have been blocked. 4. `fallbackToPluginDefault` (the default) — use the policy the plugin set when registering the view factory. Most apps never touch this; it exists for native views whose recognizers misbehave under aggressive blocking. ## Performance mitigation The docs' suggested technique for complex cases applies here too: if a Dart animation runs slowly while a platform view is on screen, take a snapshot of the native view and show it as a texture during the animation, then swap the live view back. ## Common misunderstandings - iOS platform views are not rendered into textures by default. - A `ShaderMask` that works over Flutter widgets will not mask the native view. - Changing Android's composition flags has no effect on iOS.