Your team has experienced iOS and Android engineers; would you still start a new React Native app framework-first rather than bare, and why?

## The question behind the question Interviewers ask this to see whether you confuse **capability** with **cost**. A team with strong iOS and Android engineers *can* run a bare React Native project well. The question is whether spending their time maintaining a home-grown framework is the best use of it. The React Native team's framing helps: you are either using a framework or building your own. ## What a framework still leaves to native engineers - **Custom native modules** for SDKs the framework does not cover. - **Native configuration** applied through plugins rather than hand edits. - **Performance work** in native code where profiling shows a need. - **Reviewing** native dependencies and build settings. Choosing a framework does not waste native skill; it redirects it from boilerplate to product-specific work. ## What the framework takes off the team | Concern | Framework-first | Bare | |---|---|---| | Navigation and routing | provided (file-based routing) | chosen and wired by the team | | Native module set | curated SDK with aligned versions | assembled library by library | | Native project files | generated from configuration | hand-maintained forever | | React Native upgrades | SDK upgrade path | template diff merged by hand each release | | Newest core release | arrives with the next SDK | available on release day | ## Constraints that justify bare 1. **Brownfield.** React Native is embedded in existing native apps; the native apps own the project structure. 2. **Day-one core releases.** The product needs a React Native feature before the framework ships it. In September 2026, Expo SDK 57 runs 0.86 while 0.87 is current, and 0.87 is only in Expo's canary builds. 3. **Native setups a framework cannot express**, such as unusual build systems, custom app extensions or deep platform integrations that would need constant hand-edited escape hatches. 4. **An existing internal platform**: the organisation already maintains build, signing, release and update infrastructure and wants React Native to plug into it. 5. **Platforms outside the framework's support** that the app must target. If none of these applies, native expertise alone is not a reason to go bare. ## Risks on each side - **Framework risks:** dependence on the framework's release timing; some native changes need a plugin or a local module rather than a direct edit; learning its configuration model. - **Bare risks:** native folders drift from the template; upgrades become multi-day merges; each library's native setup is repeated by hand; knowledge concentrates in the one or two people who did the original setup. ## How to present the answer 1. State the default and its source: the React Native docs recommend a framework for new apps. 2. Show that native skill is used either way, so it is not the deciding factor. 3. Name the concrete constraints that would flip the decision. 4. Quantify the ongoing cost of bare: who merges template changes, how often, and how long it took last time. 5. End with a decision and a review trigger, not a list of pros and cons. ## A defensible recommendation For a new app with a strong native team: **start framework-first**, put native engineers on custom modules and platform quality, and write down the triggers that would justify moving to bare (for example, the framework blocking a required React Native release twice in a row). Revisit at each major upgrade. If a trigger fires, the move is a planned migration, not an emergency. For a **brownfield** product, the answer flips: the native apps already exist, so the integration path is the bare, embedded one, and the framework question becomes which of its libraries you can still use inside that setup.