Xcode 4 and nested projects — header files not fou

Question

I'm having a myriad of problems with Xcode 4 and nested projects that worked just well under Xcode 3.2. Here's a very basic one I cannot solve:

I'm building a cocoa framework that requires another cocoa framework for which I have the source. So I perform the usual steps:

• Drag the .xcodeproj file of the required framework into my main framework project
• In my main framework under TARGETS > MyFramework > Build Phases > Target Dependencies: Add the nested project's target
• Make sure the header files of the nested framework are public
• In Xcode Settings > Locations > Build Location I have it set to Place build products in derived data location (recommended)
• Build products path of both targets are set to ${BUILT_PRODUCTS_DIR} and tell me they are at the DerivedData/Debug (or Release) location
• Architecture settings for both targets are identical

Then I hit [CMD] + B to build and it tells me that it doesn't find the header files of the nested framework. When I check the settings, User Header Search Paths contain the path to DerivedData/Debug, and inside there is the nested framework target with the header files in Versions/A/Headers.

I'm sitting here, anybody an idea what I'm doing wrong?

---

The issue goes away when building for Debug when I change the User header search paths to ${BUILT_PRODUCTS_DIR}/MyFramework.framework/Headers. However this doesn't work when building for Distribution as the frameworks then use their Release settings, which ends up in a different subdirectory...

---

My temporary solution is to also define a Distribution configuration for the nested projects. This way the headers are found and the linker can link successfully.

Answer 1

I had this problem: I could build both Debug and App Store configurations, but not Ad Hoc. Building Ad Hoc gave me errors because it couldn't find .h files needed by nested projects.

Turned out I had an expired provisioning lingering in my Release configuration. I updated that provisioning link and now I can both build Ad Hoc and use the Archive feature to package it.

Took me hours to figure it out! My mind just didn't jump from missing .h files to provisioning errors just by itself. =) There might have been an error or warning complaining about the missing provisioning, but if so it was well buried among the hundreds of .h related errors.

Answer 2

I was having this issue with a nested project that built a static library. I found this doc on apples site that completely saved my life.

http://developer.apple.com/library/ios/#DOCUMENTATION/Xcode/Conceptual/ios_development_workflow/AA-Developing_a_Static_Library_and_Incorporating_It_in_Your_Application/archiving_an_application_that_uses_a_static_library.html

I'm so glad I didn't have to muck around with the derived data paths.

Answer 3

Make sure your third party framework is added as «group» to your main project, so you can see it in your project's hierarchy...

Answer 4

I was having the same issue with a Configuration named "Ad Hoc" (as per TestFlight recommendation at http://help.testflightapp.com/customer/portal/articles/402782-how-to-create-an-ipa-xcode-4) and the main project could not find some of the headers from the nested projects. I renamed the project to "AdHoc" (no spaces) and the problem went away; seems like spaces can mess up header search paths in some cases, although I haven't figured out the specifics of when that might happen and why.

Answer 5

For me, this happened after a GIT merge, which created many conflicts, one of them related to the project file. After the merge, I'm sure the structure of the project file changed.

What I ended up doing was going into the project "Build Settings", then looking for "Always Search User Paths" and turning it to Yes.

I guess the merge turned this boolean to No, therefore the project wasn't looking in the right places for the header files.

Answer 6

I had the same problem here and I could solve the problem by setting "Build Location" to Place build products in locations specified by targets"