SolvedCocoaPods Pod lint fails when containing dynamic-frameworks without simulator architectures

Currently pod trunk is not usable for us as pod lint fails because simulator architectures (i386 and x86_64) are missing. BUT Apple rejects apps containing dynamic-frameworks with simulator architectures.

We deploy two variants of dynamic-framworks

• one with all device and simulator architectures (for debugging)
• one with device-only architectures (for app-submission).

pod lint fails with the following errors:

x86_64 in file SampleSDK/iOS/Sample.framework/Sample (3 slices)

• NOTE | [SampleSDK/SampleSDK and more...] xcodebuild: fatal error: lipo: -remove's specified would result in an empty fat file
• NOTE | [iOS] [SampleSDK/SampleSDK] xcodebuild: ld: warning: ld: warning: ignoring file SampleSDK/iOS/Sample.framework/Sample, missing required architecture x86_64 in file

We were forced to provide device-only architectures as Apple rejects app-submissions containing any simulator-architectures with

ERROR: ERROR ITMS-90087: "Unsupported Architectures. The executable for Sample.app/Frameworks/Sample.framework contains unsupported architectures '[x86_64, i386]'."

Similar issues:
#5275
http://stackoverflow.com/questions/36618252/cocoapods-podspec-push-without-build-simulator-architecture

I almost have the same case with @hberenger . But the third-party in my private pod does not include both i386 and x86_64 libraries.
I add pod_target_xcconfig like this:

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

after that, pod lib lint --skip-import-validation works for me.

I just hope "the lint" can ignore architecture i386 and x86_64. I'm not sure whether it is the right way, though it works.

Hi,
I also ran into the same issue while creating a private pod to wrap a third-party which does not provide i386 libraries : pod lib lint resulted into Undefined symbols for architecture i386.
Finally, I came up with the following workaround (which is a posteriori natural, since my project really doesn't need to be built on i386) : tell the podspec that the project is not buildable on 32 bit simulators, that is :

    subspec.pod_target_xcconfig = {
        'ARCHS[sdk=iphonesimulator*]' => '$(ARCHS_STANDARD_64_BIT)'
    }

(instead of the default ARCHS_STANDARD)

In case it helps... @MarcoBrescianini @dvdblk @lumialxk

@eldewy I managed to go around this issue by replacing the code inside the xcodebuild function of validator.rb by that one :

def xcodebuild
      require 'fourflusher'
      command = ['clean', 'build', '-workspace', File.join(validation_dir, 'App.xcworkspace'), '-scheme', 'Pods-App', '-configuration', 'Release']
      case consumer.platform_name
      when :ios
        command += %w(-sdk iphoneos10.0 -destination=generic/iOS ONLY_ACTIVE_ARCH=NO ARCHS=armv7)
      when :watchos
        command += %w(CODE_SIGN_IDENTITY=- -sdk watchsimulator)
        command += Fourflusher::SimControl.new.destination(:oldest, 'watchOS', deployment_target)
      when :tvos
        command += %w(CODE_SIGN_IDENTITY=- -sdk appletvsimulator)
        command += Fourflusher::SimControl.new.destination(:oldest, 'tvOS', deployment_target)
      end

      output, status = _xcodebuild(command)

      unless status.success?
        message = 'Returned an unsuccessful exit code.'
        message += ' You can use `--verbose` for more information.' unless config.verbose?
        error('xcodebuild', message)
      end
      output
    end

I basically replicated the behaviour of 0.39 to allow our team to push pods. Please note that this is a quick and dirty fix, will only work for ios targets, is only working with xcode8, and might not work for you, but I thought it might help you while waiting for an official fix ;)

A temporary solution：use rvm.
For example：
rvm install ruby 2.2.2. Use 2.2.2 and install cocoapods 0.39.0.

rvm install ruby 2.3.1. Use ruby 2.3.1 and install cocoapods 1.1.1

You can flexibly switch pod's version by using 'rvm use'

1.2.0 supports an option to skip-import-validation if you do not want to link your pod. This is the same as 0.39.0 behavior.