Workflow Selection
Workflow selection is the highest-leverage technical decision in a React Native project. It determines how much infrastructure your team owns, how fast you can onboard developers, and how difficult upgrades become later.
Default recommendation
For most new products, start with a framework-led workflow. It gives a better default for builds, updates, asset handling, and development tooling while still allowing native escape hatches when required.
Common workflow models
| Model | Best for | Main risk |
|---|---|---|
| Framework-led React Native | Most product teams and greenfield apps | Over-customizing too early and losing the workflow advantage |
| Bare React Native | Teams with significant native requirements from the start | Higher maintenance cost and slower onboarding |
| Hybrid shell | Companies embedding React Native into an existing native app | Complex integration boundaries and release coordination |
Framework-led workflow
Choose this when:
- The team wants fast setup and a standardized developer experience.
- Most product surfaces are conventional app screens.
- Build, submission, and update workflows should be predictable and documented.
This path is usually best for startups, internal tools, and product teams that want to move quickly without manually assembling every piece of mobile infrastructure.
Bare React Native workflow
Choose this when:
- You already know the app needs custom native views, SDKs, or significant platform-specific work.
- You want direct ownership of the native project from day one.
- The team already has strong iOS and Android engineering support.
Bare workflow is not wrong. It is just more expensive operationally. Treat it as an intentional choice rather than a default posture.
Hybrid integration
This is the right choice when React Native is one part of a larger native estate. Typical examples:
- Adding new feature surfaces to an established native app.
- Migrating a subset of screens to a shared React Native layer.
- Running React Native in a modular or microfrontend-style native architecture.
The challenge here is not React Native itself. It is alignment across release trains, navigation ownership, and shared design tokens.
Architectural defaults
Regardless of workflow, these defaults are usually sound:
- TypeScript-first application code.
- Feature-based folders over screen-by-screen sprawl.
- One navigation system with typed route params.
- Design tokens and UI primitives centralized early.
- Server state treated separately from local UI state.
- Native modules documented as explicit platform boundaries.
New Architecture stance
Treat the new architecture as the strategic direction of the ecosystem. Even if you are not actively customizing native modules, choose dependencies and patterns that do not assume older bridge-era behavior forever.
Workflow anti-patterns
- Starting bare because it "feels more professional" without a real requirement.
- Choosing a framework and then bypassing its conventions immediately.
- Mixing multiple state libraries and navigation patterns before the app has clear scale.
- Allowing third-party SDKs to dictate architecture instead of wrapping them behind app-owned interfaces.
Practical decision rule
If you are uncertain, choose the workflow that minimizes infrastructure ownership while still meeting product requirements. Move deeper only when real constraints justify it.
Continue with Environment Setup once the workflow is chosen.