[iOS] Inconsistent Podfile.lock checksums for hermes-engine across team members due to absolute paths
Description
When multiple developers with identical development environments run pod install, they get different checksums for hermes-engine in Podfile.lock, causing unnecessary git conflicts and confusion.
React Native Version
0.83.0
Affected Platforms
Runtime - iOS
Environment
- React Native: 0.83.0
- CocoaPods: 1.15.2
- Ruby: 3.2.3
- Node: 22.17.0
- macOS: 15.x (darwin24/darwin25)
- Architecture: arm64
Steps to Reproduce
- Create a React Native 0.83.0 project with Hermes enabled
- Developer A (username:
userA) runs:cd ios && pod install - Developer B (username:
userB) runs:cd ios && pod install - Compare the
Podfile.lockchecksums forhermes-engine - Observe different checksums despite identical configurations
Expected Behavior
All team members with identical:
- macOS versions
- Ruby versions
- CocoaPods versions
- Node versions
- Architecture (arm64)
yarn.lockchecksums
Should get the same checksum for hermes-engine in Podfile.lock.
Actual Behavior
Each developer gets a different checksum for hermes-engine.
Example:
- Developer A:
hermes-engine: 89103799388dfbbf1d8e74917538bc7c2be3de7f - Developer B:
hermes-engine: a1234567890abcdef1234567890abcdef12345678 - Developer C:
hermes-engine: b9876543210fedcba9876543210fedcba98765432
Root Cause
Investigation reveals that ios/Pods/Local Podspecs/hermes-engine.podspec.json contains absolute paths with usernames:
"user_target_xcconfig": {
"HERMES_CLI_PATH": "/Users/USERNAME/path/to/project/node_modules/hermes-compiler/hermesc/osx-bin/hermesc"
}This is generated by node_modules/react-native/sdks/hermes-engine/hermes-utils.rb around lines 220-240, where it resolves the absolute path to hermes-compiler.
Since each developer has a different username, the generated podspec.json differs, causing CocoaPods to compute different checksums.
Reproducible Demo
Developer A
cat ios/Pods/Local\ Podspecs/hermes-engine.podspec.json | grep HERMES_CLI_PATH
Output: "/Users/developerA/project/..."
Developer B
cat ios/Pods/Local\ Podspecs/hermes-engine.podspec.json | grep HERMES_CLI_PATH
Output: "/Users/developerB/project/..."Even though the downloaded tarballs have identical checksums:
shasum ios/Pods/hermes-engine-artifacts/hermes-ios-0.14.0-debug.tar.gz
Both get: 832aa5e706235a2802e3c255f0a69ae9b97f213e## Suggested Fix
Modify sdks/hermes-engine/hermes-utils.rb to use relative paths instead of absolute paths in the generated podspec.json, or make the path resolution consistent across all environments.
Possible approaches:
- Use
${PODS_ROOT}or other CocoaPods variables instead of absolute paths - Use paths relative to the project root
- Normalize the path before writing to
podspec.json
Impact
- ❌ Unnecessary git conflicts in
Podfile.lock - ❌ Team confusion about why hashes differ
- ❌ CI/CD inconsistencies
- ❌ Developers hesitant to commit
Podfile.lockchanges
Workarounds
- Designate one person to manage
Podfile.lockcommits - Use
.gitattributeswithios/Podfile.lock merge=union - Use
git update-index --skip-worktree ios/Podfile.lock(not recommended)
Steps to reproduce
Developer A
cat ios/Pods/Local\ Podspecs/hermes-engine.podspec.json | grep HERMES_CLI_PATH
Output: "/Users/developerA/project/..."
Developer B
cat ios/Pods/Local\ Podspecs/hermes-engine.podspec.json | grep HERMES_CLI_PATH
Output: "/Users/developerB/project/..."
shasum ios/Pods/hermes-engine-artifacts/hermes-ios-0.14.0-debug.tar.gz
Both get: 832aa5e706235a2802e3c255f0a69ae9b97f213e
React Native Version
0.83.0
Affected Platforms
Runtime - iOS, Build - MacOS
Output of npx @react-native-community/cli info
npx @react-native-community/cli info
info Fetching system and libraries information...
System:
OS: macOS 26.0.1
CPU: (10) arm64 Apple M1 Pro
Memory: 198.80 MB / 16.00 GB
Shell:
version: "5.9"
path: /bin/zsh
Binaries:
Node:
version: 22.17.0
path: /Users/alejototarobarbieri/.nvm/versions/node/v22.17.0/bin/node
Yarn:
version: 4.9.2
path: /Users/alejototarobarbieri/.nvm/versions/node/v22.17.0/bin/yarn
npm:
version: 11.5.2
path: /Users/alejototarobarbieri/.nvm/versions/node/v22.17.0/bin/npm
Watchman:
version: 2025.09.01.00
path: /opt/homebrew/bin/watchman
Managers:
CocoaPods:
version: 1.16.2
path: /Users/alejototarobarbieri/.rbenv/shims/pod
SDKs:
iOS SDK:
Platforms:
- DriverKit 25.0
- iOS 26.0
- macOS 26.0
- tvOS 26.0
- visionOS 26.0
- watchOS 26.0
Android SDK: Not Found
IDEs:
Android Studio: 2024.3 AI-243.25659.59.2432.13423653
Xcode:
version: 26.0.1/17A400
path: /usr/bin/xcodebuild
Languages:
Java:
version: 17.0.16
path: /opt/homebrew/opt/openjdk@17/bin/javac
Ruby:
version: 3.2.3
path: /Users/alejototarobarbieri/.rbenv/shims/ruby
npmPackages:
"@react-native-community/cli":
installed: 20.0.0
wanted: 20.0.0
react:
installed: 19.2.0
wanted: 19.2.0
react-native:
installed: 0.83.0
wanted: 0.83.0
react-native-macos: Not Found
npmGlobalPackages:
"*react-native*": Not Found
Android:
hermesEnabled: true
newArchEnabled: true
iOS:
hermesEnabled: true
newArchEnabled: true
Stacktrace or Logs
No crash or error logs - this is a checksum inconsistency issue.
Evidence of the problem:
1. Developer A Podfile.lock checksum:
hermes-engine: 89103799388dfbbf1d8e74917538bc7c2be3de7f
2. Developer B Podfile.lock checksum:
hermes-engine: <different-hash>
3. Developer C Podfile.lock checksum:
hermes-engine: <different-hash>
4. All developers have identical:
- React Native: 0.83.0
- CocoaPods: 1.15.2
- Ruby: 3.2.3
- Node: 22.17.0
- Architecture: arm64
- yarn.lock SHA: f1219425032eb3071f15c0a869d356d445599bec
5. Downloaded tarballs are identical:
shasum ios/Pods/hermes-engine-artifacts/hermes-ios-0.14.0-debug.tar.gz
832aa5e706235a2802e3c255f0a69ae9b97f213e
6. Root cause - absolute paths in generated podspec:
$ cat ios/Pods/Local\ Podspecs/hermes-engine.podspec.json | grep HERMES_CLI_PATH
"HERMES_CLI_PATH": "/Users/USERNAME/path/to/project/node_modules/hermes-compiler/hermesc/osx-bin/hermesc"
Each developer has different USERNAME, causing different checksums.
MANDATORY Reproducer
This issue affects any React Native 0.83.0 project with multiple developers on macOS. Steps to reproduce: 1. Create new RN 0.83.0 project: npx @react-native-community/cli init TestProject --version 0.83.0 2. Have Developer A (username: userA) run: cd ios && pod install 3. Have Developer B (username: userB) run: cd ios && pod install 4. Compare checksums: grep "hermes-engine:" ios/Podfile.lock 5. Observe different checksums despite identical environments Root cause verification: cat ios/Pods/Local\ Podspecs/hermes-engine.podspec.json | grep HERMES_CLI_PATHEach developer will have their own username in the absolute path. Repository demonstrating the issue: [You can add your repo URL here if you want, or leave it as "Any RN 0.83.0 project with multiple developers"]
Screenshots and Videos
No response
[!WARNING] Missing reproducer: We could not detect a reproducible example in your issue report. Reproducers are mandatory and we can accept only one of those as a valid reproducer:
- For majority of bugs: send us a Pull Request with the RNTesterPlayground.js edited to reproduce your bug.
- If your bug is UI related: a Snack
- If your bug is build/upgrade related: a project using our Reproducer Template
You can read more about about it on our website: How to report a bug.
Warning
Missing reproducer: We could not detect a reproducible example in your issue report. Reproducers are mandatory and we can accept only one of those as a valid reproducer:
- For majority of bugs: send us a Pull Request with the RNTesterPlayground.js edited to reproduce your bug.
- If your bug is UI related: a Snack
- If your bug is build/upgrade related: a project using our Reproducer Template
You can read more about about it on our website: How to report a bug.
Reproducer Template Not Applicable This issue cannot be reproduced with a single repository because it specifically affects teams with multiple developers with different usernames/home directories.
We experience this as well. Our workaround is to use the checksum generated by the runner, without committing any changes made locally.
We are experiencing the same issue on React Native 0.83.1 (iOS) builds. The behavior matches what’s described in this issue.