Three‑Platform (RN/H5) Unified Development Architecture and Practices by Snowball Frontend Team

1. Background

Snowball's frontend team maintains the Snowball App and a critical WeChat private‑domain H5, requiring simultaneous development for iOS, Android, and H5, which leads to resource conflicts and inefficiencies.

The team sought a technology that maximizes efficiency, experience, cost, and universality, aiming to break traditional stack boundaries and achieve true three‑platform unification.

Industry leaders such as Facebook (React Native), Google (Flutter), Alibaba (Xianyu), ByteDance, and Kuaishou are also exploring cross‑platform solutions; React Native is considered a cost‑effective choice for small‑to‑medium companies.

However, RN development in Snowball faced challenges: steep learning curve, verbose code, separate adaptations for each platform, and duplicated effort when syncing RN features to WeChat H5.

To address these issues, Snowball's frontend team built a three‑platform RN/H5 unification solution that has been applied to multiple business scenarios such as private funds, public funds, community features, etc.

2. RN/H5 Unification Overview

2.1 Core Capabilities

1. Single Codebase for Three Platforms

Using RN, a single codebase runs on iOS, Android, and H5, providing dynamic capabilities and eliminating the need for separate implementations.

2. Styled‑Component System and Unified Component Library

The team created a minimal styled‑system with color tokens, screen adaptation, and day/night mode, dramatically reducing CSS code and providing a ready‑to‑use component library (snowbox) that smooths platform differences.

3. Improving RN Development Experience

Development can start in a browser using standard web tools (VSCode, Chrome, snowbox) without launching emulators, and later synchronize to native platforms.

2.2 Overall Solution

The solution consists of a unified component library (snowbox) and a styled‑system that enable rapid RN code authoring.

Client side: RN generates code for both native and web, providing dynamic capabilities.

H5 side: React Native Web compiles RN code to H5 with server‑side rendering, reproducing the native experience in WeChat.

3. Effects of Unification

The team showcases three aspects: business page performance, improved RN development workflow, and component library capabilities.

3.1 Business Page Effects

The private‑fund product page, with over twenty complex modules, was the first to adopt the unification approach, achieving native‑like speed, hot‑updates, and a >2× productivity boost.

Features such as day/night theme switching, complex curve interactions, and secondary pages work identically on App and H5.

H5 Performance

Performance comparison between RN‑SSR H5 and pure H5 shows comparable Lighthouse scores and JavaScript payloads, confirming production viability.

Project

Tech Stack

Lighthouse

First‑load JS

Total JS

Component Library Page

RN SSR

96

205k

205k

Private Fund Product Page

RN SSR

80

270k

270k

Private Position Page

React SSR

82

208k

208k

Private Home Page

React SSR

68

227k

227k

Advisor Product Page

Vue

65

340k

485k

3.2 RN Development Experience Improvement

Traditional RN development suffers from cumbersome style debugging and lack of tooling. After unification, developers can use browser‑based debugging, React DevTools, and Chrome network panels for rapid iteration.

Early Stage – Browser Development

Logic, UI skeleton, and API integration are done in a web environment using VSCode and Chrome, reducing the entry barrier.

Mid‑Late Stage – Synchronized Three‑Platform Development

Two terminals run yarn dev (RN) and yarn web-dev (H5) simultaneously; UI tweaks propagate to all platforms via hot‑update.

3.3 Unified Component Library

The snowbox library encapsulates design components, provides online sandbox demos, and can be used in pure CRA, Vite, or Next projects, achieving true cross‑platform component reuse.

https://snowbox.js.org/

4. Styled‑System Component System

4.1 Problems with Conventional RN/Web Styling

Traditional styling requires verbose class names, separate CSS/JS files, and duplicated tokens, leading to large bundles and maintenance overhead.

Snowball's custom styled‑system abstracts margin, padding, border, flex, positioning, colors, and theme tokens into concise props, reducing style code by up to 90%.

Box Component

Acts like a web div or RN View, supporting box model shortcuts (m, p, br, flex), positioning (l, r, t, b, ab, c), and color tokens (cl, bg).

Txt Component

Provides font size, weight, line‑height, letter‑spacing, and DIN font support via props such as f, fw, lh, ls.

Design Tokens

Semantic color tokens (e.g., T010 for primary text) enable automatic day/night theme switching.

Screen Adaptation

Based on a 375 px iPhone 8 baseline, all dimensions scale proportionally, eliminating manual calculations.

Bridging Platform Differences

Platform‑specific quirks (e.g., missing inline elements in RN, Android font weight issues) are encapsulated, allowing business code to remain agnostic.

5. H5 Unification Implementation

5.1 React Native Web Introduction

Developed by former Twitter engineer, React Native Web powers Twitter Web, Expo, NativeBase, and many other projects, offering atomic CSS, CSS‑in‑JS, and component containerization.

5.2 RN Project Unification Refactor

Web Architecture

Snowball integrates React Native Web with Next.js for SSR and a custom Koa server to reuse existing middleware.

Route Registration

Both RN and H5 share the same JSON‑driven URL routing, enabling fallback to H5 when RN fails.

Differential Handling

Three strategies are used: code‑level guards, Metro bundler suffixes (e.g., .native.js), and Next.js custom page extensions (e.g., .web.js).

// Only import weixin‑js‑sdk on web
if (OS === 'web') { wx = require('weixin-js-sdk'); }
// Enable mobx static rendering on node
if (OS === 'node') { useStaticRendering(true); }

module.exports = {
  pageExtensions: ['web.jsx','web.js','web.tsx','web.ts'],
};

5.3 Server‑Side Rendering

SSR reduces first‑paint time by pre‑computing RN‑generated CSS. Benchmarks on low‑end devices show Lighthouse scores improving from 67 to 80 for the private‑fund page.

Project

SSR

Non‑SSR

Private New Fund Page

80

67

xueqiu.com/rn

98

93

Component Library Demo

96

86

SSR Screen Adaptation

Rem + vw layout replaces JS‑based dimension calculations, allowing true SSR without screen‑size detection.

6. CI/CD Process for Unification

6.1 Continuous Integration

GitLab CI runs lint, unit tests, RN packaging, and deployment. RN packages are uploaded via an internal mPaaS platform.

6.2 Continuous Deployment

Web services are built with Drone CI and deployed via a rolling Docker system across sit, sep, staging, and prod environments.

6.3 Unit Testing

Snowball adopts Jest + React Native Testing Library for component testing, achieving >80% coverage.

jest --coverage

7. Outlook

7.1 AI‑Driven Code Generation (D2C)

Snowball plans to integrate AI models (e.g., Copilot, Pix2Code) with the unified component system to automatically generate RN/H5 code from design drafts, progressing through compiler‑based DSL generation, visual editors, and full‑stack intelligent recognition.

7.2 Extending Unification to More Platforms

Future work includes adapting the styled‑system to mini‑programs, and exploring Taro, Uni‑App, and other frameworks to achieve iOS, Android, H5, mini‑program, PC, and VR unification.

8. Conclusion

The three‑platform RN/H5 solution demonstrates how a tailored, cross‑platform architecture can dramatically improve development efficiency, user experience, and maintainability for companies that primarily develop native apps but also need to serve web audiences.

Continued investment in component libraries, AI‑assisted code generation, and broader platform support will further reduce duplication and accelerate product delivery.