Cross‑Platform Development with Taro 2.x: Challenges and Solutions for React Native, Mini‑Programs, and H5

Background: The property‑listing business needed to expand from a single H5 embed in the Anjuke and 58 apps to multiple channels including mini‑programs and mobile sites (M‑sites), while improving user experience, reducing cost, and avoiding duplicated effort.

Goals were to improve UX, extend publishing channels to mini‑programs and M‑sites, and save development resources.

After evaluating mainstream mini‑program frameworks, only Taro and uni‑app supported React Native, mini‑programs, and H5. The team chose Taro because the Anjuke mini‑program already used it and the company provided an MPS CLI for cross‑platform development.

Taro’s official documentation states that a single codebase can be compiled to run on WeChat, JD, Baidu, Alipay, ByteDance mini‑programs, quick‑apps, H5, and React‑Native. However, practical experience revealed many gaps, especially for RN.

Key problems encountered:

Official RN 0.59.9 version was incompatible with the Anjuke and 58 apps.

Some Taro APIs depended on native modules not present in those apps.

RN’s CSS support was limited, causing style issues.

JSX syntax restrictions caused mini‑program compilation errors.

RN platform lacked certain capabilities.

TaroUI did not support RN.

Solutions:

Modified the Taro CLI to use an RN version compatible with the apps.

Removed unsupported native dependencies (e.g., expo) from @tarojs/cli, @tarojs/helper, @tarojs/taro‑rn, and @tarojs/rn‑runner.

These changes were packaged and published via patch-package and a post‑install script in package.json :

{
  "scripts": {
    "postinstall": "patch-package"
  }
}

Custom RN request module (rn‑request.ts) was added to bridge native HTTP calls:

import { NativeModules } from 'react-native';

declare type RequestData = {
  method: string;
  url: string;
  params: any;
};

export function fetch(requestData: RequestData): Promise
| null {
  return new Promise((resolve, reject) => {
    NativeModules.HTTPModule.Request(
      requestData,
      (response: any) => { resolve(response); },
      (error: string) => { reject(error); }
    );
  });
}

In the generic fetch.ts wrapper, the code now selects the RN implementation when process.env.TARO_ENV === 'rn' :

export default async function fetch(options: RequestParams) {
  const { url, data = {}, method = 'GET', header = {}, credentials = 'include' } = options;
  let result;
  if (process.env.TARO_ENV === 'rn') {
    result = await require('./rn-request').fetch({ url, method, params: data || {} });
  } else {
    result = await Taro.request({ url, method, data, header, credentials });
  }
  // ...
}

Style handling was unified by using Flex layout, BEM naming, and overriding component styles via the style prop. Conditional compilation ( if (process.env.TARO_ENV === 'weapp') { … } ) was employed to isolate platform‑specific logic.

Deployment: RN bundles were generated with yarn dev:rn , compiled to rn_temp , and served via Metro. The bundle was pushed to a dedicated rn_deploy branch for hot‑update packaging on iOS and Android. Mini‑programs were released as sub‑packages through the MPS CLI, and H5 was deployed via the cloud platform.

Result: The team delivered a new mortgage calculator, owner channel, direct‑sale form, and management detail pages, achieving the three original goals while noting that cross‑platform development required roughly double the effort of a pure H5 implementation.

Conclusion and outlook: Although many challenges remain—such as limited shared component libraries and SDK maturity—the experience demonstrates that with proper CLI patches, conditional compilation, and style strategies, Taro can serve as a viable foundation for unified front‑end development across RN, mini‑programs, and H5.