pod spec lint fails to find matching XCFramework slice for a vendored library dependency

[jakubdolejs]

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

Report

What did you do?

Run pod spec lint on a spec that contains a xcframework dependency.

What did you expect to happen?

The lint should have passed.

What happened instead?

The xcodebuild command failed with

error: no such module 'VerIDCore'
import VerIDCore
       ^

I also noticed this note in the pod spec lint command output:

- NOTE  | [iOS] xcodebuild:  warning: [CP] Unable to find matching .xcframework slice in 'Ver-ID-Core/VerIDCore.xcframework VerIDCore framework ios-i386_x86_64-simulator ios-arm64_armv7' for the current build architectures (arm64 i386 x86_64).

If you download the VerIDCore dependency you'll find it contains slices for armv7, arm64, i386 and x86_64.

Also worth mentioning is that I successfully integrated the VerIDCore dependency in a project. It's only if it's set as a dependency of another podspec that the podspec's lint fails.

CocoaPods Environment

Stack

   CocoaPods : 1.10.0
        Ruby : ruby 2.6.3p62 (2019-04-16 revision 67580) [x86_64-darwin18]
    RubyGems : 3.0.6
        Host : Mac OS X 10.15.7 (19H2)
       Xcode : 12.1 (12A7403)
         Git : git version 2.23.0
Ruby lib dir : /Users/jakub/.rvm/rubies/ruby-2.6.3/lib
Repositories : trunk - CDN - https://cdn.cocoapods.org/

Installation Source

Executable Path: /Users/jakub/.rvm/gems/ruby-2.6.3/bin/pod

Plugins

cocoapods-deintegrate  : 1.0.4
cocoapods-dependencies : 1.3.0
cocoapods-plugins      : 1.0.0
cocoapods-search       : 1.0.0
cocoapods-stats        : 1.1.0
cocoapods-trunk        : 1.5.0
cocoapods-try          : 1.2.0

Podfile

project 'VerIDUI.xcodeproj'
workspace 'VerIDUI.xcworkspace'

platform :ios, '10.3'
use_frameworks!

def veridcore
  pod 'Ver-ID-Core', '2.0.0-beta.04'
end

target 'VerIDUI' do
  veridcore
  pod 'RxSwift', '~> 5'
  pod 'RxCocoa', '~> 5'
end

target 'Ver-ID Sample' do
  pod 'DeviceKit', '~> 4.1'
end

target 'Thumbnails' do
  veridcore
end

target 'Preview' do
  veridcore
end

Project that demonstrates the issue

Github link

[mharlowfod]

Experiencing a similar issue with BugfenderSDK dependency...

[miquelalvarado]

Experiencing the same issue with Didomi-XCFramework dependency. Did you find any workaround?

[hlineholm]

After a closer look at the xcframework bash scripts and what they do, it seems that instead of copying the ios-x86_64-simulator slice to Products/Release-iphonesimulator in derived data, the scripts try to copy the ios-arm64 slice to Products/Release-iphoneos although while linting, -sdk iphonesimulator is used with xcodebuild.
This results in the slice not being copied at all and even if it would be, the architecture would be wrong and thus the symbols would be missing.

This issue might be related to #9525.

[jakubdolejs]

Experiencing the same issue with Didomi-XCFramework dependency. Did you find any workaround?

Yes. But it's so ugly that I even hesitate to call it a workaround. Details here.

[mhdostal]

Also worth mentioning is that I successfully integrated the VerIDCore dependency in a project. It's only if it's set as a dependency of another podspec that the podspec's lint fails.

I also am experiencing this exact issue. I was using Xcode 12.x command line tools and can verify the above statement. If I used the Xcode 11 command line tools I did NOT receive the error and was able to podspec lint successfully.

[mharlowfod]

Just an FYI, my instance of this issue (personal private pod with BugfenderSDK as a dependency) magically went away when I updated to the latest cocoapods version (I am not sure if a BugfenderSDK change came along the way, but I don't think it did).

Not saying it's fixed everywhere, but if you haven't tried in the past 3 weeks, you might kick the tires and see if there's been any improvement.

[mhdostal]

@mharlowfod - thanks for that. I am using v1.10.1, and just solved my issue this morning.

[FWJonathan]

This issue is still occurring for me with v1.10.1 when trying to include BlackBerryDynamics.xcframework:

warning: [CP] Unable to find matching .xcframework slice in '.../BlackBerryDynamics.xcframework BlackBerryDynamics framework ios-x86_64-simulator ios-arm64' for the current build architectures (arm64 x86_64).

[wilmarvh]

Same issue here. I have a private pod with an xcframework dependency and the linting fails with the same.

CocoaPods 1.10.1

[ElfSundae]

Same here when lint or push a pod with a binary xcframework (without i386 arch) dependency.
CocoaPods 1.10.1, it fails either on Xcode 12.4 or Xcode 11.7.
And --skip-import-validation does not help for this situation.

For now, I add --configuration=Debug for pod lib lint, it works. And install pod by specifying the source repo pod 'Name', :git => '...'.

Hope --configuration could be added to the repo push and trunk push commands. #10109

[kerrmarin-lvmh]

@dnkoutso is this something I can help with? I'd be happy to submit a patch but honestly have no idea where to even start. With a bit of guidance I'd be happy to help

[lufinkey]

After doing some digging and logging, I'm able to reproduce this when building for a simulator on an M1 mac and there is no slice in the xcframework with the -simulator suffix for that architecture.

[jindalpatel]

I am also facing the same issue. Unable to find matching .xcframework slice in '../../../../../../../../SplunkMint.xcframework SplunkMint framework ios-arm64 ios-x86_64-simulator' for the current build architectures (arm64 x86_64).

Cocoapod 1.10.2
Xcode 12.5

[StefanMiticon]

I am just trying to push or lint this https://github.com/MappCloud/MappSDK and facing the same issue.

Cocoa pods 1.11.2
Xcode 13.1

Does someone found solution or workaround?

[lufinkey]

I think the ideal behavior for this should be to just fall back to the ios-arm64 architecture rather than ios-arm64-simulator when it's unavailable. I don't really know where that decision gets made in the code, though

[billburgess]

+1

[leninmehedy]

+1

Cocoa pods 1.11.2

Xcode 13.1
Build version 13A1030d

Facing similar issue, and haven't found a solution yet:

 ERROR | [iOS] xcodebuild: Returned an unsuccessful exit code. You can use `--verbose` for more information.
    - NOTE  | xcodebuild:  note: Using new build system
    - NOTE  | xcodebuild:  note: Using codesigning identity override: -
    - NOTE  | xcodebuild:  note: Build preparation complete
    - NOTE  | [iOS] xcodebuild:  note: Planning
    - NOTE  | [iOS] xcodebuild:  note: Building targets in parallel
    - NOTE  | [iOS] xcodebuild:  warning: [CP] Unable to find matching .xcframework slice in 'ios-x86_64-simulator ios-arm64' for the current build architectures (arm64 x86_64).
    - NOTE  | xcodebuild:  clang: error: linker command failed with exit code 1 (use -v to see invocation)
    ```
    
    
    

[LowAmmo]

Anyone know if this might be related to #10058 ?

If so, looks like there is a PR to fix that one - #11093

[omarzl]

Anyone know if this might be related to #10058 ?

If so, looks like there is a PR to fix that one - #11093

I dont think they are related, this one is about xcframework slice selection while #10058 issue is about Swift module include paths

[igor-makarov]

@jakubdolejs

The Ver-ID pod has vendored XCFrameworks that contain frameworks and not libraries, so this is unrelated to issue #10058 mentioned above.

The root cause is that the XCFramework is missing an arm64 binary for the iOS Simulator, the one running on Apple Silicon Macs.

When running pod spec lint, it builds the pod using the Release build configuration. This means, using all active architectures, which for the simulator is arm64 x86_64.

The solution is to add support for arm64 simulators to the binary.

If you're unable to do so, you can use the workaround described in #10104 (comment) to explicitly disallow arm64 simulators from using the binary. This however should be a temporary measure, because the number of developers with Apple Silicon machines is growing faster and faster.

[ElfSundae]

I met this issue before when I tried to publish a pod library that depends on another binary vendored no-arm64-simulator-arch dependency. After some digging, I successfully published my library by using an ugly workaround. Here I'd like to share something and hope this could help someone.

Many people mentioned below solution:

s.pod_target_xcconfig = { 'EXCLUDED_ARCHS[sdk=iphonesimulator*]' => 'arm64' }

But it can not work at all. Configuring EXCLUDED_ARCHS in the spec.pod_target_xcconfig just excludes architectures for the pod library target, not for the app target such as the CocoaPods validator generated app target.

Then:

s.user_target_xcconfig = { 'EXCLUDED_ARCHS[sdk=iphonesimulator*]' => 'arm64' }

I'd like to say this is a terrible way. From the doc of user_target_xcconfig:

This attribute is not recommended as Pods should not pollute the build settings of the user project and this can cause conflicts.

For instance, one pod has:

s.user_target_xcconfig = { 'EXCLUDED_ARCHS[sdk=iphonesimulator*]' => 'arm64' }

and another pod has:

s.user_target_xcconfig = { 'EXCLUDED_ARCHS[sdk=iphonesimulator*]' => 'i386 arm64' }

If the user integrate these two pod libraries, pod install will fail as CocoaPods can not merge the user_target_xcconfig configuration:

[!] Can't merge user_target_xcconfig for pod targets: ["FooPod", "BarPod"]. 
Singular build setting EXCLUDED_ARCHS[sdk=iphonesimulator*] has different values.

The only solution for this issue is to ask the vendor to rebuild their pod library for the arm64-simulator architecture and publish the library with XCFramework format which is the only format can bundle arm64-device and arm64-simulator together.

Before the vendor updates their library, we may modify the CocoaPods source code to skip validating when publishing our library. Below is my ugly workaround:

In order not to modify the global installed pod command, I forked https://github.com/CocoaPods/CocoaPods repo, modified the xcodebuild function in the validator.rb file to skip executing the xcodebuild command during validation, by appending a -usage CLI parameter for the xcodebuild command:

 def xcodebuild(action, scheme, configuration, deployment_target:)
   require 'fourflusher'
   command = %W(clean #{action} -workspace #{File.join(validation_dir, 'App.xcworkspace')} -scheme #{scheme} -configuration #{configuration})
+  command += %w(-usage)

Then the validator will build the app using xcodebuild -workspace ..... -usage which is the same as xcodebuild -usage.

This modification just skips building, not the whole validation.

You may see compare between CocoaPods' master branch and my fork's hack branch at https://github.com/CocoaPods/CocoaPods/compare/master..ElfSundae:hack

Then anyone can use this fork to publish their library, via bundle:

bundle init
bundle add cocoapods --git https://github.com/ElfSundae/CocoaPods.git --branch hack

bundle exec pod repo push

rm Gemfile Gemfile.lock

If you already have Gemfile, omit the first line bundle init and the last line rm Gemfile Gemfile.lock.

In addition, this is an example of publishing podspec using GitHub workflow: https://github.com/ElfSundae/NIM_iOS_UIKit/blob/master/.github/workflows/publish-podspec.yml

[dzmitry-antonenka]

Hello @ElfSundae , I tried to execute bundle add cocoapods --git https://github.com/ElfSundae/CocoaPods.git --branch hack but got this error: Unknown switches '--git, --branch'. I have Bundler version 1.17.2. Could you please support?

[ElfSundae]

@dzmitry-antonenka For bundler 1.17, you may change

bundle add cocoapods --git https://github.com/ElfSundae/CocoaPods.git --branch hack

to

echo 'gem "cocoapods", "~> 1.11", :git => "https://github.com/ElfSundae/CocoaPods.git", :branch => "hack"' >> Gemfile
bundle install