iPad Split‑Screen Adaptation and Multi‑Engine Flutter Integration

Background: In e‑commerce scenarios the iPad’s large screen can greatly improve the shopping experience, but adapting iPad split‑screen layouts and supporting multiple Flutter engines in a hybrid stack has been a long‑standing challenge. This article describes the difficulties encountered by Xianyu (Idle Fish) and the solutions adopted.

Split‑Screen Modes: Two main display logics are identified. The dual‑screen price‑comparison mode shows the newest view on the right screen and the second‑newest on the left, suitable for comparing multiple products. The dual‑screen navigation mode keeps the left screen fixed (e.g., a list) while stacking newer views on the right, similar to iPad settings.

Requirements: (1) Support left‑right split‑screen; (2) Preserve the stack‑based navigation (UINavigationController); (3) Minimize business transformation cost.

Technical Solution – Native iOS: A custom subclass NavigationControllerForiPad of UINavigationController is created to rewrite the push/pop layout logic without changing existing navigation code. The core implementation rewrites a ContainerViewController to control how new and old view controllers are arranged and animated.

-(void)pushViewController:(UIViewController*)newVC animated:(BOOL)animated{ ... }

- (nullable UIViewController*)popViewControllerAnimated:(BOOL)animated { ... }

Native UI Adaptation: All views are switched from absolute to relative layout using Auto Layout. The use of [UIScreen main].bounds.size is replaced by ViewController.view.bounds.size to correctly handle iPad multi‑screen sizes.

H5 Adaptation: Detect orientation changes to adjust layout, ensuring existing hard‑coded iOS adaptations are handled.

Flutter Multi‑Engine Integration: Xianyu’s core business is built with Flutter. To display multiple Flutter views side‑by‑side on iPad, a lightweight multi‑engine approach is required. The solution shares isolates across engines while keeping separate rendering pipelines. Shared resources include threads, Skia contexts, graphics contexts, image caches, isolate groups, and fonts. Each engine is identified by an application_id and treated as a separate Application.

bool DartIsolate::InvokeEntryPointInSharedIsolate(...){ int64_t application_id = platform_configuration->application_id(); ... }

Singleton handling in Dart is achieved by retrieving the current application via Application.current and then accessing the appropriate singleton, e.g., the window instance.

SingletonFlutterWindow get window => Application.current.get(SingletonFlutterWindow, () => SingletonFlutterWindow._(0, PlatformDispatcher.instance));

All rendering callbacks from Dart back to C++ also carry the application_id to ensure isolation between engines.

Summary: The implemented split‑screen modes and shared‑isolate multi‑engine architecture enable smooth iPad experiences and can be extended to Android foldable devices. The custom navigation controller and Flutter engine modifications will be open‑sourced after performance stabilization.