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 coc
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.
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.
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.
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).
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)
If the submodule contains compiled libraries, set your Library Search Paths to:
"$(TARGET_BUILD_DIR)"
Make sure all the static library projects that you use have Skip Install set to YES
.
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.
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:
$(BUILT_PRODUCTS_DIR)
to User Header Search paths for the application (with recursive checked) -> this is used when running the appThis 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.
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"
(As of Xcode 5.1)
When the subproject is built by XCode, the subproject header files are copied into the build directory. When archiving, it seems that this copy destination directory is not added to the header/include search path. You'll want to go to your Build Settings and add
$(BUILD_ROOT)/../IntermediateBuildFilesPath/UninstalledProducts/include
to the "Header Search Paths" for the scheme that you use for archiving.
If you're not sure which scheme is used for archiving, go to Product -> Scheme -> Edit Schemes and look for Archive in the left column.
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.