Fingerprint React Native build inputs

Computes a deterministic SHA-256 fingerprint of the inputs that determine your native build and exports it as BUNDLE_HASH_STRING, so you can key restore-cache / save-cache off it and skip the expensive native build when only JavaScript changed.

It hashes the files and folders in path_list (folders are hashed recursively), while excluding anything matched by ignore_path_list. The default covers the common React Native native inputs — JS lockfiles, app.json / app.config.js, patch-package patches, and the ios/ and android/ native projects. It deliberately does not hash your JavaScript source, so a JS-only change reuses the cached native build.

ignore_path_list is important for correctness, not just speed: it excludes build outputs that change every run (ios/Pods, android/build, …) and machine-specific files that would otherwise make the fingerprint differ between CI and local (android/local.properties, Xcode user state, …).

Use BUNDLE_HASH_STRING as the key for restore-cache / save-cache, then gate the native/bundle build on restore-cache's BITRISE_CACHE_HIT output. On a hit, repack the new JS bundle into the cached app and re-sign.

The step is skippable: if fingerprinting can't produce a key (or fails), it exports an empty BUNDLE_HASH_STRING — a cache miss that safely forces a rebuild — rather than blocking your pipeline.

Capture every native input. The fingerprint decides whether a previously compiled native app can be reused. If path_list / ignore_path_list omit an input that affects the native build (a native module dir, a config plugin, an extra lockfile), a native change may not move the key and you could repack onto a stale binary. Extend path_list for your project when needed.

This is a lightweight, do-it-yourself pattern built on free Bitrise cache steps. For a fully managed, compilation-level remote cache across Gradle, Xcode (LLVM CAS) and C++, see Bitrise Build Cache for React Native: https://bitrise.io/platform/build-cache/react-native