i have a problem to distributing application with 2 project (one project with sub-project include inside). When i try to make as usual "archive", i'm not able to send application.
Could someone help me?
Regards
I'm guessing the sub-project is a library? And when you do Build > Archive you get an .xcarchive file instead of a .ipa? If so, you need to set the Skip Install flag to No on your library (see this answer), then Build > Archive will generate a .ipa file.
The reason this is happening is because you have two projects.
For the sub-project you need to edit the Target > Build Settings and set the Skip Install setting to Yes.
Afterwards the "Archive" action will work as usual.
Related
I already finished my project, it works and runs perfectly on the simulator or in my own device. When I select to Archive the project to upload de build to Itunes Connect, I get all these compile errors
"Use of undeclared type MBProgressHUD"
"Use of unresolved identifier MPProgressHUD"
And so on..
NOTE: I'm using CocoaPods for this library
What solved it for me was adding import MBProgressHUD in the classes where I use this library, not only in the Bridge-Header.h
Navigate to your project build settings and find the “Swift Compiler – Code Generation” section (You may find it faster to type in “Swift Compiler” into the search box to narrow down the results)
Next to “Objective-C Bridging Header” you will need to add the name/path of your header file. If your file resides in your project’s root folder simply put the name of the header file there. Examples: “ProjectName/ProjectName-Bridging-Header.h” or simply “ProjectName-Bridging-Header.h”.
Refer this link http://www.learnswiftonline.com/getting-started/adding-swift-bridging-header/
Welcome to Cocoapods Hell (a.k.a. : where the magic ends), where one must dive into his project build settings and make sense of what went wrong...
It's very hard to answer to you, as any number of reasons might be causing that.
Do you use the same target for Build / Run & Archive ? It might be because your libPods.a isn't copied into your Archive target
Have you installed Pods using pod install , have you tried playing that command again. (yes, faced with magic going wrong, one can sometimes rely on magic to save him again)
'Build' and 'Archive' product often differ in the build configuration they use (Build most of the time uses 'debug' configuration, while Archive uses 'release' configuration... ). Check your Pods configuration files (debug/release) and make sure they both include your MBProgressHud. Also, in your Project 'Info', check which pods Xcode configuration files are selected for 'debug' and 'release'
Good luck !
(PS : as MBProgressHud is a single file, and one you can often change, another solution is to get rid of Cocoapods and just copy/paste it)
In my Xcode project I have a custom build phase which runs a script and downloads some images for use by the app. What I want to do is to automatically add those image to the project during the build. Right now, I have to build once (which downloads the files), and then manually add those files to the project. It works as long as the file names don't change. Instead, I'd like to add all the files in a specific directory to the project.
I've tried setting the Output Files value, as suggested here, like this:
$(PROJECT_DIR)/$(PROJECT_NAME)/External Assets/*
but it doesn't work. Any idea if this can be done?
Create a directory with the .bundle extension. Add this bundle to your app's resources. When the project builds, it will automatically copy every file in the bundle, even if they are changed or added after you first add the bundle to the project.
I have an Xcode project with a large number of targets where I would like to include a settings bundle for apps built under the Ad-hoc and Debug configurations, but not under the Release configuration.
Build Phases don't seem to allow for making themselves conditional on configuration (they can obviously be conditional on target, but doubling the number of targets in the project would make it completely unusable).
That leaves writing a custom Build Rule. My plan is to exclude the Settings.bundle from all targets, and create a build rule that conditionally copies it into the product package, but applicable examples are really hard to find.
The build rule I've started has the Process setting set to "Source files with names matching:" and Settings.bundle as the name. The Using setting is "Custom script:".
My custom script is as follows (with the caveat that my bash scripting is on a cargo cult level):
if [${CONFIGURATION} = 'Debug'] then
cp -r ${INPUT_FILE_PATH} ${DERIVED_FILES_DIR}/.
fi
Finally, I have ${DERIVED_FILES_DIR}/Settings.bundle listed as an output file.
Since I'm here, it should be obvious that it's not working. My first question is whether there is somewhere I can view the output of the build rules as the execute to make sure that 1) it's actually being executed and that 2) I don't have a stupid syntax error somewhere.
Also, what's the proper location (in the form of an environment variable) to copy the output to?
I finally figured it out.
For each target for which you want to conditionally include the settings bundle, choose its Project from the source list, choose the target, and switch to the "Build Phases" tab.
Click the "Add Build Phase" button and choose "Add Run Script".
Then enter the following for the script:
if [ "${CONFIGURATION}" == "Debug" ]; then
cp -r "${PROJECT_DIR}/Settings.bundle" "${BUILT_PRODUCTS_DIR}/${PRODUCT_NAME}.app"
fi
I know this question has been answered already, and the answer was very helpful to me, but I wanted to throw my own modified solution out there as well.
My requirement was to have different settings bundles for different build configurations, rather than just not including it at release. Assuming a simplistic approach of only Debug and Release configurations, here's how to do it:
Start by adding 2 settings bundles to the project, named Settings-debug.bundle and Settings-release.bundle and then remove these files from the Copy Bundle Resources build phase. Next add a user defined build setting called SETTINGS_BUNDLE, which has different values for each configuration:
Debug ${PROJECT_DIR}/relative/path/to/Settings-debug.bundle
Release ${PROJECT_DIR}/relative/path/to/Settings-release.bundle
Next add a run-script build phase (after Copy Bundle Resources) named Copy Settings Bundle with a modified version of the script in Frank's solution.
cp -r "${SETTINGS_BUNDLE}/" "${BUILT_PRODUCTS_DIR}/${PRODUCT_NAME}.app/Settings.bundle"
The difference here is that the copied bundle is always named Settings.bundle regardless of the source name.
You then need to add another build phase script to prevent code signing errors when the only changes are in the settings bundles. It forces the code signing step to occur on every build. This should run before the Compile Source Files build phase. I called mine Force Codesign.
touch "${PROJECT_DIR}/relative/path/to/main.m"
For complied sources, there is a poorly documented user defined build setting that can be added. Files can be both excluded and included from compilation
Go to your target's Build Settings > Tap the + button > Add User-Defined Setting
The key is either INCLUDED_SOURCE_FILE_NAMES or EXCLUDED_SOURCE_FILE_NAMES
The value is a space separated list of file paths
See reference:
http://lists.apple.com/archives/xcode-users/2009/Jun/msg00153.html
(Tested with Xcode 9.3)
I can't find when Xcode included this feature but EXCLUDED_SOURCE_FILE_NAMES is now directly available in Build Settings > Build Options > Excluded Source File Names.
So you no longer need to create a User-Defined Setting.
See below:
It will automatically add this line in your .pbxproj.
Settings.bundle is always copied into destination area no matter whether Release or Debug configuration. So, maybe you need the following code:
if [ ${CONFIGURATION} == "Release" ]; then
rm -rf ${BUILT_PRODUCTS_DIR}/${PRODUCT_NAME}.app/Settings.bundle
fi
I am no shell script expert but I think you need space between the square brackets and the condition. Also, quoting the variables may help:
if [ "${CONFIGURATION}" = "Debug" ] then
cp -r "${INPUT_FILE_PATH}" "${DERIVED_FILES_DIR}"/.
fi
As for the location, I use "$BUILT_PRODUCTS_DIR"/"$FULL_PRODUCT_NAME" for the root of my OS X app bundle.
What I did:
I have a script that
Read some configuration files to generate source code snippets
Find relevant Objective-C source files and
Replace some portions of the source code with the generated code in step 1.
and a Makefile that has a special timestamp file as a make target and the configuration files as target sources:
SRC = $(shell find ../config -iname "*.txt")
STAMP = $(PROJECT_TEMP_DIR)/$(CONFIGURATION)$(EFFECTIVE_PLATFORM_NAME).stamp
$(STAMP): $(SRC)
python inject.py
touch $(STAMP)
I added this Makefile as a "Run Script Build Phase" on top of the stack of build phases for the project target.
What happened:
The script build phase was run before compiling the source.
However, since the script modifies source code during its execution, I needed to build twice to get the most recent version of the build product. Here is what I imagine to be happening:
1st run: Xcode collects dependency information ---> no changes
1st run: Xcode runs "Run Script Build Phase" ---> source is changed behind Xcode's back
1st run: Xcode finishes build, thinking nothing needs to be updated
2nd run: Xcode collects dependency information ---> source has changed, needs rebuild!
2nd run: Xcode runs Run Script Build Phase" ---> everything is up-to-date
2nd run: Xcode proceeds to compilation
After reading Xcode documentation on Build Phases, I tried adding a source file which is known to be updated every time the script is run as the output of "Run Script Build Phases", but nothing changed. Since the number of configuration files may vary in my project, I don't want to specify every input and output file.
Question:
How do I make Xcode aware of source file changes made during "Run Script Build Phase"?
Edit:
Added that I placed the script build phase before the other build phases
Every technique mentioned so far is an overkill. Reproducing steve kim's comment for visibility:
In the build phases tab, simply drag the "Run Script" step to a higher location (e.g. before "Compile Sources").
Tested on Xcode 6
This solution is probably outdated. See the higher voted answer instead; I no longer actively use Xcode and am not qualified to vet a solution.
Use "External Target":
Select "Project" > "New Target..." from the menu
Select "Mac OS X" > "Other" > "External Target" and add it to your project
Open its settings and fill in your script setup
Open the "General" tab of the main target's settings and add the new target as it's direct dependency
Now the new "External Target" runs before the main target even starts gathering dependency information, so that any changes made during the script execution should be included in the build.
There is another, slightly simpler option that doesn't require a separate target, but it's only viable if your script tends to modify the same source files every time.
First, here's a brief explanation for anyone who's confused about why Xcode sometimes requires you to build twice (or do a clean build) to see certain changes reflected in your target app. Xcode compiles a source file if the object file it produces is missing, or if the object file's last-modified date is earlier than the source file's last-modified date was at the beginning of the first build phase. If your project runs a script that modifies a source file in a pre-compilation build phase, Xcode won't notice that the source file's last-modified date has changed, so it won't bother to recompile it. It's only when you build the project a second time that Xcode will notice the date change and recompile the file.
Here's a simple solution if your script happens to modify the same source files every time. Just add a Run Script build phase at the end of your build process like this:
touch Classes/FirstModifiedFile.m Classes/SecondModifiedFile.m
exit $?
Running touch on these source files at the end of your build process guarantees that they will always have a later last-modified date than their object files, so Xcode will recompile them every time.
As of Xcode 4, it looks like if you add the generated files to the output section of the build phase, it will respect that setting, and not generate the ... has been modified since the precompiled header was built error messages.
This is a good option if your script is only generating a handful of files each time.
I as well struggled with this for a long time. The answer is to use ento's "External Target" solution. He is WHY this problem occurs and how we use it in practice...
Xcode 4 build steps do not execute until AFTER the plist has been compiled. This is silly, of course, because it means that any pre-build steps that modify the plist won't take effect. But if you think about it, they actually DO take effect...on the NEXT build. That's why some people have talked about "caching" of plist values or "I have to do 2 builds to make it work." What happens is the plist is built, then your script runs. Next time you build, the plist builds using your modified files, hence the second build.
ento's solution is the one way I've found to actually do a true pre-build step. Unfortunately I also found that it does not cause the plist to update without a clean build and I fixed that. Here is how we have data-driven user values in the plist:
Add an External Build System project that points to a python script and passes some arguments
Add user-defined build settings to the build. These are the arguments that you pass to python (more on why we do this later)
The python script reads some input JSON files and builds a plist preprocessor header file AND touches the main app plist
The main project has "preprocess plist files" turned on and points to this preprocessor file
Using touch on the main app plist file causes the main target to generate the plist every time. The reason we pass in build settings as parameters is so our command-line build can override settings:
Add a user-defined variable "foo" to the prebuild project.
In your prebuild you can use $(foo) to pass the value into the python script.
On the command-line you can add foo=test to pass in a new value.
The python script uses base settings files and allows for user-defined settings files to override the defaults. You make a change and immediately it ends up in the plist. We only use this for settings that MUST be in the plist. For anything else it's a waste of effort....generate a json file or something similar instead and load it at run-time :)
I hope this helps...it's been a couple rough days figuring this out.
The External Target solution from #ento no longer works as of Xcode 11.5. The solution is to add all files that will be changed under Output Files in the Run Script.
Another option is to create a subproject framework with your scripts and just add it as a dependency to all targets. The phase scripts of this subproject should now be executed before all targets.
I am developing an app and I am using an open source component.
I have a workspace containing both MyApp.xcodeproj and Component.xcodeproj. My app has three configurations: Debug, App Store and In House but the component has only two: Debug and Release
In the Debug configuration, everything works fine, but I can't compile my app in App Store or In House configuration because the configuration names do not match. I get a file not found error when trying to #import <Component/Component.h>
I need both App Store and In House configurations and I would really like to avoid modifying the component's configurations in order to ease future updates of the component.
I know I could use CocoaPods to solve this issue but I would like to know if there is a simple solution in Xcode
You can get your project to compile with some tweaks to your app’s settings.
I suggest you to modify all settings at the project level so that all your targets can inherit these settings.
Add a new DEFAULT_CONFIGURATION user-defined setting and define your configuration mapping. This is how it should look like:
Set FRAMEWORK_SEARCH_PATHS to $(BUILD_DIR)/$(DEFAULT_CONFIGURATION)-$(PLATFORM_NAME) for all configurations, add Any OS X SDK variants and set the value to $(BUILD_DIR)/$(DEFAULT_CONFIGURATION). Set HEADER_SEARCH_PATHS to $(FRAMEWORK_SEARCH_PATHS)/include and LIBRARY_SEARCH_PATHS to $(FRAMEWORK_SEARCH_PATHS). This is how it should look like:
This step is quite tedious, it can be automated with the xcproj tool and by running this script in your project directory. Edit your configurations mapping as needed.
#!/bin/bash
CONFIGURATIONS=( "App Store:Release" "In House:Release" "Debug:Debug" )
for CONFIGURATION in "${CONFIGURATIONS[#]}"; do
xcproj --configuration "${CONFIGURATION%%:*}" write-build-setting DEFAULT_CONFIGURATION "${CONFIGURATION#*:}"
done
xcproj write-build-setting 'FRAMEWORK_SEARCH_PATHS' '$(BUILD_DIR)/$(DEFAULT_CONFIGURATION)-$(PLATFORM_NAME)'
xcproj write-build-setting 'FRAMEWORK_SEARCH_PATHS[sdk=macosx*]' '$(BUILD_DIR)/$(DEFAULT_CONFIGURATION)'
xcproj write-build-setting 'HEADER_SEARCH_PATHS' '$(FRAMEWORK_SEARCH_PATHS)/include'
xcproj write-build-setting 'LIBRARY_SEARCH_PATHS' '$(FRAMEWORK_SEARCH_PATHS)'
If the component is distributed as a static library, you are done here. If the component comes as a framework you have to update its path reference by editing your project.pbxproj file in a text editor. In the PBXFileReference section (under /* Begin PBXFileReference section */) find Component.framework and update its path like this:
name = Component.framework; path = "../$(DEFAULT_CONFIGURATION)/Component.framework"; sourceTree = BUILT_PRODUCTS_DIR; };
Also make sure that the sourceTree is set to BUILT_PRODUCTS_DIR, i.e. relative to built products. Once you edited the project file, this should look like:
Your project should now build as expected.
I had this same problem, but I had multiple configurations (Debug, TestFlight, Release, Enterprise) in my app, and the bolded configurations would always fail to build cause it couldn't find the frameworks. I really didn't want to mess with the project settings of my sub projects in order to make updating them easy.
The answer I found was to just update the framework search path to account for the fact that the frameworks would be dropped in Release (or whatever the default configuration is set to) of the sub projects.
Specifically I set it to:
$(BUILD_DIR)/Release-$(PLATFORM_NAME)
I set it to be recursive too. This works both for Simulator and Device, building in Xcode and command line.
I solved it in the following way,
In my dependency project,
Project -> Target -> Build Phases, added new Run Script
TARGET_DIR="Build"
TARGET_FILE="${TARGET_DIR}/${FULL_PRODUCT_NAME}"
mkdir -p ${TARGET_DIR}
rm -rf ${TARGET_FILE}
cp -rf "${BUILT_PRODUCTS_DIR}/${FULL_PRODUCT_NAME}" ${TARGET_DIR}
After the every build, I copy the build to my Build directory inside the project.
And from the main project,
Project -> Target -> General, I drag and dropped the dependency Framework (which is inside dependency project's Build folder)
then,
Project -> Target -> Build Settings -> Framework Search Paths, under my custom Build Configuration, I added the following
$(PROJECT_DIR)/../DependencyProject/Build
The folder is relative to my main project, and this should be relative to your project.
Then in my all the schemes, I added a Pre-actions script for Build with
rm -Rf "${PROJECT_DIR}/../DependencyProject/Build"
Also you need to select the app against Provide build settings from drop down.