Skip to content


Subversion checkout URL

You can clone with
Download ZIP


Cocoapods adding frameworks from MacOSX.platform rather than iPhoneOS.platform #1420

ExoticObjects opened this Issue · 14 comments

5 participants


I'm wondering if something might be wrong with my local setup, but here are the (very simple!) steps to recreate:

  • Using XCode 5, create and then close an Empty Application (for iPhone) project
  • Run the following simple Podfile:

    platform :ios, '7.0'
    pod 'SVProgressHUD', '0.9'
  • Open the workspace file and note that the frameworks point to MacOSX directories rather than iPhoneOS directories:


screen shot 2013-09-27 at 1 48 42 pm

I can fix them in XCode by pointing them to directories under iPhoneOS.platform:


But if I run pod --verbose update the paths will break again.

Many frameworks appear in both directories, but some don't, like CoreImage.

Here, in case it helps, is the Pods.xcconfig file:

OTHER_LDFLAGS = -ObjC -framework QuartzCore

I'm running cocoapods-0.25.0.

I've searched the open issues and couldn't find anything related.



I have seen this issue also and it resulted in some missing iOS frameworks that aren't present in OSX.


Strange, this issue should have been fixed in CocoaPods 0.25


I'm running 0.25 and have the same problem. Friend is running 0.24 and the same Podfile works on his system.

$ cat Podfile
platform :ios, '7.0'

pod 'AFNetworking', '~> 1.3.3'
pod 'SSKeychain'
pod 'TestFlightSDK', '~> 2.0'


Reverting to cocoapods 0.24.0 fixes the problem for me. For anyone else who has the issue, you can revert by following the instructions here.


  • If you don't have bundler:

    gem install bundler
  • CD to your project's root directory and create a Gemfile

    touch Gemfile
  • Gemfile contents should look like this:

    source ''
    gem 'cocoapods', '0.24.0'
  • Run your podfile via bundler

    bundle exec pod --verbose update

I got a warning that The version of CocoaPods used to generate the lockfile is higher that the one of the current executable. Incompatibility issues might arise. But the framework issue went away and everything else seems to be fine so far.

@irrationalfab - Can you guys recreate this issue?


Props to @ExoticObjects his method works. I installed bundler and used 0.24.0 and now my workspace is correct as well.


"Do the frameworks create any issue with the build"

Not as far as I can tell. But I don't want to give a definitive answer without thoroughly testing, which unfortunately I don't have time to do...

"Is, for any reason, the platform set to OS X when you experience the issue"

I hope not! As indicated above, all you need to do is open an Empty Application (for iPhone) project. (I just updated the initial post to be clearer about this...).

"Those references are for illustrative purposes"
Ok, but the same could be said for any resources listed in the XCode navigator. By convention, if I click on one of those resources, say a JPEG, Xcode will show me the full path. This gives me confidence that I've got the right asset. Similarly, when I click on a framework, I think it's reasonable to expect that I should see the correct path to the framework that is in use.

Regardless, this doesn't happen when you revert to 0.24.0, so there's probably something in the code somewhere...


Sorry for the trouble, defect confirmed. I used the wrong source tree (Relative to SDK instead of Relative to Developer Directory) in a patch introduced in 0.25.


@ExoticObjects Thank you for reporting this! And I completely agree re: Cocoapods! It has changed my life on OSX and iOS.

@irrationalfab is there an ok workaround/patch to use in the meantime, or a patch-commit I can try and reverse engineer? Or is reverting to 0.24.0 still the current best solution? [I am on XC5 - using bleeding-edge]


After some inspection this is the state of the issue:

Xcode sets the file references of the frameworks relative to the Developer Directory. The relative path depends on the name of the platform (as well on the SDK version). The interesting part is that if you add a framework for a platform and then add it for a different one the file reference is not duplicated, so only one is kept with the name of the original platform. For the build there is no problem because only the name of the framework is passed (and the file is identified with the search paths which are correctly set). I consider this an UI issue of Xcode.

As I noticed this issue I changed the file reference to be relative to the SDK, unfortunately Xcode doesn't reflect this in the UI according to the selected build configuration (I guess this is the reason why they are still using the developer directory).

None of the two solutions seem optimal, however in doubt I would use the Xcode one (even I consider my approach more correct). This cause an issue because the target might not have a deployment target set and to detect the last one we would need to ask it to Xcode (which is a bit slow). Not sure how to proceed though. @alloy Dod you have any suggestion?

Regarding the build to my understanding any of those two solutions do not create any issue (I think that the reason Xcode adds the file references is to allow the user to inspect the headers - although I consider the current behavior a suboptimal solution). So you can keep using CP 0.25.


I don't quite understand your comment, but that's probably ok. I have a question, though...

In 0.24.0 at least Cocoapods didn't create red frameworks in the workspace, and didn't cause XCode to display incorrect paths. Although these paths apparently are 'for display only' and don't matter, they will probably continue to cause people to be alarmed. Is there any harm in reverting to the way 0.24.0 handled frameworks? Would that cause other issues?


Did you update CocoaPods?


Oops! Thanks for the fix. I didn't expect an update so quickly!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.