Kuikly Cross-Platform Architecture for Financial AI Apps: A Three-Platform Case Study

Background: From H5 Bottlenecks to Cross-Platform Engineering

As Changjiang Securities expanded from single-page securities services to market data, trading, news, and AI services, the traditional H5 approach hit experience bottlenecks while three-end native development costs grew. Each new feature required separate Android, iOS, and HarmonyOS implementations, leading to low verification efficiency, inconsistency across platforms, maintenance difficulties, and constant context switching. H5 pages (e.g., hot-spot review, conditional orders, wealth-management mall) had to support all three platforms but struggled to match native performance, host capabilities, and were constrained by network quality for dynamic resource delivery.

The team evaluated Kuikly, a KMP-based cross-platform framework open-sourced by Tencent, against native and H5 on the same device, network, and comparable business complexity. Metrics included page-entry latency, P95 long-tail latency, interaction-phase resource usage, and jank. Kuikly's overall experience approached native, improving most key metrics over H5, especially on HarmonyOS page-entry and scrolling. This validated further engineering adoption.

Why Kuikly: Respecting Existing Engineering Boundaries

The three target platforms (Android, iOS, HarmonyOS) are not greenfield: login, trading, market data, permissions, analytics, routing, and theming already run in each host. Any cross-platform solution requiring full rewrite of these capabilities would cost more than it saves. The premise: the cross-platform layer must enter hosts incrementally; native continues to own what it does best and must own.

H5 remains efficient for fast-changing, display-heavy scenarios with mature release pipelines. However, complex interactions and native capability coordination turned WebView, page lifecycle, JS Bridge, and three-end compatibility into engineering burdens affecting user experience. Kuikly was chosen for its alignment with the team's Kotlin stack, flexible KuiklyDSL, near-native runtime experience, controllable binary-size increment, low legacy migration cost, three-platform coverage, and dynamic-update support.

AI Hot-Spot Review: First Production Pilot

The hot-spot review feature was chosen as the first pilot because it is non-trivial: multiple pages (main, skill switching, sector search), complex state (date, skill, sector, stock), gesture-driven card animations, timeline and Q&A expand/collapse, stock-detail navigation and watchlist collaboration, dark/light themes, exposure tracking, and asynchronous data. It stress-tests cross-platform engineering boundaries.

Migration followed four AI-assisted phases:

Read H5/Vue source to inventory pages, components, data sources, bridges, and assets.

Ingest official documentation into a local knowledge base, generating dependency specs and rule files.

Apply H5/Vue → Kuikly transcoding Skill: migrate models, state, and APIs first; then generate KuiklyDSL page structure; finally implement business logic in Kotlin. First-pass UI fidelity reached ~90% per internal acceptance criteria; complex interactions were refined via human-AI collaboration.

Compile and run in Demo, iteratively aligning layout, gestures, animations, and lifecycle. The goal of AI's first output is not production-ready code but a compilable, runnable, comparable page skeleton. As the project knowledge base and official capabilities accumulate, subsequent pilots (trading conditional orders, OA business) achieved ~95% first-pass fidelity, with remaining work focused on code review and complex-interaction calibration.

Lightweight Component Architecture

In the Kuikly business layer the team adopted a lightweight componentized page architecture rather than strict MVC or standard MVVM. This avoids forcing a ViewModel layer while preventing a single massive page class from holding all state and events.

Card-Stack Interaction: From "Looks Animated" to "Explainable Logic"

Take the card-switching interaction. The deck's drag offset, scale, opacity, and animation lock are UI transient states, so they live with the deck component, not in page-level state. Reading the deck effect requires only one responsibility file. The interaction is not a simple left/right page swap; during drag:

Top card follows finger horizontally.

Rear cards rise, enlarge, and brighten per drag progress.

Past threshold, top card flies out completely.

Below threshold or at boundaries, all cards spring back.

First and last cards auto-adjust deck expansion direction.

Card area supports both tap and outer vertical scroll.

Real multi-layer cards are used instead of simulating stacks with background images. Each layer computes scale, translation, opacity from the same reactive state, enabling continuous rear-card changes during drag. Content cannot be swapped immediately when threshold is crossed; otherwise the new card would appear before the old one finishes flying out. Hence, after threshold, top card executes fly-out animation while rear cards rise synchronously; on animation end, current card updates, transforms reset, and animation lock releases. During spring-back, the extra placeholder layer used only for successful transition is hidden promptly to avoid fleeting duplicate cards. Partial implementation:

internal fun AiHotReviewPage.finishBlockPan(deltaX: Float) {
  if (abs(deltaX) <= BLOCK_SWIPE_THRESHOLD_POINTS) {
    reboundBlockCard()
    return
  }
  val direction = if (deltaX < 0f) {
    SWIPE_DIRECTION_NEXT
  } else {
    SWIPE_DIRECTION_PREVIOUS
  }
  val targetIndex = targetBlockIndex(direction) ?: run {
    reboundBlockCard()
    return
  }
  blockStackState.isBlockTransitioning = true
  blockStackState.blockDragOffsetX = if (direction == SWIPE_DIRECTION_NEXT) {
    -pagerData.pageViewWidth
  } else {
    pagerData.pageViewWidth
  }
  schedulePageTimer(BLOCK_CARD_ANIMATION_DURATION_MS) {
    viewModel.selectBlock(targetIndex, BlockSelectionSource.SWIPE)
    resetStackTransforms()
    blockStackState.isBlockTransitioning = false
  }
}

Host Lifecycle Contract

Multiple Kuikly Views can be retained in the host to speed up back navigation, but only the top-of-stack View may be in resumed state. When a child page is pushed, the root pauses; on pop, the current page detaches first, then the previous page resumes. If the host only forwards Activity/ViewController foreground/background events, the root never receives a signal that it became visible again. This rule was added to the three-end contract: on page return, consume one-time results and refresh in pageDidAppear to avoid reopening the previous page or firing duplicate requests.

APNG components are also used; decoding, playback, and local resource resolution remain host responsibilities.

The pilot confirmed: KuiklyDSL's value lies not in "translating pages" but in first separating state, rules, data, and host boundaries, then letting DSL express only the page.

Four-Layer Engineering: Answering Real Debugging Problems

The initial single-module design placed pages, shared components, mocks, and test buttons together in Shared. The first page ran quickly, but adding more businesses caused three problems: interface layer and Bridge capabilities depend on host, preventing independent verification; duplicate implementation of similar capabilities across businesses; test pages and debug code polluting production artifacts and increasing binary size.

The four-layer structure solves these:

Demo – development/debug root, aggregates verification entry points for multiple businesses, provides navigation, test login, environment switching, mocks, and debug Bridge. Enables cross-platform development without repeated host packaging. Not a production artifact.

Validation – host acceptance layer, carries test pages, test clients, parameter input, and raw result display. Enters real app with corresponding business to verify container, routing, login state, Bridge, and host environment. Does not enter production business package.

Shared – single business's formal delivery unit. Each business has a peer-level, independent Shared containing only production pages, state, data repositories, resources, and registration entry points.

Common – shared foundation for all businesses, holding stable cross-business capabilities. Not delivered alone; aggregated into final artifacts with current Shared or Validation.

Validation currently relies on manual on-device host acceptance; next step is automated acceptance. Model parsing, state transitions, and protocol contracts run via commonTest; host-dependent tests (container, routing, login, lifecycle, Bridge) run via host-validation package on three-end real devices, producing unified results, logs, and screenshots. This keeps production artifacts clean while gradually converting manual acceptance into repeatable test patterns.

Common & Packaging: Shared Capabilities Must Exist in Deliverables Common did not start as a monolithic toolbox; it emerged from concrete duplication: each business wrapping near-identical Bridges; same results parsed differently across pages; session expiry, signing, encryption, error logging handled separately; a single protocol change requiring modifications on Android, iOS, and HarmonyOS. Copy-paste seems faster short-term but raises long-term regression cost. Entry criteria for Common: a capability must be reused by at least two businesses or be a confirmed cross-business foundational capability; otherwise it stays in Shared. On the interface side, existing host APIs depend on Socket while the current NetworkModule doesn't support that protocol. To satisfy Demo's independent debugging, the backend was lightly refactored to serve microservice requests over HTTPS, and Common unified HTTP, signing, encryption, token handling, and parsing. Business layer only touches Client, config, and result data models. Bridge refactoring in Common is典型. All three hosts already have a Jockey parsing system for H5. Replacing it with a completely different communication format would look cleaner but force hosts to maintain another capability set. The solution: keep two outer entry points – existing Web/Jockey semantics go to webRequest , Kuikly-native capabilities go to nativeRequest , dispatched inside a unified request body. Pages never touch these low-level entry points; they depend only on business Bridge's Kotlin APIs. This reuses existing capabilities while preserving clear boundaries for new ones. Packaging & Delivery Android needs a consumable business AAR; iOS needs same-version XCFramework and resource Bundle; HarmonyOS needs .so, headers, and resources. Production deliverables aggregate Shared + Common; host-acceptance deliverables aggregate Validation + corresponding Shared + Common. During Android packaging, Shared artifacts couldn't merge Common's compiled files and dependencies cleanly, producing multiple AARs. A dedicated delivery project was built using the Fused Library aggregation tool to merge multiple AARs and their dependencies into a single AAR, ensuring each business outputs exactly one host-consumable artifact. AI Capability Precipitation: Making Engineering Rules Executable Across Businesses In a single-page project, AI generating runnable code may cover most work. In a multi-business Kuikly project, the hard part is deciding which business a piece of code belongs to, what capabilities can enter Common, and whether test code pollutes production artifacts. Therefore, AI precipitation focused not on "writing a page faster" but on "enabling new businesses to onboard the same engineering structure quickly with built-in debuggability, verifiability, and independent deliverability." AI capabilities split into two layers: Boundary Rules – answer "what can/cannot be done". Examples: pages must not directly concatenate Bridge calls; public HTTPS must not fall back to host proxy; test pages, mocks, test clients have dedicated module ownership; production and acceptance packages must follow separate packaging pipelines. Executable Skills – answer "what sequence to follow for a given task". To make rules discoverable, reusable, and continuously updated, AI assets are stored in four layers: Index → Rules → Skill → Change Evidence. The directory itself serves as the entry point. These precipitates form two tiers: bottom tier reuses KuiklyUI-AI official Skills to ensure correctness of components, state, networking, animation, and native extensions; top tier precipitates project-level Skills solving multi-business ownership, H5 migration, unified Bridge, direct Demo debugging, and three-end delivery. Below are typical Skills validated by real problems in the project. Performance Verification & Summary Three on-device reports cover Android, iOS, and HarmonyOS. Only relative changes from H5 to Kuikly on the same platform are compared; no absolute cross-platform ranking. Kuikly improved most core runtime metrics: HarmonyOS: average page-entry latency ↓20.7%, scroll CPU ↓86.2%, steady-state PSS ↓28.5%. Android: P95 entry latency ↓7.5%, scroll CPU ↓6.6%, P95 frame time ↓28.6%, steady-state full PSS ↓~36.1%. iOS: full page process-group memory ↓~59.4%, controlled-scroll hitches from 8 to 1. Note: All three reports used same platform, same device, same operation sequence for H5 vs. Kuikly comparison. Full PSS taken from attributable page process groups or whole-app stable-state data per report. Different profiling tools per platform prevent absolute cross-platform ranking. Overall, Kuikly's value has expanded from "page consistency" to measurable runtime efficiency. Gains differ per platform; weak areas (iOS first-screen, low-end devices, cold/hot start, isolated package size, long-run stability) need continuous improvement. The value of cross-platform is not making three ends look alike, but making them collaborate stably within the same boundaries. Looking back, the key achievement is not merely adding a cross-platform page but forming a multi-business engineering system that is directly debuggable and can enter three-end host acceptance. KuiklyDSL unifies business expression; Demo lets pages run and debug without waiting for host integration; Shared and Common ensure clean delivery boundaries. The hot-spot review's three-end measurements further show this system not only boosts development efficiency but also outperforms H5 on most key metrics (memory, CPU, frame time, interaction continuity). Next steps: complete automated acceptance, performance baselines, and long-term stability verification, turning validated capabilities into default engineering defaults for more financial businesses. Closing Remarks Changjiang Securities' practice shows that cross-platform construction's true value is not just sharing code across three ends, but aligning business boundaries, debugging methods, host contracts, acceptance mechanisms, and delivery shapes simultaneously. Only when these capabilities precipitate into a reusable engineering foundation can new businesses enter three ends at lower cost while balancing performance, experience, and long-term maintenance. From AI hot-spot review to subsequent conditional orders and OA businesses, Kuikly has evolved from a single-point experiment into a reusable multi-business system. Going forward, the team will continue refining automated acceptance, performance baselines, and long-run stability verification, enabling this engineering capability to be stably reused across more financial businesses.