Inside your app repo
What each file in your standalone app repo is for.
Your app repo is a standalone React Native project wired to the Appbrew platform. Knowing what each piece does, and what is safe to change, keeps upgrades and releases painless.
The layout
Yours to change
src/app/— your code:App.tsxcomposition,register-blocks.ts, and your custom blocks (Custom blocks).packages/— local packages you build, consumed asworkspace:*..env— which store/app config the dev build points at (Run your app).
Platform-managed files
package.jsondependency pins — every@gauntlet/*entry is pinned to one exact platform version. Bump them only as a full set (Upgrading)..npmrc— the registry wiring and the committed read token (Registry access), plusnode-linker=hoisted.
Do not change node-linker
React Native's native build steps expect a hoisted node_modules layout.
Removing node-linker=hoisted (or installing with a different package
manager) produces Android builds that fail at runtime with missing native
libraries — an error that looks nothing like its cause.
patches/— dependency patches applied on install. Removing one breaks the build in non-obvious ways.ios/andandroid/— the native projects. You'll rarely edit these; integrations that need native changes usually arrive through a platform upgrade or an Appbrew-run change.mise.toml— pinned toolchain versions; edit only when Appbrew tells you the platform moved.- Bundler config (
metro.config.js/rspack.config.mjs) andtsconfig— preconfigured so@gauntletsource packages compile; treat as platform files.
One version at a time
The repo always represents one consistent platform version: pinned @gauntlet set, matching toolchain, matching native projects. The release pipeline builds exactly what your default branch describes, which only works if the repo stays internally consistent.