How Taro’s Custom iOS Rendering Layer Achieves High‑Performance Cross‑Platform UI

Background

Taro’s cross‑platform ecosystem already supports H5, mini‑programs, and HarmonyOS, and aims for a “one‑code‑five‑platform” vision that includes high‑performance containers on iOS and Android.

Why a Self‑Developed Solution?

Existing industry solutions cannot simultaneously satisfy the following requirements: High performance: Near‑native speed for first‑screen load, FPS, and memory usage. High stability: Low crash and OOM rates for critical scenarios such as orders, shopping carts, and search. Taro ecosystem compatibility: Reuse code across mini‑programs, HarmonyOS and other platforms with consistent visual and interaction experience. Native inter‑operability: Embed native components, align rendering timing, and resolve gesture/scroll conflicts. Low integration cost: Leverage existing native APIs with minimal package‑size increase.

Solution Overview

Taro implements two core components to meet these constraints: iOS Rendering Layer: Provides high performance and strong native inter‑operability. TaroUI: Offers high cross‑platform consistency, Taro‑ecosystem compatibility, and extensible UI capabilities.

iOS – High‑Performance Rendering Layer

Taro’s runtime introduces a JS engine, React framework, complex CSS parser, and package manager, which improve development efficiency but add logical overhead compared with pure native execution. Therefore, Taro must deliver a rendering solution that outperforms native while supporting seamless native inter‑operation.

Rendering Container Architecture: Engine‑View Decoupling

Taro adopts a double‑thread rendering pipeline and separates the view container from the runtime, dramatically improving first‑screen performance and enabling richer pre‑warm capabilities for future scenarios.

Double‑Thread Rendering Pipeline

: A JS thread handles business logic, DOM operations, animation and layout; a UI main thread handles native view manipulation, layout and text rendering, fully exploiting multi‑core CPUs. First‑Screen Parallel Rendering: JS and UI threads run in parallel, boosting first‑screen load without requiring developers to write separate code paths. High Pre‑Warm Design: Decoupled runtime and view container allow engine pre‑creation, business‑logic pre‑execution, native‑view pre‑rendering, and resource pre‑fetching (images, cache data). Single Engine Multiple View Containers: One rendering engine can drive multiple independent view containers, facilitating future runtime scenarios.

Mixed Native View + Layer Rendering Mode

Taro iOS uses a mixed mode (native View + layer) that reuses iOS CoreAnimation and Render Server for layer‑tree management, compositing, dirty‑region repaint, caching, and GPU scheduling. This delivers high‑performance complex rendering while keeping visual consistency with native components.

Native View

Native View Rendering

: Implements system native View, ScrollView, and Input components. Strong Native Inter‑operability: Taro views can be embedded in native pages and vice‑versa, with touch/gesture conflict resolution. Smooth Scrolling Experience: Native ScrollView provides native‑level scrolling performance and handles nested scrolling. Reuse System Ecosystem: Low‑cost adaptation to accessibility, VisionOS, and other system capabilities.

Layer Rendering

High‑Performance Layer Rendering

: Uses Image, Text, and partial View components; layers are lightweight (no touch, layout, or accessibility) and reduce memory consumption. Lightweight Design: Avoids heavy drawing libraries like Skia, keeping package size and maintenance cost low.

Future Canvas components will provide 2D/3D graphics drawing capabilities for complex rendering scenarios.

Rendering Pipeline Optimizations

Automatic Layer Rendering Optimization

: Runtime automatically decides whether to use layer rendering based on view type, allowing layers and Views to coexist with consistent visual output. Automatic View Flattening: Real‑time flattening of simple Views reduces hierarchy depth, cutting native View node count by ~50% in order‑list scenarios. Fine‑Grained View Atomic Commands: After DOM diff, generates atomic commands (Create, Insert, Update, Delete) to minimize redundant rendering. Native Component Reuse Pool: Caches native components for large updates or long‑list scrolling, reducing creation/deletion overhead. Layout Optimization: Caches layout calculations to lower repeated work, improving scroll FPS and reducing CPU usage for animations. Image Rendering Optimization: Optimizes image and GIF rendering, decreasing main‑thread time by over 30%. Memory Optimization: Multi‑round tuning reduces node‑tree memory consumption by >20% compared with earlier versions.

High‑Performance Rich‑Text Engine

Built on CoreText, the engine employs multi‑layer caching (text objects, measurement, lines, fonts) and hash‑based optimizations to achieve high cache reuse, supporting CSS‑aligned styling, async drawing, and rich‑text features such as nested Text/Image/View with event handling.

High Cache Reuse Rate

: Multi‑layer cache design dramatically improves reuse and lowers memory usage. Rich Text Capabilities: Supports single/multi‑line, nested Text/Image/View, and touch/event response. CSS Alignment: Implements color, font, font‑size, line‑height, text‑align, text‑overflow, vertical‑align, matching CSS specifications. Async Drawing: Delays text drawing to post‑first‑frame, improving perceived first‑screen performance.

Rendering Capability Completeness

Component Support

: View, Image, Text, ScrollView, Input, Sticky, nested scrolling, and custom native component injection. CSS Property Support: Background, border, radius, shadow, transform, text styles, etc. Layout Calculation: Flex, margin, padding, absolute positioning. Rich Text Support: Multi‑level nested text/image/view rendering. Accessibility Support: Basic accessibility capabilities.

TaroUI – Cross‑Platform UI Base

Background

Different cross‑platform scenarios (pages, floor cards) and developer ecosystems (Web, KMP, custom DSL) create diverse requirements, making a single framework insufficient.

Consistency Requirements

Uniform rendering, API scheduling, event system, animation, and thread model are essential; traditional native‑centric approaches lead to high duplication cost and inconsistent behavior.

Consistent Core Capabilities

: Component API, event dispatch, animation, rendering pipeline, thread model. Issues with Native‑Centric Implementations: High duplication cost, inconsistent behavior, high adaptation effort for new platforms.

Architecture and Technical Implementation

A C++ core combined with native components reduces native development overhead, improves visual consistency, and lowers JNI transmission costs on Android.

Native Atomic Components

: System View wrappers for View, Text, Image, ScrollView, Input, optimized for performance and visual consistency. C++ Basic Components: Direct mappings for the same atomic components plus high‑frequency, complex components such as Swiper, List, Waterflow, RecycleList, Page.

Touch / Event System

Touch System

: Supports onTap, onLongTap, onMoveStart, onTouchMove, onTouchEnd, onTouchCancel, and event bubbling, aligned with Taro specifications. Event Handling: Component event binding and bidirectional communication between view and logic layers.

Rendering Pipeline Scheduling

TaroUI defines a standardized, time‑consistent rendering pipeline that drives the underlying rendering layer and provides an event queue with micro‑tasks, macro‑tasks, and timers.

High‑Performance Virtual List Components

List, Waterflow, and RecycleList address FPS and memory challenges in long‑list scenarios by using sliding‑window scheduling to render only a subset of items.

List / Waterflow

: Single‑column and multi‑column list components with real‑time window updates. RecycleList: Recyclable single‑row list offering stable memory usage for infinite scrolling.

Extensibility Design

More Platform Extensions

: C++ core enables low‑cost expansion to additional platforms. Independent Runtime: Declarative API decoupled from the upper‑level runtime, allowing reuse in various scenarios.

Business Deployment

The iOS/Android cross‑platform solution is already used in core business modules such as order lists/details, search, international versions, and category pages.

Future Planning

Technical Vision

Transform TaroUI into an industry‑competitive, general‑purpose UI infrastructure with high cross‑platform consistency, lightweight core, full‑platform support (iOS, Android, HarmonyOS, Windows), multiple rendering modes (native and self‑draw), and applicability to various scenarios (pages, floor reuse).

2026 Roadmap

Performance Optimization

: Reusable list enhancements, native‑level animation, rendering pipeline tuning, richer pre‑warm capabilities, memory reductions. Capability Expansion: Complex gestures, main‑thread UI, 2D graphics drawing. Cross‑Platform Ecosystem Building: Continue refining TaroUI standards and specifications.