skip to content

In a React Native project created without a framework, what does it mean that you own the ios/ and android/ folders?

level: middleimportance: should knowfreq 40%

answer

  1. generated once, then yours
  2. committed and edited by hand
  3. manifests, Podfile, Gradle, AppDelegate
  4. upgrades mean merging template diffs
  5. full control, full maintenance

basics

~20 s

The native iOS and Android projects are generated once at init and then become source code you commit, edit and maintain yourself, including applying the template's native changes by hand at every React Native upgrade.

solid answer

~40 s

`npx @react-native-community/cli init` copies the template's `ios/` and `android/` projects into your repository once. From then on they are ordinary native projects that you commit and change directly: `Info.plist` and `AndroidManifest.xml` for permissions and URL schemes, the `Podfile`, the Gradle files, `AppDelegate.swift` and `MainApplication.kt`. Nothing regenerates them, so every native setting a library needs is a manual edit that must be reviewed like code. The biggest cost shows at upgrades: the template's native files change between React Native versions, and you must merge those changes into files you have also modified. In exchange you get full control: any native SDK, build setting or custom native code, with no generator standing between you and Xcode or Gradle. Framework workflows can instead generate these folders from configuration.

go deeper

for a junior

Recall that a bare app's ios/ and android/ folders are created once and then edited and committed by you.

for a middle

Explain which native files you touch for common tasks, and why template changes must be merged by hand at each upgrade.

for a senior

Keep native customisations isolated and documented, and plan upgrades one minor at a time so template diffs stay mergeable.

for a principal

Weigh the control of owned native projects against the recurring upgrade cost, and set rules for when a native change is allowed.

## What init actually gives you When you create a project with `npx @react-native-community/cli@latest init`, the CLI copies the **Community Template** into a new folder. Alongside the JavaScript (`App.tsx`, `index.js`, `package.json`), it creates two complete native projects: - **`ios/`**: an Xcode project and workspace, a `Podfile` for CocoaPods, `Info.plist`, and the app delegate (Swift, `AppDelegate.swift`, since 0.77). - **`android/`**: a Gradle project with `settings.gradle` (which applies the React Native settings plugin and autolinking), `app/build.gradle`, `AndroidManifest.xml`, `MainApplication.kt` and the main activity. These files are generated **once**. After that they are not templates any more; they are your source code. ## What owning them means day to day | Task | In an owned native project | |---|---| | Add a permission or usage string | edit `Info.plist` or `AndroidManifest.xml` by hand | | Add a URL scheme or app link | edit the plist, the manifest and possibly the app delegate | | Install a library that needs native setup | follow its README and change native files yourself | | Change the bundle ID or app name | edit Xcode settings and Gradle config | | Add native code | add Swift, Objective-C++ or Kotlin files directly | Every one of those edits is committed, reviewed and remembered. Nothing rebuilds the folders from a config file, so a change someone made months ago is still there, whether or not anyone remembers why. ## The upgrade cost The Community Template changes between React Native versions: new Gradle plugin settings, a new app-delegate shape, raised minimum SDKs. When you upgrade, you must apply those native changes to your copies of the files, which you have also modified. In practice that means reading the version-to-version diff of the template and merging it by hand, resolving conflicts with your own edits. The more your native folders drift from the template, the harder each upgrade becomes. Keeping native customisations small, documented and isolated is the main defence. ## What you gain - **Full control.** Any native SDK, build phase, signing setup or Gradle configuration is available directly. - **No generator in the way.** You are never limited by what a configuration format can express. - **Familiar ground for native engineers.** An iOS or Android specialist works in Xcode or Android Studio exactly as usual. ## How this contrasts with a framework Framework workflows such as Expo can treat `ios/` and `android/` as **generated output**: native settings are declared in app configuration and applied by plugins, and the folders can be regenerated rather than hand-maintained. That shifts upgrade work from merging native files to updating the framework's SDK and configuration. A bare project keeps the older model: the native folders are the source of truth. ## Signs the native folders have drifted - Nobody can explain a build setting or a manifest entry. - The last upgrade took days of native merge conflicts. - Library installation instructions are followed differently on each platform. - Native changes land without review because "it's just config". Each sign points to the same fix: fewer, documented, isolated native changes. ## Habits that keep owned folders healthy 1. Commit the native folders and review native diffs as carefully as JavaScript. 2. Keep a short document of every intentional native change and why it exists. 3. Upgrade one React Native minor at a time, so each template diff stays small. 4. Prefer libraries that need no manual native steps beyond autolinking. 5. Keep custom native code in its own files or local modules rather than editing template files heavily.

  • Why do heavily customised native folders make upgrades slow?
    Each React Native release can change the template's native files, and those changes must be merged into your edited copies. Every local customisation is a potential conflict, so the upgrade becomes a native merge exercise rather than a version bump. Small, isolated, documented native changes keep that merge manageable.
  • Should the ios/ and android/ folders be committed in a bare project?
    Yes. In a project without a framework they are the only source of the native configuration; nothing can regenerate your customisations. They are reviewed and versioned like any other code.

Owning the native folders is like buying a house instead of renting a serviced flat: you can knock down any wall you like, but every repair, and every change the building code later demands, is yours to carry out.

saying these in an interview costs you the question

  • The CLI regenerates ios/ and android/ automatically on every build
  • Native folders in a bare app can be deleted and recreated without loss
  • React Native upgrades never touch the native template files
  • Owning the native folders means you cannot use autolinking
  • Native edits in a bare app belong in .gitignore