Frontend · Android · iOS

19 Weex Rendering Bugs That Will Haunt Your Cross-Platform Build

By 勤劳勇敢的打工人 · Oct 30, 2026

Read original on juejin.cn ↗ Google Translate ↗ Alt translation

Weex promises write-once-run-anywhere, but this list shows that promise has cracks: teams must build and test platform-specific workarounds for each feature, which multiplies maintenance cost and can slip into production as flickering UI, broken navigation, or invisible ellipsis marks.

Summary

Weex development runs into a wall of platform-specific rendering idiosyncrasies. The list covers CSS shorthand failures, layout bugs, timer quirks, and refresh component issues. Android forces explicit width/height on every div; iOS breaks overflow with box-shadow; HarmonyOS ignores ellipsis with nowrap. Workarounds range from wrapping elements in extra divs to slicing images for arrows.

The patterns are concrete: background shorthand is unusable, `border-radius` with four different values fails on iOS, and the `refresh` component cannot be dynamically shown or hidden. Several issues stem from how Weex maps CSS to native rendering on each platform, leaving developers to guess which properties behave where. The list also includes platform-specific traps like the Baidu app session reset and HarmonyOS image loading stalling after a translate plus transition-delay.

All 19 items are practical field notes, not theoretical warnings. Each one names a symptom and a fix, giving teams a checklist to consult before shipping Weex features. The recurring theme is that "write once, run anywhere" breaks down in the details — the only reliable path is to test every style and component on every target platform.

Takeaways

— Background shorthand is unsupported; use `background-color` and `background-image` separately.

— Android requires explicit width and height on every `div`; content-sized elements break positioning.

— Placing `text` at the same level as `flex:1` can lose styles; wrap it in a `div`.

— Baidu app H5 sessions reset during browsing, forcing users back to the login page.

— Upward loop scrolling sometimes freezes the first element.

— On Android, a stopped timer fails to restart; calling an empty timer after restart works.

— The `refresh` component cannot be dynamically toggled; change its layout instead.

— On iOS, clearing `background-image` via style requires setting `background-color` to `transparent`.

— iOS pull-to-refresh background only covers the height area; use an underlying layer.

— Android flashes when CSS and inline `style` both set the same property; remove the CSS rule.

— On iOS, `box-shadow` disables `overflow`.

— HarmonyOS and H5 fail to load image resources after `translate` plus `transition-delay` until user interaction.

— iOS components disappear after pull-back when the data difference is too large, caused by `key`.

— Android `transition` only supports a few style changes; wrap unsupported properties in a separate element.

— iOS `border-radius` with four different values is ignored; use image slicing or stacking.

— Weex web lacks the `richtext` component and tags.

— The four-border shorthand syntax fails on Android and iOS; slice images for arrows.

— HarmonyOS does not show ellipsis with `white-space: nowrap;` for single-line overflow.

Conclusions

The list is a direct symptom of Weex's rendering engine diverging from standard CSS across platforms, forcing developers to maintain a platform-aware mental model instead of a single component API.

Most items are silent at compile time and only appear at runtime, so without a shared pitfall register every new team member re-discovers the same bugs.

Concepts & terms

Weex

A cross-platform UI framework that compiles JavaScript and CSS into native components on Android, iOS, and web, aiming for write-once-run-anywhere development.

From the discussion

The technical corrections to the bug list are the core of the discussion. Font-weight is a text-only style, and Android's mapping to 400/700 makes a 500 weight impossible without a font-family workaround. Box-shadow is an iOS-only property, so the listed overflow failure simply doesn't occur on Android. White-space is unsupported, and single-line ellipsis requires lines and text-overflow, tied to the parent-specified width. On the lifecycle side, sentiment is grim: one developer reports a prior employer used Weex and that two years spent on it were wasted.

— Font-weight is a text-only style in Weex, so applying it to a div does nothing, and Android only supports 400 and 700; a 500 Medium requires loading a separate font-family rather than adjusting the numeric value.

— Box-shadow is iOS-only in Weex, so the article's claim that it breaks overflow on Android is wrong; the two platforms simply have different support, and Android has no alternative but a cutout image.

— White-space is not in the supported style list at all; single-line ellipsis is achieved with lines:1 and text-overflow:ellipsis, and the width has to come from the parent container, which is the same root cause as the explicit width requirement in item 3.

— Weex is seen as abandoned tech: one developer expresses that a previous employer used it, they likely won't again, and the two years spent on it were a waste.

Featured comments

booboosui

The first item isn't "maybe" ineffective — it's definitely ineffective: font-weight in Weex belongs to text styles, only applying to text / input / richtext; div has no font concept. And the documentation says iOS supports 9 levels from 100 to 900, while Android recognizes only 400 and 700 — any other number is forced down to 400 or 700. So a design-specified 500 Medium will definitely be thinner on Android; tweaking the number won't help, the only approach is loading the Medium weight via font-family.

勤劳勇敢的打工人

Whoa, there's a pro here. Your company is still using this? [watching]

See top comments, translated →

Source: juejin.cn ↗ Google Translate ↗ Backup ↗