The Problem

Developers starting a new React‑Native app often spend weeks assembling a reusable component library, wiring navigation, and configuring native build files. The missing piece is a ready‑made, opinionated starter that supplies a complete UI kit, Redux state scaffolding, and native project setup out of the box.

What This Does

The repository is a fully‑featured template that boots a mobile app with a modular architecture. Core UI elements live under src/components/ (e.g., Button.js, Card.js, Autocomplete.js). State containers and screens are in src/modules/ (e.g., ChatState.js, AuthView.js). Native build scripts and assets are provided in android/ and ios/. The entry point App.js imports src/components/index.js, which re‑exports the component library, and src/modules/AppView.js which composes the navigation stack.

How It Is Wired

Execution begins at App.js, which registers the root component with React‑Native. The navigation stack is defined in src/modules/navigation/stackNavigationData.js (high fan‑in: 37 imports, instability 0.97) and is consumed by src/modules/AppView.js. Once a screen mounts, its componentDidMount triggers data loading functions such as loadChartsData in src/modules/charts/ChartsState.js and loadMessagesList in src/modules/chat/ChatState.js.

The internal call graph shows the most widely used functions:

  • applyGeneralStyles – called from 3 UI components (Text, Title, Caption).
  • setModalVisible – invoked by toggleModal in two places.

Modules with the highest blast radius are style hubs (src/styles/index.js – 69 dependents) and chart collections (src/modules/charts/chartsCollection/charts/index.js – 34 dependents). No circular dependencies were detected, but deep nesting (max depth 8) appears in src/modules/components/CheckboxView.js and related auth views, which makes the control flow harder to follow.

How To Use It

# Clone the exact repository
git clone https://github.com/moses-y/react-native-starter
cd react-native-starter

# Install JS dependencies (yarn is declared in package.json)
yarn install

# Android – build and run
yarn run:android

# iOS – build and run
yarn run:ios

No additional environment files are referenced in the repo; the native projects rely on the default debug keystore located at android/app/debug.keystore (which must be replaced for production). Configuration for Redux, navigation, and theming is already present in the source tree.

Real‑World Use

A startup could fork this repo, replace the placeholder API calls in src/modules/chat/ChatState.js with their own backend endpoints, and drop new screens into src/modules/. Because the UI components are centrally styled, a brand‑wide theme change only requires editing src/styles/colors.js and src/styles/index.js.

Code Health & Issues

  • Critical – Private key committed: android/app/debug.keystore. Must rotate, purge from history, and replace with a secure keystore.
  • High – No build gate for src/modules/charts/ChartsState.js. Add a CI workflow that builds the app and validates generated assets.
  • Medium – Dependabot/Renovate missing. Add .github/dependabot.yml to keep dependencies patched.
  • Medium – No pre‑commit secret scan. Install a hook (e.g., git-secrets) to prevent future leaks.
  • Medium – Test coverage is extremely low (1 test file for ~200 source files). Prioritize tests for high‑fan‑in modules such as src/styles/index.js and src/components/Card.js.
  • High (clarity) – Hub modules (src/styles/index.js, src/styles/colors.js, src/components/Card.js) have large dependency footprints; keep them stable and limit logic to pure styling.
  • High (cognitive load) – Deeply nested files (src/modules/components/CheckboxView.js, src/modules/auth/AuthView.js) should be refactored to flatter structures.
  • High (duplicated code) – Repeated 6‑line blocks across 78 files (e.g., Autocomplete.js, Dropdown.js). Extract shared helpers.

The Bottom Line

The template delivers a complete React‑Native scaffold with a rich component set and native project files, making early development fast. However, the presence of a committed keystore, minimal testing, and several high‑impact maintainability issues mean it is best suited for teams that will invest in hardening the codebase before production use.