agentsclimarketplace
Sign in

React native architecture

Skill Amey-Thakur/AI-SKILLS/skills/mobile/react-native-architecture

Structure React Native apps around clear native-module boundaries and decide honestly when RN fits. Use when starting or auditing a React Native codebase, or weighing RN against fully native development.From its SKILL.md

Install
npx -y skills add Amey-Thakur/AI-SKILLS --skill react-native-architecture

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

  • 23 days oldThe repository was created 23 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
  • 4 stars4 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

2.7 KB, 547 tokens by cl100k_base, as published. Nobody here has run it

React Native architecture

React Native earns its keep when one product team ships two platforms with mostly shared UI logic. The architecture question is always the same: what lives in JavaScript, what lives native, and how thin is the bridge between them.

Method

  1. Decide fit before structure. RN fits content- and form-driven apps with shared business logic. It fights you on heavy real-time graphics, background-centric apps (tracking, audio), and deep OS integration on day one. If the roadmap is 30%+ platform-specific capability, budget for native engineers regardless.
  2. Keep the JS/native boundary explicit and small. Wrap every native capability in one typed TypeScript module (src/native/), with its TurboModule or Nitro module behind it. UI code imports the wrapper, never the module directly; when implementations change, one file changes.
  3. Choose libraries by maintenance reality. Navigation: react navigation (JS-driven) unless you need native stack behavior everywhere. Lists: FlashList over FlatList for anything long. Animations: reanimated, which runs on the UI thread. Every native dependency you add is a build-breakage subscription; prefer JS-only where performance allows.
  4. Isolate platform divergence. Component.ios.tsx / Component.android.tsx for small forks; a platform/ capability layer when behavior differs structurally (permissions, files, notifications). Scattered Platform.OS === "ios" conditionals are the smell to refactor.
  5. Respect the threading model. JS runs on one thread: no JSON parsing of megabyte payloads or sync storage reads during interaction. Push heavy work behind InteractionManager, into reanimated worklets, or into a native module that does the work off-thread.
  6. Wire the escape hatches early. Crash reporting that symbolicates both JS and native stacks, and an over-the-air update service for JS-only fixes, with the store-policy limits understood. Retrofitting either after the first incident is twice the work.

Boundaries

  • RN does not remove the need to understand iOS and Android; it changes how often you touch them.
  • Brownfield embedding (RN screens inside an existing native app) is a different architecture with its own lifecycle bridging; do not apply this layout blindly there.
  • Expo's managed workflow accelerates the first year; audit its native module coverage against your roadmap before committing.

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.

Gives 0 of the 12 instructions most architecture codebase skills give in 547 tokens

Counted across 811 of the 1,134 authors here whose files we hold, read 2026-08-07

  • Ask the user which candidate to explorein 45 of 811, across 15 files
  • Apply the deletion test to suspected shallow modulesin 43 of 811, across 15 files
  • Read any relevant architecture decision records firstin 31 of 811, across 8 files
  • Use exact glossary terms in every suggestionin 30 of 811, across 10 files
  • Accept dependencies instead of creating themin 24 of 811, across 5 files
  • Include before and after visualisations for each candidatein 24 of 811, across 5 files
  • Read the domain glossary before exploringin 24 of 811, across 6 files
  • Return results instead of producing side effectsin 23 of 811, across 4 files
  • Explore the codebase for shallow modules and frictionin 23 of 811, across 3 files
  • Introduce seams only where things varyin 22 of 811, across 3 files
  • Reduce the number of methodsin 21 of 811, across 2 files
  • Design deep modules with small interfacesin 21 of 811, across 3 files

Said here and by no other author read

  • decide fit before structure
  • keep the native boundary small
  • wrap every native capability
  • choose libraries by maintenance reality
  • isolate platform divergence
  • respect the threading model

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.

Keep looking

Skills are one crate of 326,790. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.