Cocoapods: IBDesignable not works with the frameworks which links with CocoaPods' framework.

Created on 9 Apr 2018  Â·  59Comments  Â·  Source: CocoaPods/CocoaPods

Report

What did you do?

Use my custom framework which linked with CocoaPods' Framework

What did you expect to happen?

Just works.

What happened instead?

Failed:

[MT] IBSceneUpdate: [scene update, delegate=<IBStoryboardDocument: 0x7feec9364800>] Error Domain=com.apple.InterfaceBuilder Code=-1 "Failed to load designables from path /Users/sinoru/Library/Developer/Xcode/DerivedData/Ovey-fmwxmwpxyfgdluaoblaljoqussjk/Build/Intermediates.noindex/IBDesignables/Products/Debug-iphonesimulator/OveyUIKit.framework" UserInfo={NSLocalizedFailureReason=dlopen(OveyUIKit.framework, 1): Library not loaded: @rpath/JGProgressHUD.framework/JGProgressHUD
  Referenced from: OveyUIKit.framework
  Reason: no suitable image found.  Did find:
    /Users/sinoru/Library/Developer/Xcode/DerivedData/Ovey-fmwxmwpxyfgdluaoblaljoqussjk/Build/Intermediates.noindex/IBDesignables/Products/Debug-iphonesimulator/JGProgressHUD.framework/JGProgressHUD: required code signature missing for '/Users/sinoru/Library/Developer/Xcode/DerivedData/Ovey-fmwxmwpxyfgdluaoblaljoqussjk/Build/Intermediates.noindex/IBDesignables/Products/Debug-iphonesimulator/JGProgressHUD.framework/JGProgressHUD'
, <…>

CocoaPods Environment

Stack

   CocoaPods : 1.5.0
        Ruby : ruby 2.5.0p0 (2017-12-25 revision 61468) [x86_64-darwin17]
    RubyGems : 2.7.3
        Host : Mac OS X 10.13.4 (17E199)
       Xcode : 9.3 (9E145)
         Git : git version 2.17.0
Ruby lib dir : /Users/sinoru/.rbenv/versions/2.5.0/lib
Repositories : master - https://github.com/CocoaPods/Specs.git @ 18020377917e622f64b4b73808de98b6cf39e5be

Installation Source

Executable Path: /Users/sinoru/.rbenv/versions/2.5.0/bin/pod

Plugins

cocoapods-deintegrate : 1.0.2
cocoapods-plugins     : 1.0.0
cocoapods-search      : 1.0.0
cocoapods-stats       : 1.0.0
cocoapods-trunk       : 1.3.0
cocoapods-try         : 1.1.0

Podfile

# -*- mode: ruby -*-
# vi: set ft=ruby :

workspace 'Ovey.xcworkspace'

# Comment the next line if you're not using Swift and don't want to use dynamic frameworks
use_frameworks!

target 'OveyUIKit' do
  project 'OveyUIKit/OveyUIKit'
  platform :ios, '9.0'

  # Pods for OveyKit
  pod 'JGProgressHUD', '~> 2.0'

  target 'OveyUIKitTests' do
    inherit! :search_paths
    # Pods for testing
  end

  target 'Ovey' do
    project 'Ovey/Ovey'
    platform :ios, '9.0'

    # Pods for Ovey
    pod 'Firebase', '~> 4.10'
    pod 'Firebase/RemoteConfig'
    pod 'GoogleSignIn', '~> 4.1'
    pod 'FBSDKLoginKit', '~> 4.31', :inhibit_warnings => true
    pod 'Bolts', :inhibit_warnings => true
    pod 'FBSDKCoreKit', :inhibit_warnings => true
    pod 'naveridlogin-sdk-ios', '~> 4.0'
    pod 'Kakao', :podspec => 'PodsSpecs/Kakao.podspec'

    pod 'PhoneNumberKit', '~> 2.1'

    target 'OveyTests' do
      inherit! :search_paths
      # Pods for testing
    end

    target 'OveyUITests' do
      inherit! :search_paths
      # Pods for testing
    end
  end
end

# Workaround for @IBDesignable (https://github.com/CocoaPods/CocoaPods/issues/5334)
post_install do |installer|
  installer.pods_project.targets.each do |target|
    next if target.product_type == "com.apple.product-type.bundle"
    target.build_configurations.each do |config|
      config.build_settings['CONFIGURATION_BUILD_DIR'] = '$PODS_CONFIGURATION_BUILD_DIR'
    end
  end
end

Project that demonstrates the issue

It works just before as is. But it happens after Xcode updates.
I think it is related to macOS changes which is (from Xcode 9.3 Release Notes):

The debugger on macOS now requires the entitlement com.apple.security.get-task-allow to attach to apps built for macOS or for iOS, tvOS or watchOS apps built for Simulator. Xcode automatically injects this entitlement to your builds. The entitlement is stripped from apps distributed using the Organizer window. (34638816)
To disable Xcode injecting the entitlement, set CODE_SIGN_INJECT_BASE_ENTITLEMENTS to NO in the build settings for the target or app. (34638816)

So, default CocoaPods behavior is when to create Pods Project, It disables whole codesign. But now, at least, iOS Simulator requires codesign. So maybe default behavior should be changed?

I know that is frameworks referred from application it self, it will be works because of Embed Pods Frameworks phases(which do codesign if codesign not exist). But If IBDesignable-like thing used, may be frameworks can be referred from BUILT_PRODUCTS_DIR which is not signed, So IBSceneUpdate can be failed.

easy help wanted

Most helpful comment

@sinoru Yes, that fixes it.

Here's a post install hook that can be used until this is fixed and merged. Add it to the bottom of your Podfile and run pod install

# Workaround for Cocoapods issue #7606
post_install do |installer|
    installer.pods_project.build_configurations.each do |config|
        config.build_settings.delete('CODE_SIGNING_ALLOWED')
        config.build_settings.delete('CODE_SIGNING_REQUIRED')
    end
end

All 59 comments

I do not think there is support for IBDesignable in CocoaPods. are you suggesting this was working in 1.4.0?

@dnkoutso Yes. It was working previsouly, until macOS policy changed (With Xcode 9.3).

Same problem on version 1.5.0, I slove the issue by demotion version to 1.4.0.

Can confirm, receiving issues with an IBDesignable framework in 1.5.0 but fine in 1.4.0

would love a sample app here and also someone to investigate.

I check that removing CODE_SIGNING_ALLOWED, CODE_SIGNING_REQUIRED settings on the project which is created by CocoaPods solves this problem.

This is caused by now macOS requires codesigns (even dummy codesigning) when debugger attach to it. But, frameworks are not codesigned, so..
IBDesignables requires Interface Builder's process(debugger attached) to load frameworks, but it can't.

Here is a sample app: https://github.com/luispadron/PodDesignableTest

It uses one of my pods, if you pod update with cocoapods 1.5.0, the designable view in main.storyboard will not show and sometimes an error (code signing) will show up. If you run pod update with 1.4.0 the designable works as intended and shows up on IB as expected.

If you run pod update with 1.4.0 the designable works as intended and shows up on IB as expected

Thank you very much! I've spent around five hours fixing the problem.

<edited by orta/> Has somebody tested it with XCode 9.3?

@Serproger please don't use language like you did in our CocoaPods issues, that's not cool.

Can confirm downgrading to 1.4 fixed the issue.
I spent two days trying to figure this out. I even completely reinstalled OSX to rule out local and caching issues.

Reading the issue, I am uncertain if this is an Xcode 9.3 issue and most likely a CocoaPods library issue, it seems that it works for everyone in Xcode 9.3 and CocoaPods 1.4 so this leads me to believe that its a CocoaPods issue and not an Xcode issue.

@dnkoutso, agreed seeing as how it works on both of my machines on Xcode 9.3 and pods 1.4 but breaks with 1.5.

Remove CODE_SIGNING_ALLOWED, CODE_SINING_REQUIRED should make it works.
May I create pull request of this?

Yes please :)

@sinoru Yes, that fixes it.

Here's a post install hook that can be used until this is fixed and merged. Add it to the bottom of your Podfile and run pod install

# Workaround for Cocoapods issue #7606
post_install do |installer|
    installer.pods_project.build_configurations.each do |config|
        config.build_settings.delete('CODE_SIGNING_ALLOWED')
        config.build_settings.delete('CODE_SIGNING_REQUIRED')
    end
end

Same happened to me with TTTAttributedLabel: https://github.com/TTTAttributedLabel/TTTAttributedLabel/issues/783

I think this is the same issue we're seeing in https://github.com/Skyscanner/SkyFloatingLabelTextField/issues/201 too

can i fix that in podspec?

@Anobisoft no idea, but I add @soleares workaround, https://github.com/CocoaPods/CocoaPods/issues/7606#issuecomment-381279098, it worked, :)

after building, the stars did not appear in the view

Is it so hard just to support IBDesignables in CocoaPods and make sure they don't break again in subsequent versions?

(without resorting to these hacks)

@Jon889 I believe it's just a matter of someone taking the time to implement it and add tests to make sure we don't break it down the road. The most active CocoaPods contributors have been working on other features such as Swift static library support, static frameworks, Podspec-based unit tests, performance improvements, etc.

PRs are welcome!

Any updates here?

I created pull request #7640, and waiting for comment.

It's also worth nothing that IBDesignables, at least for now, will not work with static libraries (see https://stackoverflow.com/a/44733038/1001911) though there are some suggestions for ways to update your build configuration to use dynamic frameworks for designable targets at development time. Maybe there's a way to allow for a pod developer to specify this in the podspec in the future?

@soleares Thanks a lot man! Wasted an entire day on this.

FYI, the posted work around doesn't seem to work any more.

Yes, the workaround stopped working for me as well. Any ideas when it will be fixed in CocoaPods, or any new workaround?

The issue still has.
And this does not work for me.

Xcode: 9.3.1
CocoaPods: 1.5.3

Workaround for Cocoapods issue #7606
post_install do |installer|
installer.pods_project.build_configurations.each do |config|
config.build_settings.delete('CODE_SIGNING_ALLOWED')
config.build_settings.delete('CODE_SIGNING_REQUIRED')
end
end

Confirmed issue still persists

Xcode 9.4
CocoaPods 1.5.3

The workaround doesn't seem to work..

I can "clean" the error with the above solution, but the issue still persist for me too after a while working with some views.

XCode 9.4.1
Cocoapods 1.5.3

Does downgrading to 1.4.0 works?

Thanks

I don't see the error anymore downgrading to 1.4.0

sudo gem uninstall cocoapods
sudo gem install cocoapods -v 1.4.0
pod update

When this issue going to fixed, should we move to the Carthage or SPM

When this issue going to fixed, should we move to the Carthage or SPM

@anilabsinc-ajay, only after SPM will work with UIKit. God will bless that day.

There is a PR in review, be patient

I downgraded my Cocoapods version to 1.4.0 but still facing the same issue. Xcode version is 9.4.1. Any suggestions?

@miraz029 The post-install hook above works for me with Cocoapods 1.5.0 and Xcode 9.4.1. Did you add the hook to your Podfile?

I did a pod update this morning and broke a lot of things which I have now fixed, apart from this issue discussed on this thread.

I have added the hook suggested as above to my pod file and running Cocoapods v1.5.3 and Xcode v9.4.1 and still no luck!

any other suggestions that may have fixed this issue for others?

This is my error:

Main.storyboard: error: IB Designables: Failed to render and update auto layout status for ConversationsListVC (ZGv-vB-cXa): dlopen(MapboxNavigation.framework, 1): Library not loaded: @rpath/Mapbox.framework/Mapbox
  Referenced from: MapboxNavigation.framework
  Reason: image not found

Again, we’re waiting for the PR to get merged which fixes this bug. I don’t know why it’s taking so long to get approved but there is no need to keep about this issue since it’s known

@rigaldamez Please try 1.5.0 with the post install hook. It’s been working for me for a while.

@soleares Yes, that worked! - Cocoapods v1.5.0 and Xcode v9.4.1 with the post install hook got rid of the error.

I've also been trying to figure out this error for a week or two now and just stumbled across this post. @soleares I downgraded to Cocoapods v1.5.0 and I'm using Xcode v9.4.1, tried the post install hook and pod updated, no luck. Still having the same error:
IB Designables Failed to render and update auto layout status for MasterVC (...): The agent threw an exception.

@frederickjjoubert I'm not sure. I would try the following:

Clean everything

You may have already done this but I'll list it in case not.

  • Command line

    • pod deintegrate

    • pod install

  • Xcode

    • delete derived data

    • Product -> Clean

    • Product -> Clean Build Folder (holding option)

Wait for the fix PR https://github.com/CocoaPods/CocoaPods/pull/7640 to be merged and released

I know this doesn't solve your issue, but I wanted to mention it before the next suggestion.

Install the Cocoapods version from the PR

If you can't wait you could install the cocoapods version from the PR.

  • Uninstall cocoapods
  • Create a Gemfile in the root of your project

    source 'https://rubygems.org'
    gem 'cocoapods', :git => '[email protected]:sinoru/CocoaPods.git', :branch => 'remove-codesign-config'
    
  • sudo gem install bundler
  • bundle install

After the fix is released:

  • Update your Gemfile for the new release version (assuming 1.5.4)
```
source 'https://rubygems.org'
gem 'cocoapods', '1.5.4'
```

  • bundle update

For the latest COCOAPODS (1.5.3) please view this comment and try this post_install hook as the workaround:

# Workaround for Cocoapods issue #7689 (and #7606? - to be confirmed)
post_install do |installer|
    installer.pods_project.build_configurations.each do |config|
        config.build_settings['CODE_SIGNING_ALLOWED'] = 'YES'
        config.build_settings.delete('CODE_SIGNING_REQUIRED')
    end
end

For the latest COCOAPODS (1.5.3) please view this comment and try this post_install hook as the workaround:

# Workaround for Cocoapods issue #7689 (and #7606? - to be confirmed)
post_install do |installer|
    installer.pods_project.build_configurations.each do |config|
        config.build_settings['CODE_SIGNING_ALLOWED'] = 'YES'
        config.build_settings.delete('CODE_SIGNING_REQUIRED')
    end
end

This also works for CocoaPods 1.6.0.beta.2

The fix is included in 1.6.0.beta.2 - the workaround shouldn't be necessary on that version

@amorde Same issue still persists in 1.6.0.beta.2

For us this issue was all about run paths. There's another thread somewhere that has part of this solution posted but given the recent comments and the trouble we had on our team we thought we'd share our fix:

post_install do |installer|
  installer.pods_project.build_configurations.each do |config|
    next unless config.name == 'Debug'
    config.build_settings['LD_RUNPATH_SEARCH_PATHS'] = [
      '$(FRAMEWORK_SEARCH_PATHS)'
    ]
  end
end

For us this issue was all about run paths. There's another thread somewhere that has part of this solution posted but given the recent comments and the trouble we had on our team we thought we'd share our fix:

post_install do |installer|
  installer.pods_project.build_configurations.each do |config|
    next unless config.name == 'Debug'
    config.build_settings['LD_RUNPATH_SEARCH_PATHS'] = [
      '$(FRAMEWORK_SEARCH_PATHS)'
    ]
  end
end

This seemed to work.

iOS 12.2 
XCode 10.2.1
Pod V 1.6.1

Analyzing dependencies
Downloading dependencies
Using Mapbox-iOS-SDK (4.10.0)
Using MapboxCoreNavigation (0.32.0)
Using MapboxDirections.swift (0.27.3)
Using MapboxMobileEvents (0.9.3)
Using MapboxNavigation (0.32.0)
Using MapboxNavigationNative (6.1.3)
Using MapboxSpeech (0.1.1)
Using Polyline (4.2.1)
Using Solar (2.1.0)
Using Turf (0.3.0)

Everything was working and today out of nowhere I started to have this issue. I've updated cocoa pods itself and all the pods, but took a lot of time to fix.

But, I still have this issue with 1.7.1.

I've tried all post_install fixes.
I've tried cleaning build folder & derived data.
I've tried re-running pod update.
I've tried restarting XCode and Mac OS multiple times.

I've tried downgrading to 1.4.0, but I can't do it, because one of pods I use requires 1.5.0.

Using Xcode 10.2.1 by the way.

I'm completely stuck. Project runs, but I cannot edit Storyboard (well, technically, I can edit stuff, but I don't see the changes unless I restart Xcode or run the app on the device).

Here's how it looks like:
Screenshot 2019-05-31 at 13 46 53

One error for each instance of GoogleMaps view.

edit:

Here's my Podfile:

# Uncomment the next line to define a global platform for your project
platform :ios, '11.0'

target 'Awesome App' do
  # Comment the next line if you're not using Swift and don't want to use dynamic frameworks
  use_frameworks!
  inhibit_all_warnings!

  pod 'SwiftyJSON'
  pod 'SlideMenuControllerSwift', :git => 'https://github.com/AtomicSLLC/SlideMenuControllerSwift.git', :branch => 'swift5'
  pod 'PKHUD', '~> 5.0'
  pod 'IQKeyboardManagerSwift'
  pod 'Alamofire', '~> 4.6'
  pod 'FacebookCore'
  pod 'FacebookLogin'
  pod 'FacebookShare'
  pod 'Stuff/Codable', '0.6.0'
  pod 'GoogleMaps', '2.6.0'
  pod 'Charts'
  pod 'Kingfisher', '~> 4.0'
  pod 'SDCAlertView'
  pod 'Cosmos', '~> 15.0'
  pod 'DLRadioButton', '~> 1.4'
  pod 'CVCalendar', '~> 1.6.1'
  pod 'Firebase/Core'
  pod 'Firebase/Messaging'
  pod 'RealmSwift'
  pod 'Fabric'
  pod 'Crashlytics'
  pod 'CircleProgressBar', '~> 0.32'

end

post_install do |installer|
    installer.pods_project.targets.each do |target|
        target.build_configurations.each do |config|
            config.build_settings['DEBUG_INFORMATION_FORMAT'] = 'dwarf'
        end
    end

    installer.pods_project.build_configurations.each do |config|
        config.build_settings.delete('CODE_SIGNING_ALLOWED')
        config.build_settings.delete('CODE_SIGNING_REQUIRED')
    end

end

Funny thing: it also yields this issue on view controllers, which don't contain GoogleMap view at all.

Some time ago the error disappeared, but reappeared after several minutes. And nothing helps..

I even tried doing this:

import GoogleMaps

class GoogleMapView: GMSMapView {

}

What's more funny, even after changing GMSMapView to UIView I'm still getting the same errors.

I've tried deleting Derived Data, cleaning, restarting Xcode, restarting Mac, reinstalling Pods.

Issue still present on 1.7.4. Develop private pod with class
```import UIKit

@IBDesignable public class BorderedView: UIView {
@IBInspectable var borderColor: UIColor? = UIColor.white {
didSet {
if let actualColor = borderColor {
layer.borderColor = actualColor.cgColor
} else {
layer.borderColor = UIColor.white.cgColor
}

        setNeedsDisplay()
    }
}
@IBInspectable var borderWidth: CGFloat = 1 {
    didSet {
        layer.borderWidth = borderWidth
        setNeedsDisplay()
    }
}

}
```

The issue is gone using Xcode 11, cocoapods 1.9.0.beta.2 and implementing the following in the Podfile:

post_install do |installer|
    installer.pods_project.build_configurations.each do |config|
        next unless config.name == 'Debug'
        config.build_settings['LD_RUNPATH_SEARCH_PATHS'] = [
          '$(FRAMEWORK_SEARCH_PATHS)'
        ]
    end
end

For us this issue was all about run paths. There's another thread somewhere that has part of this solution posted but given the recent comments and the trouble we had on our team we thought we'd share our fix:

post_install do |installer|
  installer.pods_project.build_configurations.each do |config|
    next unless config.name == 'Debug'
    config.build_settings['LD_RUNPATH_SEARCH_PATHS'] = [
      '$(FRAMEWORK_SEARCH_PATHS)'
    ]
  end
end

After hours of headache, that worked. I love you guys.
Version: Xcode 11.3.1 / Cocoapods 1.8.4

I get random errors that point in different directions and the IBs will build and display sometimes, sometimes not, just by restarting XCode. Working with this is impossible. Right now I'm struggling with IBDesignables saying (in the new info that's finally available in XCode 12):

The agent raised a "NSUnknownKeyException" exception: [<MyFramework.MyClass 0x00...> setValue:forUndefinedKey:]: this class is not key value coding compliant for the key adjustsImageSizeForAccessibilityContentSizeCategory.

I never even heard of or touched adjustsImageSizeForAccessibilityContentSizeCategory, and it's not present in my class (a UIControl subclass) at all. Everything works fine when I run the app though.

Storyboards are a joke. I haven't had a problem-free session with XCode since I started using IBDesignables.

XCode 12.0.1, CocoaPods 1.9.3. My Podfile contains the code alperkayabasi posted as well as use_modular_headers!. No errors when running pod install.

I don't know where to go with this problem as I have no clue what the underlying cause is, but the thread here seems at least related, so perhaps this will help someone with debugging.

Any workaround for this?
xCode 12.3 with cocoapods 1.10 isn't working with all of solutions mentioned above

Any workaround for this?
xCode 12.3 with cocoapods 1.10 isn't working with all of solutions mentioned above

+1

Try adding this line inside your target:

use_frameworks!
inherit! :search_paths

I can use_frameworks! unfortunately as not all of the pods I use support that.
Is there another way? or some way to debug this error to figure our the cause? (Failed to reload designables from path (null))

Was this page helpful?
0 / 5 - 0 ratings