How a Lightweight “General List” Framework Enables Remote UI Updates in Mobile Apps

Introduction

App dynamicization has long been a hot topic in mobile development. Various technical options have emerged, from early low‑cost Hybrid development to later, more mature Web‑standard‑based frameworks like React Native, all aiming to better serve fast‑changing business needs.

This article presents the lightweight “General List” dynamic framework and shows how it meets certain business scenarios.

Background

Apps provide smooth operation and offline capability, making them the preferred way to showcase products on smartphones. However, uncontrollable version updates limit rapid feature iteration:

App store submission processes are cumbersome, and iOS apps must survive strict review.

Multiple historical versions exist, requiring server‑side compatibility handling and client data migration on upgrade.

Some users simply refuse to update.

Consequently, product managers demand greater app dynamism, pressuring developers to add stronger remote configurability.

Goals

To let new features reach every user faster, the dynamic solution must satisfy two requirements:

Control the display of specific pages remotely without releasing a new version.

Control the behavior of each clickable region remotely without releasing a new version.

Technical Options

We considered several approaches:

1. Multi‑platform frameworks such as React Native and Weex

These provide near‑native performance and a unified development experience, allowing JS bundles to be delivered over the network to update UI and logic quickly.

In 2015, React Native was still in its infancy (around v0.7) and Weex was not released until 2016, so the ecosystem risk was too high.

2. Hot‑fix solutions for each platform

For example, iOS’s JSPatch bridges Objective‑C runtime with remotely delivered JS to achieve hot updates. However, early hot‑fix frameworks were unstable for large business codebases and mixed fixing with feature development could complicate the workflow.

3. Hybrid approach

Embedding HTML5 inside a native app allows content updates without a new native release, offering a consistent cross‑platform experience but with slightly weaker performance and extra effort for native‑like UI components.

4. Native implementation

Since the above solutions exceed the original goals by updating all client code, we designed a lightweight native dynamic framework—General List. It uses a predefined set of templates on both client and server to deliver structured UI definitions, combined with a router protocol to support navigation to any screen, achieving flexible display and navigation.

Client Architecture

The rendering flow of General List is straightforward, as illustrated above:

When a user enters a screen, the app requests JSON data from the server, typically an array of dictionaries.

Each dictionary’s

style

field determines which local model instance to instantiate, validating data and simplifying later access.

All client versions ship with a set of predefined style templates; each model references a template, and filling the models into their templates yields the final view.

What exactly does “template” refer to?

It is a business‑agnostic view component, such as a custom

UIView

subclass in iOS.

These components have distinct appearances, while their core content can be freely assembled from external data.

For example, the left image defines a “top image / bottom text” template (Template A), and the right image defines a “top video / bottom left avatar / bottom right text” template (Template B), both serving purely as presentation layers.

<code>{
    "style": "top_image_bottom_text",
    "image": "http://xxx.png",
    "text": "Lorem ipsum"
}

{
    "style": "top_video_bottom_image_and_text",
    "video": "http://xyxy.mp4",
    "image": "http://xxx.png",
    "text0": "Lorem ipsum",
    "text1": "Dolorum voluptate"
}</code>

How is the final layout of each template determined?

The on‑screen UI is backed by a view tree; each view defines its internal layout while its position and size are dictated by its parent container. To control dynamic presentation, we send a hierarchical template metadata structure.

Assume we want Template A and B displayed side‑by‑side, with the left block occupying 1/3 of the row width and the right block 2/3, and the container height equal to one‑third of the screen width.

We first add an abstract container template that can lay out children horizontally based on width ratios.

When the client receives data like the following:

<code>{
    "style": "horizontal_flow_container",
    "children_grows": [1, 2],
    "aspect_ratio": 3,
    "children": [
        {
            "style": "top_image_bottom_text",
            "image": "http://xxx.png",
            "text": "Lorem ipsum"
        },
        {
            "style": "top_video_bottom_image_and_text",
            "video": "http://xyxy.mp4",
            "image": "http://xxx.png",
            "text0": "Lorem ipsum",
            "text1": "Dolorum voluptate"
        }
    ]
}</code>

it is transformed into a simple model tree:

Starting from the root, each node’s position and size are derived (the parent determines the child’s dimensions):

The

horizontal_flow_container

is the root; its default width

w0

equals the screen width. Using its

aspect_ratio

, the height

h0

becomes

w0 / aspect_ratio

.

The first child

top_image_bottom_text

receives a width of

1/(1+2) * w0 = w0/3

and inherits the parent height

h0

.

The second child

top_video_bottom_image_and_text

receives a width of

2/3 * w0

and the same height

h0

.

Handling Click Events

By appropriately arranging data, we can compose most page displays based on the template library.

When a user clicks a region, how does the app respond?

We want the response logic to be independent of the presentation.

For example, in Template B, some blocks may navigate to a video detail page, while others might be disguised third‑party ads that open a WebView.

Can we remotely control click handling for each block?

General List relies on a router module that uses custom URL schemes (e.g.,

bxapp://xxx

) to map URLs to components. Each app defines its own routing protocol, registers URLs with corresponding targets and actions, and then resolves them at runtime.

To separate display from navigation, we split the metadata:

<code>{
    "display": {
        "style": "top_image_bottom_text",
        "image": "http://xxx.png",
        "text": "Lorem ipsum"
    },
    "action": "bxapp://web_view/show/?url=https%3A%2F%2Fwww.google.com"
}</code>

Limitations & Future Optimizations

General List is used in various dynamic scenarios within the Baixing client, such as regular lists and frequently changing operation pages. Its main limitation is that the server can only deliver templates that were predefined in the client version, requiring a sufficiently diverse template library.

Future work could integrate React Native to truly download and render custom templates on the client, and provide a backend configuration portal for designers and developers to manage template definitions, versions, and rendering results, reducing maintenance overhead and improving system stability.

Conclusion

Although many large companies favor Hybrid or React Native for dynamic features, a lightweight approach like General List can adequately satisfy the needs of relatively simple business scenarios, and we hope it inspires others.