react-native-asset is a command-line tool that links and unlinks assets — fonts, mp3 files, and more — into the native iOS and Android sides of a React Native project, and because it runs at build time with filesystem access, it deserves the same supply-chain scrutiny as any build tool. Where the old react-native link command only handled font files, react native asset supports the full range of asset types and, usefully, unlinks automatically when you delete an asset instead of forcing a manual cleanup.
Most teams meet it the moment they need custom fonts in a bare React Native app. This guide covers what it does, how to run it, and the handful of security habits worth keeping around it.
What the tool does
React Native apps written outside Expo need their static assets copied into the native project structure and registered so the OS can find them. Fonts go into the iOS Info.plist and the Android assets folder; sound files land in the appropriate native directories. Doing this by hand is fiddly and easy to get wrong across two platforms.
react-native-asset reads a config file, copies the declared assets into both native projects, and wires up the platform-specific registration. Delete an asset from your config and re-run it, and it removes the now-orphaned files too. That symmetry is the main reason people prefer it over the legacy link command.
Configuring and running it
You declare assets in react-native.config.js at the project root:
module.exports = {
assets: ['./src/fonts', './src/audio'],
// platform-specific assets are supported too:
// iosAssets: ['./src/fonts/ios'],
// androidAssets: ['./src/fonts/android'],
};
Then run the linker. You can install it globally, but running it on demand through npx keeps your machine clean and pins nothing globally:
npx react-native-asset
That command copies everything in the declared folders into both native builds and registers it. Run it again after adding or removing assets. npx react-native-asset is the invocation you'll see in most setup guides, and it is the one I'd standardize on for a team so nobody depends on a globally installed version drifting out of sync.
Why a build-time tool is a security concern
It is tempting to wave off a font linker as harmless. But look at what it actually is: an npm package that executes on your machine and in CI, reads your project config, and writes files into your native build output. That is a privileged position. Two risk categories matter.
Supply-chain compromise. Any build-time dependency can, if a malicious version is published or a maintainer account is hijacked, run arbitrary code in your development and CI environments. This is not hypothetical for the npm ecosystem — install-time and build-time scripts have been a repeated vector. The exposure scales with how much access your CI token has: a linker running in a pipeline that can also publish releases or read secrets is a far bigger deal than one on a laptop.
Assets as a payload channel. The files this tool copies ship inside your app. If an attacker can influence what lands in your asset folders — through a compromised design-asset pipeline or a poisoned shared drive — those files get bundled and distributed to users. It is a low-probability path, but asset directories are rarely reviewed the way code is.
Hygiene worth adopting
None of this means avoid the tool. It means treat it like the build dependency it is.
Pin the version in your lockfile and commit the lockfile. Use npm ci in CI so installs are reproducible and a surprise version bump fails loudly rather than sliding in. Review the diff whenever this or any build tool changes version — a build-time package moving from a patch you trust to one you haven't seen is worth thirty seconds of attention.
Scan your dependency tree. react-native-asset pulls in its own dependencies, and those are where transitive risk hides. An SCA tool will flag a known-vulnerable transitive package and tell you which direct dependency introduced it, which is the part npm ls makes tedious to work out by hand. An SCA tool such as Safeguard can surface that transitively without you auditing the whole tree manually.
Constrain CI permissions. The build agent that runs npx react-native-asset should have the least privilege that gets the job done. Don't give the job that links fonts access to your signing keys or publish tokens if it doesn't need them.
Finally, know your asset provenance. Keep fonts and audio in version control, review changes to those folders in pull requests, and prefer assets from sources you can vouch for over grab-bag downloads.
Fitting it into a mobile pipeline
In practice, the linking step runs early in a build, before compilation. Put your dependency scan ahead of it so a compromised package is caught before it executes, not after. For teams shipping frequently, wire the SCA check into the same pipeline stage that installs dependencies, and gate the build on critical findings. Our security academy has a fuller walkthrough of ordering security checks in a CI pipeline if you're building one from scratch.
FAQ
What is the difference between react-native-asset and react-native link?
The legacy react-native link command only linked font files and required manual unlinking. react-native-asset supports the full range of assets — fonts, mp3 files, and others — and unlinks automatically when you remove an asset from your config, which makes it the more complete and less error-prone option for bare React Native projects.
How do I run react-native-asset?
Declare your asset folders in react-native.config.js, then run npx react-native-asset from the project root. It copies and registers the assets into both the iOS and Android native projects. Re-run it whenever you add or remove assets so the native side stays in sync.
Is react-native-asset safe to use?
The tool itself is a widely used, legitimate build utility. The security consideration is that, like any build-time npm package, it executes with filesystem access on your machine and in CI. Pin its version, commit your lockfile, scan the dependency tree, and run it with least-privilege CI credentials.
Do Expo projects need react-native-asset?
Generally no. Expo has its own asset and font handling, so this tool is aimed at bare React Native projects that manage the native iOS and Android sides directly. If you later eject from Expo to a bare workflow, it becomes relevant.