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

Here’s my synthesized knowledge so far:

Forget the whole public header thing with Xcode, it’s a PITA and doesn’t work correctly when archiving your app. Instead, have all static library header files on the project level and tell your app where to find it.

1. Ease your pain by making sure all targets have the same name for the build configuration (i.e. add an “AdHoc” and “Deployment” configuration to the static libraries).

2. In build settings, point the Header Search Paths (if you use #include <file.h>) or User Header Search Paths (if you use #include "file.h") to the directory of the static library project. If the static library project is inside your app directory, use this:

   "$(PROJECT_DIR)" (recursive enabled)

   If you have a directory which contains a) the static library project and b) your app, then this should work:

   "$(PROJECT_DIR)/.." (recursive enabled)

3. If the submodule contains compiled libraries, set your Library Search Paths to:

   "$(TARGET_BUILD_DIR)"

4. Make sure all the static library projects that you use have Skip Install set to YES.

5. Again, no public header files (Build Phases » Copy Headers) in any of the static libraries, otherwise Xcode will not be able to archive an app.

6. Make sure to tell Xcode when to build the static libraries, as shown in this Tech Doc from Apple.

---

Old Answer:

I still haven’t found a real solution to this problem with static libraries. What works for me is:

• Create an “AdHoc” Configuration for the static library
• Add $(BUILT_PRODUCTS_DIR) to User Header Search paths for the application (with recursive checked) -> this is used when running the app
• In the Xcode menu, select Product > Build For > Build For Archiving

This works, the app finds the header files and builds itself, it ends up in DerivedData//Build/Products/AdHoc-iphoneos/ as an App bundle. Following these simple instructions (dead link) from TestFlightApp.com I can pack this App into an IPA and send it around. Simply selecting to Archive the app from Xcode does again not find the headers, even if they truly are in the AdHoc-iphoneos build directory.