Cocoapods: `Embed pod frameworks` took long time to execute

[akshay23]

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

Report

What did you do?

ℹ Please replace this with what you did.
Built project via Xcode (for real device)

What did you expect to happen?

Build process should be quick but the Embed pod frameworks step takes about 3 minutes to complete

ℹ Please replace this with what you expected to happen.
Should only take a few seconds

What happened instead?

ℹ Please replace this with of what happened instead.
Embed pod frameworks step took a long time to complete. But it did eventually finish

CocoaPods Environment

ℹ Please replace this with the output of pod env.

Stack

   CocoaPods : 1.1.1
        Ruby : ruby 2.3.1p112 (2016-04-26 revision 54768) [x86_64-darwin16]
    RubyGems : 2.5.1
        Host : Mac OS X 10.12.1 (16B2555)
       Xcode : 8.1 (8B62)
         Git : git version 2.9.3 (Apple Git-75)
Ruby lib dir : /Users/akshaybharath/.rvm/rubies/ruby-2.3.1/lib
Repositories : Specs - https://github.com/CocoaPods/Specs.git @ 5c1428cce43f10233397969ac09179c57d7dc355

Installation Source

Executable Path: /Users/akshaybharath/.rvm/rubies/ruby-2.3.1/bin/pod

Plugins

cocoapods-deintegrate : 1.0.1
cocoapods-plugins     : 1.0.0
cocoapods-search      : 1.0.0
cocoapods-stats       : 1.0.0
cocoapods-trunk       : 1.1.1
cocoapods-try         : 1.1.0

Podfile

# coding: utf-8

platform :ios, '8.0'

target :slideshow do
    #AppServiceClient podspec has NYXImagesKit as a dependency.
    #This line must come before ASC's line, in order for the warnings in NYXImagesKit to be suppressed successfully
#---BEGIN SUPPRESSING ASC DEPENDENCY WARNINGS---#
    pod 'NYXImagesKit', :inhibit_warnings => true
#    pod 'AFNetworking', :inhibit_warnings => true
#---END SUPPRESSING ASC DEPENDENCY

    pod 'libextobjc', '~> 0.4'
    pod 'SVProgressHUD'
    pod 'CircleProgressBar', '~> 0.31'
    pod 'ZendeskSDK', '1.5.4.1'
    pod 'VIMNetworking'
    pod 'GoogleAnalytics'
    #pod 'gtm-oauth2', :inhibit_warnings => true #source code imported due to pod being broken
    pod 'SnowplowTracker'
    pod 'Mixpanel'
    pod 'Fabric'
    pod 'Crashlytics'
    pod 'NSString+RemoveEmoji'

    #ASC pods
    pod "FBSDKCoreKit", "~> 4.5.1"
    pod "FBSDKLoginKit", "~> 4.5.1"
    pod "FBSDKShareKit", "~> 4.5.1"
    pod "AFNetworking", "~> 2.6.0"
    pod "NYXImagesKit"
    pod "Reachability"
end

target :slideshowTests do
    # See podfile notes below on OCMock and configuration of each target.
    # Add test specific pods here.  Pods from slideshow are automagically
    # available in this target so do not re-include them or there will be
    # insidious duplicate copies of those classes.
    #don't use link with approach for each target or duplicate classes are imported
    pod 'OCMock', '~> 3.0'
end


target :ascUnitTests do
    #use_frameworks!
    pod 'OCMock', '~> 3.0'
    pod 'JPSimulatorHacks'
    #pod 'Quick'
    #pod 'Nimble'
end

target :ascIntegrationTests do
    pod 'OCMock', '~> 3.0'
    pod 'JPSimulatorHacks'
end

target :ascIntegrationTestsLongRunning do
    pod 'OCMock', '~> 3.0'
    pod 'JPSimulatorHacks'
end

[benasher44]

Hi @akshay23! I recently added #6088 in the latest beta. If you add that flag to your build settings as a user-defined setting or throw it into an xcconfig you might have, that should help speed things up.

[benasher44]

Can you give that a try? It's available in the latest 1.2.0 beta, which you can install by doing gem install cocoapods --pre or modifying your Gemfile. Thanks!

[zvonicek]

Hi there, I experience the same problem. Compilation for device always gets stuck for a few minutes on Running 2 of 3 custom shell scripts phase (Embed pod frameworks). This problem does not occur when building app for simulator.

This was however not a problem before, it started to appear after upgrade to Xcode 8.1.

[benasher44]

@zvonicek can you try my suggestion?

[zvonicek]

@benasher44 I tried that and it's bit faster, but still not as fast as it used to be.

[benasher44]

Hm. 3 minutes is quite a long time. My project has a larger Podfile, and my build phase takes ~2.5s for me. Can @akshay23 or @zvonicek share a project that reproduces the issue?

Since I haven't experienced this, there's not all that much I can do to help without some kind of repro project. Someone could also try profiling this build phase. You'd just have to go into the build phase in Xcode and open up the script listed there. Once inside, you can add time in front of commands you suspect are slow to see how long they take. That's often how I get started anyway.

[AJMiller]

@benasher44 while I can't personally release the project as a test I'm working on, I can tell you we're experiencing this on three separate machines running Xcode 8.1. All of the time seems to be spent in codesign where the console dumps a ton of these: CSSM Exception: -2147409622 CSSMERR_TP_NOT_TRUSTED

[nicolasgoutaland]

@benasher44 I did encounter the same problem, and did install cocoapods 1.2 --pre. This seems to speed up the process for the Embed pod frameworks phase.
But, archiving / exporting an application take a hug amount of time, because each framework is codesigned (About 30minutes to export my application now).

Is there a configuration to set to speed up this process ? If there a way to generate only one framework will all pods, preventing this problem ?

Regards

[jeremypiednoel]

I have the same issue than @nicolasgoutaland

[benasher44]

@nicolasgoutaland so it sounds like time to codesign a binary has increased dramatically in Xcode 8.1 or there's an issue with your (and others) environments that's causing codesign to take up more time. I'm not sure why this is, but filing a radar/bugreport for Apple would be useful to make sure Apple understands that this is a relevant/new issue.

CocoaPods doesn't support generating a single framework with all pods, and this could cause all kinds of name-spacing issues. That said, there may be plugins out there that try to do this, which is useful if most of your pods belong to you and likely share the same namespace anyway.

[benasher44]

Based on a recent comment in #3455 and lack of repro steps, it seems like this can be caused by any number of environmental factors. I'm going to close this, since there doesn't seem to be more that CocoaPods can do to fix this.

[zvonicek]

Just for reference, I checked the Keychain and certificate replication is not the issue. The only thing I know is that it started happening after Xcode 8.1 upgrade, it now takes few seconds to codesign one CocoaPods framework which makes the device debugging pretty much unusable for me now.

[jeremypiednoel]

It was that for me thanks @benasher44
http://stackoverflow.com/questions/40257968/slow-app-compilation-with-new-sierra-update/40298722#40298722

[raphaeloliveira]

Hi, on my project the [CP] Embed Pods Frameworks is taking around 9 seconds every time even though no files have been changed. Should this happen after the change to include input and output files?

[raphaeloliveira]

Ok, I think I found the issue, I have one of my pods declared as

pod 'InMobileMME', :configuration => ['Prod-Release', 'Test-Release'], :git => '<git repo>'

which then automatically adds to the [CP] Embed Pods Frameworks the following entry on Output Files:
${TARGET_BUILD_DIR}/${FRAMEWORKS_FOLDER_PATH}/InMobileMME.framework.

When not running on the configurations defined on the Podfile, the [CP] Embed Pods Frameworks will always run because InMobileMME.framework is not there.

Any suggestions on how to fix this issue? Would that be something that Cocoapods can do?

[dnkoutso]

seems like a bug but you are commenting on a very old issue. Please open a new one and add a sample app demonstrating the issue and uses the issue template.

[dnkoutso]

since there is no issue yet...I'll comment here. It is possible as I am reading this that we cannot do this as script phases are tied to a single target and therefore we cannot differentiate between debug and release for input and output paths.

[raphaeloliveira]

@dnkoutso, https://github.com/CocoaPods/CocoaPods/issues/8181