xcodebuild of cocoapods project with PRODUCT_NAME fails

Question 1

Try creating a config file and move the PRODUCT_NAME and CONFIGURATION_BUILD_DIR variable to a xcconfig flag in your xcodebuild command.

Example of your xcconfig text file will look like this:

PRODUCT_NAME='This is my app'
CONFIGURATION_BUILD_DIR=/Users/myusername/Documents/myiosproject/build

Pass it into your xcodebuild:

xcodebuild [options and other args] -xcconfig mynewconfig.xcconfig

May want to do a clean and remove DerivedData for good measure, and perhaps try the build command a couple of times. xcodebuild command line seems to be pretty finicky.

Edit: If you can, I recommend giving xctools a shot. It has made my headache with xcodebuild go away.

Question 2

I have the same problem and found the root cause about the problem.

Environment: Xcode 6.1 (6A1052c), OSX 10.10 (14A389)

Problem

The cause is the PRODUCT_NAME property not only affects built *.app but also library *.a files for CocoaPods.

I tried Dean's and Joel's solutions, but not worked for me. In my scenario, I need to build many *.app files with different product name and some little different in image resources and settings. Thus, I want to build different *.app files in a build script which I can trigger the process with just a click.

Here's what happens if we set PRODUCT_NAME in xcodebuild's options with *.xcworkspace in following command:

xcodebuild -workspace $PROJECT_NAME.xcworkspace \
           -scheme $PROJECT_NAME \
           -configuration Distribution \
           CONFIGURATION_BUILD_DIR=$PROJECT_SRC/build \
           PRODUCT_NAME=$NEW_PRODUCT_NAME build

xcodebuild builds $NEW_PRODUCT_NAME.app
xcodebuild builds *.a libray files of CocoaPods with name $NEW_PRODUCT_NAME.a, which should be libPods-CocoaLumberjack.a and libPods.a
In the linker step, project settings ask for linking with libraries by properties -lPods and -lPods-CocoaLumberjack. Since library files are also affected by PRODUCT_NAME property, linker cannot find find *.a files.
Build fail

Per Dean's solution, the problem still occurs even write PRODUCT_NAME config in *.xcconfig file.

And for Joel's solution, the PRODUCT_NAME config before the xcodebuild command does not in effect for new product name.

For Full's question:

And more strangely, if I use the first command and then the second command it will work. (Delete the build directory to reset.)

It's because of the first build already built essential *.a files of CocoaPods. Even the second time builds some $NEW_PRODUCT_NAME.a files (not used), the *.a files needed for linker step are already there for linking. That's why the second build process success.

My solution

Finally, my solution is that build the project and CocoaPods libraries separately.

In project's src folder
Build CocoaPods libraries with following command
```
xcodebuild -project Pods/Pods.xcodeproj build
```

Build project with following command and add CocoaPods and other necessary libraries in search path (Don't forget to include all your necessary libraries)

xcodebuild -project $(TARGET_PROJ) \
           -configuration Distribution \
           -target $(TARGET_TAR) \
           PRODUCT_NAME=$(NEW_PRODUCT_NAME) \
           LIBRARY_SEARCH_PATHS="./Pods/build/Release-iphoneos $OTHER_PATH"

Build!

These are worked for me to have a one-click build script for same binary but with some different images and settings. Hope this will help someone who have the same problem.

Question 3

I found the answer. You need to place PRODUCT_NAME=MyProductName before the xcodebuild command is given.

So

# This does NOT work
xcodebuild ... options ... PRODUCT_NAME=MyProductName

# This DOES work
PRODUCT_NAME=MyProductName xcodebuild ... options ...

Not sure why this second from works while the first does not. I'm speculating that the second form allows the setting to percolate more deeply down to the linker and other subcommands that xcodebuild delegates to, as a better env var setting, whereas the first does not. But that's just speculation. In any event, the second form works.

I have verified this in OS X 10.9.2 with Xcode 5.1.1.

Good luck!