Cocoapods: BCSymbolMaps in vendored xcframework generate invalid app archive

[CFKevinRef]

• [x] I've read and understood the CONTRIBUTING guidelines and have done my best effort to follow.

Report

What did you do?

CocoaPods 1.9.1
Xcode 11.3.1 and 11.4

The goal is to create a vendored xcframework pod with bundled dSYM and bitcode symbol maps. When the pod is consumed, archiving should pick up the dSYMs and the bitcode symbol maps.

1. Created a pod (let's call it InternalLib) with a vendored xcframework (InternalLib.xcframework)
   
   
   
   • Added a BCSymbolMaps directory _within the platform framework_ as apparently required* by #9334
   
   
2. pod install into a new project
3. Product -> Archive in Xcode

* Like so:

- InternalLib.xcframework/
  - ios-armv7_arm64_arm64e/
    - InternalLib.framework/
      - BCSymbolMaps/
        - ${UUID}.bcsymbolmap
        - ${UUID}.bcsymbolmap
        - ${UUID}.bcsymbolmap

What did you expect to happen?

• Archiving succeeds and generates a valid iOS archive.
• Apps built from this project should not have the .bcsymbolmap files as part of the app bundle

What happened instead?

Archiving _completed_ but the Organizer window is not shown. Attempting to open the archive from Finder results in an alert with "The archive could not be installed. The archive may be corrupt or unreadable." It seems the archive only contains BCSymbolMaps/, dSYMs/, and Products/. It is missing an Info.plist as well as SCMBlueprint/ and SwiftSupport/

Also I'm noticing that apps built with this pod have that whole BCSymbolMaps/ directory included when embedding the framework.

Debugging steps taken

Removing the BCSymbolMaps directory allows the archive to complete successfully, but of course then the bitcode symbol maps from the framework are not in the resulting archive.

It seems that having that nonstandard BCSymbolMaps directory in the framework itself _even just in CONFIGURATION_BUILD_DIR_ is incompatible with some part of the archiving process. It's not enough to simply strip this out when embedding the framework, it must be done in the artifacts script (or there just needs to be a different way to include these other than modifying a framework bundle).

As a quick hack, modifying the Prepare Artifacts script like the following seems to be a workaround. I get a successful archive and all the expected symbol maps are there.

  if [ -d "${source}/${BCSYMBOLMAP_DIR}" ]; then
    # Locate and install any .bcsymbolmaps if present
    find "${source}/${BCSYMBOLMAP_DIR}/" -name "*.bcsymbolmap"|while read f; do
      install_artifact "$f" "$destination" "true"
    done
    # hack: remove this nonstandard directory from destination
    rm -r "${destination}/$(basename "$source")/${BCSYMBOLMAP_DIR}"
    # end hack
  fi

CocoaPods Environment

Stack

   CocoaPods : 1.9.1
        Ruby : ruby 2.6.3p62 (2019-04-16 revision 67580) [universal.x86_64-darwin19]
    RubyGems : 3.0.3
        Host : Mac OS X 10.15.4 (19E266)
       Xcode : 11.4 (11E146)
         Git : git version 2.25.0
Ruby lib dir : /System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib
Repositories : master - git - https://github.com/CocoaPods/Specs.git @ cd0cf75c537e681401ace6836cdcf3c4cb893a0c

               trunk - CDN - https://cdn.cocoapods.org/

Project that demonstrates the issue

In progress. The current library is not suitable for public release.

[dnkoutso]

Great bug report! Not sure for the actual fix here would appreciate any further investigation on what we can change here. I can make a 1.9.2 release with this.

[CFKevinRef]

I was thinking this could be avoided by supporting an implicit {XCFRAMEWORK_NAME}.BCSymbolMaps like is already done with {XCFRAMEWORK_NAME}.dSYMs. I have a proof of concept already working with updated CoconutLib/BananaLib examples. I'll see when I can roll it up into a PR.

[dnkoutso]

great. I can guide you through the PR for whatever it needs to land.

[amorde]

One of the nice things about _not_ using an umbrella {XCFRAMEWORK_NAME}.BCSymbolMaps is that we can select the ones for the correct slice, rather than including _all_ of them.

If the issue is that we are leaving the BCSymbolMap folder behind inside the framework, that's an easy fix. I'm working on re-doing a bunch of the XCFramework stuff but was taking a break the last couple of weeks

[CFKevinRef]

I agree about the umbrella directories, it just seemed to be the convention.

That said, it seems that when you "drag in" an XCFramework with the individual frameworks containing dSYMs/ and BCSymbolMaps/ directories, everything from the selected framework is copied over into the resulting archive in the appropriate place.

Perhaps that can be the officially supported configuration? Example:

- InternalLib.xcframework/
  - ios-armv7_arm64_arm64e/
    - InternalLib.framework/
      - BCSymbolMaps/
        - ${UUID}.bcsymbolmap
        - ${UUID}.bcsymbolmap
        - ${UUID}.bcsymbolmap
      - dSYMs/
        - InternalLib.framework.dSYM

edit: it would be really nice to be able to reuse the exact same InternalLib.xcframework for manual integration and delivery via CocoaPods, and this seems to enable that.

[CFKevinRef]

Heh, another data point - Xcode (11.4) does not check (much? at all?) for validity or relevance of the .bcsymbolmap or .dSYM when archiving an app consuming an xcframework with the above structure. I dropped a simulator dSYM in the device framework and it copied over to the resulting archive.

[amorde]

Yep, this is why CocoaPods has to manually strip dSYMs of invalid architectures. Injecting dSYMs from vendored libraries isn't something Xcode really "supports", it's something CocoaPods provides as a value-add

[douglashill]

We are also seeing this issue with our customers integrating PSPDFKit. We believe it worked correctly in 1.9.0 (or a beta).

[amorde]

I’ll take a look at this during the weekend

[amorde]

Found some time for this, PR is up #9888