ReactNativeOne: a React Native clone of the ONE reading app, and its API problem

What the application is, and the four sections it covers

This is a high-fidelity reimplementation of the Chinese reading app ONE, built on React Native, running on both Android and iOS. The README links the original app, which it describes as a literary and lifestyle application supervised by Han Han and created by former members of the Du Chang Tuan team.

The stated goal is 80 percent code reuse between the two platforms, and the supported devices are Android 4.1 and later and iOS 8.0 and later.

The functional scope is the original app's four sections, and the README lists what is implemented in each. The picture-text section shows a list with a ViewPager and a ListView, browses past issues of that content, and opens images full screen. The reading section handles the three article series types, short pieces, serials and question and answer, with audio playback of an article and a list of past articles. The music section shows stories, plays music and lists history. The movie section lists recent releases, opens a detail page, plays trailers and shows stills.

Then the cross-cutting features: comment lists for articles, music and movies, a custom extended ListView that loads more data on pull, WeChat friend and WeChat Moments sharing, and caching of the API responses to save traffic.

The application is licensed GPL-3.0, the primary language in the repository metadata is JavaScript, the default branch is master, and the last push was on 2026-05-31 with no GitHub releases. The repository is a fork of the original project by lipeiwei-szu, and the README points to that project for the interface documentation.

The disclaimer, which is the first thing a reader should see

The README has a statement section, and it is the most consequential paragraph in the document, so it is worth rendering plainly rather than paraphrasing.

The APIs the application uses are all provided by the original service, and the author states that they were obtained by unusual means, that the act of obtaining and sharing them may infringe the rights of the original service, and asks readers to understand the situation and make sure they do not infringe the original service's interests and that they respect the open source licence.

The approach section says the same thing in a different place. The interface documentation was assembled by capturing the original app's network traffic with Charles on a Mac and organising it into a document, which is now a separate repository.

So the data source is reverse engineered, the repository is public, and the author has said so in the README. That is a materially different situation from a project that calls a documented public API, and it is not something a downstream adopter can fix by reading the licence.

None of this is a reason not to look at the code, and the engineering in it is genuinely instructive. But it is a reason not to ship it, and it is a reason to read the disclaimer before the screenshots.

The engineering decisions, from navigation to deferred work

The section on the overall approach lists ten decisions, and they are the interesting part of the repository.

The routing uses the official Navigator, with the scene transition animation freely configurable and the Android back button event handled. The layout uses FlexBox and JSX syntax, with a set of common components wrapped up for global reuse, among them a GridView, a ListView with pull-to-refresh and an ImageViewer.

Audio playback is implemented on the native Android side and the native API is exported to React Native, and the video module is imported as a native API with a custom interface for the movie trailer loading and playback. The WeChat sharing comes from the third-party library react-native-wechat. The various network states are handled explicitly, including loading, success, failure and a tap-to-retry.

Two of the ten are performance decisions rather than features. InteractionManager is used to guarantee that each page only performs its expensive work when the transition animation has finished, so switching pages does not stutter, and the view hierarchy is kept shallow to reduce rendering cost. And there is a deliberate design of the global state, with redux brought in for the audio-related state and the components that depend on it managed through redux, react-redux, redux-thunk and redux-logger.

That is the profile of an app written by someone who cared about the frame budget, which is the part worth taking from the repository.

The dependency set, and what it dates the code to

The `package.json` is the clearest way to date this project, and it dates it precisely.

React is pinned to `~15.4.0-rc.4` and React Native to `0.38.0`, which is a 2016 release. The state management is redux at `~3.6.0`, react-redux at `~4.4.5`, redux-thunk at `~2.1.0` and redux-logger at `~2.7.0`. The native pieces are react-native-video at `0.9.0`, react-native-wechat at `1.7.0`, react-native-orientation at `1.17.0`, react-native-scrollable-tab-view at `0.6.0` and react-native-simple-store at `~1.1.0`, plus a toast component at `1.0.5`.

The `react-native-viewpager` entry is the one to note. It is not a registry dependency but a git URL pointing at a fork maintained by the original author, which is itself a fork of the viewpager by race604. That fork exists because the README's own bug list mentions the home page using many ViewPagers without reuse or lazy loading, which is expensive on performance, so the fork exists to fix that.

A fork of a third-party library, pulled from git rather than from a registry, is a maintenance liability that any adopter inherits along with the code. There is no version constraint on it in the manifest, which means an install resolves to whatever the tip of that branch is at the time.

The package is private, at version 0.0.1, and the only script is a start command that invokes the React Native local CLI, so there is no build, test or lint script defined at the root at all.

The unfinished list, which is more useful than the screenshots

The README keeps a section on the bugs found and the features not yet done, and it is more informative than the feature list, because a project that lists its own gaps is telling you where it will not work.

On Android, the debug build has a problem with a ViewPager nested inside a ListView in the music section that does not occur in the release build, the Image component takes no space at all when its uri is empty, and the author has not been able to implement the iOS ScrollView contentOffset behaviour on Android.

On iOS, the entries for the video library and the WeChat sharing not importing successfully are struck through and marked done, so those were resolved. Audio playback still uses the native interface, which the author has finished for Android but not for iOS, so audio cannot be played there. And in the reading section, some serial articles fail to display on iOS, with two possible causes offered, special characters in the text or a long text exceeding the label, with a note that a real device behaves correctly, so it is probably a simulator issue.

The shared problems are more interesting. The audio buffering state was added and struck through as done, and so were the top music control modal and the draggable progress bar in the audio and video players. The remaining items are that the ActivityIndicator is always problematic on Android, particularly nested inside a Modal, and sometimes does not spin at all while iOS is fine, and that the home page uses many ViewPagers without reuse or lazy loading, which is expensive on performance.

The planned features are search, audio and video caching, JavaScript hot reload and favourites.

Building it, and the platform split

The build section is three steps:

npm install
react-native run-android

Or the iOS equivalent, since the README says to run `react-native run-android` or `react-native run-ios`.

The distribution situation is asymmetric and worth knowing before you try it. There is an Android application download linked through a third-party hosting service, a screenshot of the download page in the `screenshots/` directory. For iOS, the README says that without an Apple developer account there is no way to package the application for now, and asks the reader to compile it themselves and run it in a simulator or on a phone.

The repository layout is the standard React Native one, with `android/`, `ios/`, an `app/` directory holding the JavaScript, and separate `index.android.js` and `index.ios.js` entry points, which is what makes the 80 percent code reuse claim concrete, since the platform-specific entry is the only part that differs at the top level.

There is also a set of configuration files that reveal the era, with a `.buckconfig` for Buck, a `.flowconfig` for Flow type checking and a `.watchmanconfig`. The Flow configuration is a sign that the codebase was written with Flow types rather than TypeScript.

The `screenshots/` directory holds the images the README displays, and the source of the interface documentation is a separate repository, so the API reference travels with the project rather than inside it.

Where ReactNativeOne is the wrong thing to build on

The first wrong case is a production application, and the reason is the data source rather than the code. The application calls an interface obtained by capturing the original service's traffic, which is a different thing from calling a documented API. A fork inherits a legal exposure that no amount of code quality addresses, and the original service can change or withdraw the interface at any time, which makes the application fragile in a way that is independent of the code.

The second is anything on a current React Native. The dependency set is React 15.4 release candidate and React Native 0.38, which is a decade of framework change away, and the `react-native-viewpager` entry has no version constraint and resolves to a git tip. Bringing this to a current React Native is a rewrite, and the parts worth keeping are the ideas rather than the code.

The third is a team that wants the iOS behaviour. The README is honest that audio playback was never finished on iOS, that some serial articles do not display there, and that the application cannot be packaged for the App Store without a developer account. Half of the platform support is a work in progress.

The fourth is a project that needs a maintained library. There are no releases, the version is 0.0.1, the only script is a start command, and the fork of the viewpager is unpinned. The quality of the engineering in the source is real, but it is a sample project, and it should be read as one.

The fifth is an organisation with a policy on scraping and on reverse engineering other services' interfaces. The README asks readers to make sure they do not infringe the original service's interests, and a corporate user has to answer that question themselves before shipping anything derived from this code.

Editorial conclusion

ReactNativeOne suits a developer studying how a React Native client is put together, since the repository is a complete worked example with its navigation, layout, native module and state management decisions written down, including the parts that did not work. It does not suit a product team, and the reason is not technical. The README states that the APIs the application calls were obtained by capturing traffic from the original app, and that the act of sharing them may infringe the original service's rights, so a fork of this project inherits a legal question about its own data source before it inherits anything else. Before using any of this, read the disclaimer section in the README, and if you want the techniques rather than the application, take the ViewPager fork, the native module export and the InteractionManager pattern, none of which depend on whose API the screens are talking to.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. README
4. vivianli-me/ReactNativeOne on GitHub