Unresolved dSYMs path for hermes.xcframework on React Native 0.71.0

[gvarandas]

New Version

0.71.0

Old Version

0.70.6

Build Target(s)

iOS simulator in debug flavor (but the issue will likely happen on any iOS build flavor).

Output of react-native info

System:
    OS: macOS 13.1
    CPU: (8) arm64 Apple M1 Pro
    Memory: 78.59 MB / 16.00 GB
    Shell: 5.8.1 - /bin/zsh
  Binaries:
    Node: 18.9.0 - /var/folders/b5/5157q_1923jffgs5kk5ycn9c0000gn/T/yarn--1673979783677-0.35373539239086704/node
    Yarn: 1.22.19 - /var/folders/b5/5157q_1923jffgs5kk5ycn9c0000gn/T/yarn--1673979783677-0.35373539239086704/yarn
    npm: 8.19.1 - /opt/homebrew/bin/npm
    Watchman: 2022.09.19.00 - /opt/homebrew/bin/watchman
  Managers:
    CocoaPods: 1.11.3 - /Users/gvarandas/.gem/ruby/3.1.2/bin/pod
  SDKs:
    iOS SDK:
      Platforms: DriverKit 21.4, iOS 16.0, macOS 12.3, tvOS 16.0, watchOS 9.0
    Android SDK:
      API Levels: 24, 25, 26, 28, 29, 30, 31, 32, 33
      Build Tools: 29.0.2, 30.0.2, 30.0.3, 31.0.0
      System Images: android-29 | Google APIs ARM 64 v8a, android-29 | Google APIs Intel x86 Atom, android-29 | Google APIs Intel x86 Atom_64, android-31 | Google APIs ARM 64 v8a, android-31 | Google APIs Intel x86 Atom_64, android-33 | Google APIs ARM 64 v8a
      Android NDK: Not Found
  IDEs:
    Android Studio: 2021.3 AI-213.7172.25.2113.9123335
    Xcode: 14.0/14A309 - /usr/bin/xcodebuild
  Languages:
    Java: 11.0.13 - /usr/bin/javac
  npmPackages:
    @react-native-community/cli: Not Found
    react: 18.2.0 => 18.2.0
    react-native: 0.71.0 => 0.71.0
    react-native-macos: Not Found
  npmGlobalPackages:
    *react-native*: Not Found

Issue and Reproduction Steps

Due to a specific requirement, our brownfield project needs to depend on hermes.xcframework directly in order to resolve the Hermes runtime path when building the app for an iOS target.

After upgrading to 0.71.0, we've noticed that builds started to fail with a unresolved path error:

error: Missing path (project/ios/Pods/hermes-engine/destroot/Library/Frameworks/universal/hermes.xcframework/ios-arm64_x86_64-simulator/dSYMs) from XCFramework 'hermes.xcframework' as defined by 'DebugSymbolsPath' in its `Info.plist` file (in target 'iOSTarget' from project 'Project')
ios/Pods/hermes-engine/destroot/Library/Frameworks/universal/dSYMs

The path reference seems to be generated by the following Plist file:

ios/Pods/hermes-engine/destroot/Library/Frameworks/universal/hermes.xcframework/Info.plist

<dict>
  <key>AvailableLibraries</key>
  <array>
    <dict>
      <!-- this entry -->
      <key>DebugSymbolsPath</key>
      <string>dSYMs</string>
      <!--  -->
      <key>LibraryIdentifier</key>
      <string>ios-arm64</string>
      <key>LibraryPath</key>
      <string>hermes.framework</string>
      <key>SupportedArchitectures</key>
      <array>
        <string>arm64</string>
      </array>
      <key>SupportedPlatform</key>
      <string>ios</string>
    </dict>
    <!-- Other architectures -->
  </array>
</dict>

The folder, however, doesn't exist, as debug symbols don't seem to be shipped with the prebundled version of Hermes.

I'm wondering if the DebugSymbolsPath plist entry should be suppressed if debug symbols aren't being generated, as the path doesn't actually exists and just providing an empty folder seems to suffice, signalling that the reference isn't used beyond validating it's existence.

[cortinico]

The folder, however, doesn't exist, as debug symbols don't seem to be shipped with the prebundled version of Hermes.

You're right, we don't ship dSYM for Hermes.

Due to a specific requirement, our brownfield project needs to depend on hermes.xcframework directly in order to resolve the Hermes runtime path when building the app for an iOS target.

Can you clarify your setup? What's the requirement you're talking about.
(cc @cipolleschi)

[ankitjainOfficial]

@cortinico I'm also facing the same problem while upgrading.

I guess, what @gvarandas (Correct me if I'm wrong) means, that they cannot disable hermes in order to proceed.

[gvarandas]

@cortinico we have a brownfield app that's being progressively ported over to React Native. Our iOS setup has multiple frameworks within the same workspace and our React Native configurations are all embedded into one of these frameworks (that isn't the main target), including the pods.

  graph LR;;
      A[Main Target]-->B[React Native Framework];
      A-->F
      B-->C[libPods.a];
      C-->F[hermes.xcframework]
      A-->D[Framework #1];
      A-->E[Framework #2];

Loading

Since enabling Hermes on iOS, we had to add a direct reference to the hermes.xcframework to Main Target, otherwise React Native wouldn't be able to resolve it's path and would crash with an unresolved path error:

Library not loaded: @rpath/hermes.framework/hermes
Referenced from: <4C39F48E-982D-3AB5-AAC2-043DB3748E96> /Users/USER/Library/Developer/CoreSimulator/Devices/D1B619FA-D012-473E-A2F1-931C410D5A16/data/Containers/Bundle/Application/E96877C9-046A-4BFB-81A2-23ADD37F7DC2/Project.app/Frameworks/ReactNativeProject.framework/ReactNativeProject

We haven't been able to solve this issue and the workaround was to reference the framework in the main target, effectively duplicating it. It's not great but it works. 🤷‍♂️

[gvarandas]

For the record, this is what we've setup in our Podfile to avoid the issue for the time being, confirming that removing the Info.plist does, in fact, solve the issue:

post_install do |installer|
  PLIST_BUDDY_PATH = '/usr/libexec/PlistBuddy'

  installer.pods_project.targets.each do |target|
    target.build_configurations.each do |config|
      if target.name == "hermes-engine"
        installer.pods_project.files.each do |fileref|
          if fileref.path.end_with? "hermes.xcframework"
            hermes_plist_file = "#{fileref.real_path}/Info.plist"
            # Patch Hermes to remove the debug symbols entry from the Info.plist (as it's not shipped with it)
            # This might be removed once Hermes starts to ship with Debug symbols or we remove our
            # direct dependency from the Main iOS target on "hermes.xcframework"
            Open3.capture3(PLIST_BUDDY_PATH, '-c', 'Delete :AvailableLibraries:0:DebugSymbolsPath', hermes_plist_file)
            Open3.capture3(PLIST_BUDDY_PATH, '-c', 'Delete :AvailableLibraries:1:DebugSymbolsPath', hermes_plist_file)
            Open3.capture3(PLIST_BUDDY_PATH, '-c', 'Delete :AvailableLibraries:2:DebugSymbolsPath', hermes_plist_file)
          end
        end
      end
    end
  end

end

[cipolleschi]

mmh... I wonder what would happen if we just remove that entry from the hermes-engine.xcframework plist...

For the time being, could you try to use the hermes-engine framework from here: https://repo1.maven.org/maven2/com/facebook/react/react-native-artifacts/0.71.0/react-native-artifacts-0.71.0-hermes-ios-debug.tar.gz

This should download the debug version which may have the dSYMs.

[gvarandas]

mmh... I wonder what would happen if we just remove that entry from the hermes-engine.xcframework plist

It seems to work fine, as that's what we're effectively doing in our Podfile post_install hook.

[ankitjainOfficial]

Can you help with the post_install hook, that you’re using.

On Wed, 18 Jan 2023 at 11:27 PM, Guilherme Varandas < ***@***.***> wrote: mmh... I wonder what would happen if we just remove that entry from the hermes-engine.xcframework plist It seems to work fine, as that's what we're effectively doing in our Podfile post_install hook. — Reply to this email directly, view it on GitHub <#35863 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACD4FMQ2JOOKAFHGDWZDF3TWTAVJRANCNFSM6AAAAAAT6GGTRE> . You are receiving this because you commented.Message ID: ***@***.***>

-- Thanks, Ankit Choraria

[gvarandas]

@ankitjainOfficial It's this one posted above.

[zallanx]

For the record, this is what we've setup in our Podfile to avoid the issue for the time being, confirming that removing the Info.plist does, in fact, solve the issue:

post_install do |installer|
  PLIST_BUDDY_PATH = '/usr/libexec/PlistBuddy'

  installer.pods_project.targets.each do |target|
    target.build_configurations.each do |config|
      if target.name == "hermes-engine"
        installer.pods_project.files.each do |fileref|
          if fileref.path.end_with? "hermes.xcframework"
            hermes_plist_file = "#{fileref.real_path}/Info.plist"
            # Patch Hermes to remove the debug symbols entry from the Info.plist (as it's not shipped with it)
            # This might be removed once Hermes starts to ship with Debug symbols or we remove our
            # direct dependency from the Main iOS target on "hermes.xcframework"
            Open3.capture3(PLIST_BUDDY_PATH, '-c', 'Delete :AvailableLibraries:0:DebugSymbolsPath', hermes_plist_file)
            Open3.capture3(PLIST_BUDDY_PATH, '-c', 'Delete :AvailableLibraries:1:DebugSymbolsPath', hermes_plist_file)
            Open3.capture3(PLIST_BUDDY_PATH, '-c', 'Delete :AvailableLibraries:2:DebugSymbolsPath', hermes_plist_file)
          end
        end
      end
    end
  end

end

Hey @gvarandas, thanks for posting this. I tried to integrating, but always get the outcome uninitialized constant Pod::Podfile::PLIST_BUDDY_PATH when running the post install hooks and is unable to have the pod build.

Did you also encounter this error?

[gvarandas]

@zallanx did you declare the PLIST_BUDDY_PATH' constant on the first line of the post_install` block?

PLIST_BUDDY_PATH = '/usr/libexec/PlistBuddy'

It seems like it's either missing or not being properly populate on your end.

[jkolivuo]

Having the same issue RN 0.71.3 but above solution did not work.

[kiprijonas]

I had to remove Hermes from BuildPhases -> Link Binary With Libraries

[cipolleschi]

Can I ask if some of you have some time to set up a small repro for us? We would like to have this fixed, but so far we are not encountering the problem, so it's a little hard to verify if we are solving it properly. 😅

[adbs1]

Can I ask if some of you have some time to set up a small repro for us? We would like to have this fixed, but so far we are not encountering the problem, so it's a little hard to verify if we are solving it properly. 😅

https://github.com/adbs1/35863

This is the result of manually upgrading from 0.70.6 to 0.71.5

Let me know if anyone else needs access to it.

[adbs1]

An update, the problem in my case was old references to hermes.xcframework in the project.pbx.proj file.

There are no references to hermes in the project.pbx.proj file with any new build, nor in the upgrade diff

I removed these lines and it now builds fine:

4909123929060FDB00E97F47 /* hermes.xcframework in Frameworks / = {isa = PBXBuildFile; fileRef = 4909123829060FDB00E97F47 / hermes.xcframework */; };

4909123829060FDB00E97F47 /* hermes.xcframework */ = {isa = PBXFileReference; lastKnownFileType = wrapper.xcframework; name = hermes.xcframework; path = "Pods/hermes-engine/destroot/Library/Frameworks/universal/hermes.xcframework"; sourceTree = ""; };

4909123929060FDB00E97F47 /* hermes.xcframework in Frameworks */,

4909123829060FDB00E97F47 /* hermes.xcframework */,

[cipolleschi]

😮 Well spotted @adbs1! Thank you for the update!

[adnaneghalem]

I remove dsym from my infoplist and it worked but I don't know what would be future considerations to fix this problem :)

[github-actions]

This issue is stale because it has been open 180 days with no activity. Remove stale label or comment or this will be closed in 7 days.

[donutdognut]

Can I ask if some of you have some time to set up a small repro for us? We would like to have this fixed, but so far we are not encountering the problem, so it's a little hard to verify if we are solving it properly. 😅

https://github.com/adbs1/35863

This is the result of manually upgrading from 0.70.6 to 0.71.5

Let me know if anyone else needs access to it.

Any chance of getting ahold of this?

[cipolleschi]

Sorry for this issue. I'll try to have a look at it.
I'm still confused as a new app, created from the template, does not suffer from the issue. How do you trigger this?

[tshedawa]

This fails only in CI after upgrading to RN 0.73.2 with the error even after running pod install --repo-update

error: Missing path (/Users/runner/work/app-main/app-main/apps/mobile/ios/Pods/hermes-engine/destroot/Library/Frameworks/universal/hermes.xcframework/ios-arm64/dSYMs) from XCFramework 'hermes.xcframework' as defined by 'DebugSymbolsPath' in its `Info.plist` file

@cipolleschi could it be github caches already installed pods from the previous version?

Hey,I am also facing the same issue. Any idea on how you solved it?

[sgshy1995]

An update, the problem in my case was old references to hermes.xcframework in the project.pbx.proj file.

There are no references to hermes in the project.pbx.proj file with any new build, nor in the upgrade diff

I removed these lines and it now builds fine:

4909123929060FDB00E97F47 /* hermes.xcframework in Frameworks / = {isa = PBXBuildFile; fileRef = 4909123829060FDB00E97F47 / hermes.xcframework */; };

4909123829060FDB00E97F47 /* hermes.xcframework */ = {isa = PBXFileReference; lastKnownFileType = wrapper.xcframework; name = hermes.xcframework; path = "Pods/hermes-engine/destroot/Library/Frameworks/universal/hermes.xcframework"; sourceTree = ""; };

4909123929060FDB00E97F47 /* hermes.xcframework in Frameworks */,

4909123829060FDB00E97F47 /* hermes.xcframework */,

@adbs1 which file has these lines? i cant find.

[arunsa-hrbl]

Hi @react-native-bot
why there are so many bugs / issues opened and you guys are simply kept silence yourself ???
Is this something not solvable ??????

I am facing same issue since a month and not a finite solution yet

Can you please look into it ????

Mine has below set ups

`➜ SampleRNApp git:(main) ✗ npx react-native info

WARNING: You should run npx react-native@latest to ensure you're always using the most current version of the CLI. NPX has cached version (0.73.2) != current release (0.73.6)

info Fetching system and libraries information...
System:
OS: macOS 13.6.6
CPU: (10) x64 Apple M1 Max
Memory: 19.41 MB / 32.00 GB
Shell:
version: "5.9"
path: /bin/zsh
Binaries:
Node:
version: 20.12.0
path: ~/.nvm/versions/node/v20.12.0/bin/node
Yarn:
version: 1.22.19
path: ~/node_modules/.bin/yarn
npm:
version: 10.5.0
path: ~/.nvm/versions/node/v20.12.0/bin/npm
Watchman:
version: 2023.08.14.00
path: /usr/local/bin/watchman
Managers:
CocoaPods:
version: 1.15.2
path: /usr/local/opt/ruby/bin/pod
SDKs:
iOS SDK:
Platforms:
- DriverKit 23.2
- iOS 17.2
- macOS 14.2
- tvOS 17.2
- visionOS 1.0
- watchOS 10.2
Android SDK: Not Found
IDEs:
Android Studio: 2023.1 AI-231.9392.1.2311.11330709
Xcode:
version: 15.2/15C500b
path: /usr/bin/xcodebuild
Languages:
Java:
version: 18.0.2
path: /usr/bin/javac
Ruby:
version: 3.3.0
path: /usr/local/opt/ruby/bin/ruby
npmPackages:
"@react-native-community/cli": Not Found
react:
installed: 18.2.0
wanted: 18.2.0
react-native:
installed: 0.73.2
wanted: 0.73.2
react-native-macos: Not Found
npmGlobalPackages:
"react-native": Not Found
Android:
hermesEnabled: true
newArchEnabled: false
iOS:
hermesEnabled: true
newArchEnabled: false

info React Native v0.73.6 is now available (your project is running on v0.73.2).
info Changelog: https://github.com/facebook/react-native/releases/tag/v0.73.6
info Diff: https://react-native-community.github.io/upgrade-helper/?from=0.73.6
info For more info, check out "https://reactnative.dev/docs/upgrading?os=macos".
➜ SampleRNApp git:(main) ✗ `

[cipolleschi]

@arunsa-hrbl I'm sorry that you feel that way. I asked for reproducer in several messages as we are not able to reproduce the issue internally and even by using the OSS pipelines, so there is something specific to the local setup.

I tried several times to spin up applications with React Native 0.71, but they works well, and they builds. It's hard to help if I can't find the line that looks for the 'DebugSymbolsPath'.

[CoryWritesCode]

After following all these steps, migrating from RN 0.72.6 => 0.73.6, I'm getting this error now

After deleting my xcode.local.env file it resolved.
@laishere 's solution worked for me after deleting that local file and cleaning the env.

[losh11]

So after deleting hermes framework reference under Frameworks folder, Xcode automatically removes hermes framework linking too in project main target config. And finally the app runs normally.

I too am facing the same issues as yourself, firstly with the Library not loaded: @rpath/hermes.framework/hermes message. Adding hermes and setting it to embed and sign ends with a build failure. And your fix of deleting Hermes from frameworks does not seem to work.

@cipolleschi If I can help at all, I can bring my laptop to Meta's London offices. I been having these issues for a while now.

[cipolleschi]

@losh11 can you create a reproducer starting from this template? I appreciate your willingness to come to the office, but it is unfortunately not an option.

I'd be more than happy to help you out if you can provide a way for me to reproduce the issue.

[losh11]

@cipolleschi after doing a bunch of testing, I managed to find a fix. It's to do with cocoapods versioning being too old or cocoapods being installed with 2 or more different tools.

On my end, completely uninstalling cocoapods (rubygem + homebrew), and installing the latest version with gem fixed the issue.

[janst44]

So do i just need to upgrade RN to fix this now? I tried removing cocoapods from brew and started using gem. No luck.

[cipolleschi]

@janst44 yes, please. Update and this should be solved.

[mohammad-goldast]

My solution for RN 0.76.3 is here.

[nzcodarnoc]

I'm running into this issue with a fresh install of RN 0.76.5, and the podfile updates suggested here #35863 (comment) have not resolved it.

I'm getting this error when I distribute to App Store Connect

The archive did not include a dSYM for the hermes.framework with the UUIDs [A7F8AE9C-D803-3457-8EA5-BE3293D01B81]. Ensure that the archive's dSYM folder includes a DWARF file for hermes.framework with the expected UUIDs.

[cipolleschi]

Apparently, there is an issue with this and Xcode 16: https://forums.developer.apple.com/forums/thread/763731?page=4

[nzcodarnoc]

For what it's worth, using Xcode 16.2 and a fresh install of RN 0.76.5, it hasn't stopped me getting the iOS app into Test Flight even with the warning.

[cipolleschi]

Yeah, that's just a warning. Apple will not block the app and will not reject the submission for this issue.

[cipolleschi]

Locking this as we are tracking the issue in #49059