@avasapp/react-native-dhoni

Dev-only OTA bundle loading and a dev menu for React Native apps served by a dhoni distribution server.

Lets you push JS to an installed dev build without a native rebuild. The bundle lands on disk and loads at launch, so cold-start paths — VoIP wake-ups, background resume — behave like a shipped build, which Metro cannot do.

Install

npx expo install @avasapp/react-native-dhoni expo-sensors

expo-sensors powers shake-to-open and is a required peer dependency.

Use

import { DhoniDevTools } from '@avasapp/react-native-dhoni'

// Mount once, as late in the tree as possible so the icon floats above the app.
<DhoniDevTools />

It renders nothing unless the build opted in — see Gating below. There is no __DEV__ check on purpose: dev-update builds are release-flavoured, which is the whole point of being able to test cold starts.

To point a simulator or CI device at a server without anyone typing into the dev menu, pass the credentials in:

<DhoniDevTools
  seedServerURL={process.env.EXPO_PUBLIC_DHONI_SERVER}
  seedToken={process.env.EXPO_PUBLIC_DHONI_TOKEN}
/>

Read those env vars in your code, not ours. babel-preset-expo inlines EXPO_PUBLIC_* only outside node_modules (getInlineEnvVarsEnabled is gated on !isNodeModule), so the identical read from inside this package resolves to undefined on device — no error, just a build that never contacts the server. Whatever is entered in the dev menu takes precedence over the seed.

Route its logs into your own logger if you want them:

import { setDhoniLogger } from '@avasapp/react-native-dhoni'
setDhoniLogger({ info: logger.info, error: logger.error })

Gating

Two flags must be set at build time, both from your app.config.ts, and both must be absent from production builds:

const DEV_UPDATES =
  ['development', 'development-simulator'].includes(process.env.EAS_BUILD_PROFILE ?? '') ||
  process.env.DHONI_DEV_UPDATES === '1'

export default ({ config }) => ({
  ...config,
  updates: {
    url: 'https://u.expo.dev/<your-project>',
    ...(DEV_UPDATES ? { disableAntiBrickingMeasures: true } : {}),
  },
  // appVersion does not change when native code does, so a bundle built against
  // new native modules would be offered to an older binary and crash on load.
  runtimeVersion: DEV_UPDATES
    ? { policy: 'fingerprint' }
    : { policy: 'appVersion' },
  extra: { ...config.extra, dhoniDevUpdates: DEV_UPDATES },
})

disableAntiBrickingMeasures removes expo-updates' bad-update recovery path and makes the update URL settable at runtime. Together that would let anything reaching the override API permanently repoint a production app at an arbitrary bundle source. Because the flag is written into Info.plist / AndroidManifest at build time, a production binary simply does not carry it and the native override API refuses regardless of what JS asks for — but gate it anyway, and assert in CI.

What you get

• Floating icon — draggable, snaps to the nearer edge, remembers its position. Green dot when a bundle is downloaded and waiting for a relaunch; amber ring when the running bundle was published from a dirty tree.
• Dev menu — shake to open, or tap the icon. Shows branch, commit, publisher, runtime version and commits since the previous bundle. Check for updates, reload, pin a publisher, enter server credentials, hide the icon.

Hiding the icon is sticky across launches; shake still reaches the menu, and the menu warns you before you disable both.

Two-launch semantics

The native update check runs at launch before any JS, so the URL override applied from JS only affects the next check. DhoniDevTools fetches explicitly right after applying it, which makes the launch useful rather than wasted: launch N downloads, launch N+1 runs it.

That shape is what you want for cold-start testing anyway — the bundle is already on disk before the launch under test.

Deliberately not themed

The dev surface styles itself and is always dark. Borrowing the host app's theme system would mean this UI stops rendering exactly when the app's providers are broken, which is when you most need to read it. For the same reason the menu is built on React Native's Modal and the icon on PanResponder, so neither needs a gesture-handler root or a working provider stack.