I have a Swift project that uses a ObjC dynamic framework, the framework had to be linked with and embedded into my project. The project runs OK in devices, when submitted to App Store, the error occurred during validation:
Found an unexpected Mach-O header code: 0x72613c21
Below are the validation logs:
2015-10-12 02:32:33 +0000 [MT] Beginning distribution assistant for archive: MusicFans, task: Validate
2015-10-12 02:32:33 +0000 [MT] Automatically selecting the only availaable distribution method <IDEDistributionMethodiOSAppStoreValidation: 0x7f851c1d96c0>
2015-10-12 02:32:34 +0000 [MT] [OPTIONAL] Didn't find archived user entitlements for <DVTFilePath:0x7f851b42db10:'/Users/panzhansheng/Library/Developer/Xcode/Archives/2015-10-11/MusicFans 11-10-15 上午8.29.xcarchive/Products/Applications/MusicFans.app/Frameworks/libswiftDispatch.dylib'>: Error Domain=NSCocoaErrorDomain Code=4 "Item at "/Users/panzhansheng/Library/Developer/Xcode/Archives/2015-10-11/MusicFans 11-10-15 上午8.29.xcarchive/Products/Applications/MusicFans.app/Frameworks/libswiftDispatch.dylib" did not contain a "archived-expanded-entitlements.xcent" resource." UserInfo={NSLocalizedDescription=Item at "/Users/panzhansheng/Library/Developer/Xcode/Archives/2015-10-11/MusicFans 11-10-15 上午8.29.xcarchive/Products/Applications/MusicFans.app/Frameworks/libswiftDispatch.dylib" did not contain a "archived-expanded-entitlements.xcent" resource.}
2015-10-12 02:32:34 +0000 [MT] [OPTIONAL] Didn't find archived user entitlements for <DVTFilePath:0x7f8529a08050:'/Users/panzhansheng/Library/Developer/Xcode/Archives/2015-10-11/MusicFans 11-10-15 上午8.29.xcarchive/Products/Applications/MusicFans.app/wavpack.framework'>: Error Domain=NSCocoaErrorDomain Code=4 "Item at "/Users/panzhansheng/Library/Developer/Xcode/Archives/2015-10-11/MusicFans 11-10-15 上午8.29.xcarchive/Products/Applications/MusicFans.app/wavpack.framework" did not contain a "archived-expanded-entitlements.xcent" resource." UserInfo={NSLocalizedDescription=Item at "/Users/panzhansheng/Library/Developer/Xcode/Archives/2015-10-11/MusicFans 11-10-15 上午8.29.xcarchive/Products/Applications/MusicFans.app/wavpack.framework" did not contain a "archived-expanded-entitlements.xcent" resource.}
2015-10-12 02:32:34 +0000 [MT] [OPTIONAL] Didn't find archived user entitlements for <DVTFilePath:0x7f850da13de0:'/Users/panzhansheng/Library/Developer/Xcode/Archives/2015-10-11/MusicFans 11-10-15 上午8.29.xcarchive/Products/Applications/MusicFans.app/FLAC.framework'>: Error Domain=NSCocoaErrorDomain Code=4 "Item at "/Users/panzhansheng/Library/Developer/Xcode/Archives/2015-10-11/MusicFans 11-10-15 上午8.29.xcarchive/Products/Applications/MusicFans.app/FLAC.framework" did not contain a "archived-expanded-entitlements.xcent" resource." UserInfo={NSLocalizedDescription=Item at "/Users/panzhansheng/Library/Developer/Xcode/Archives/2015-10-11/MusicFans 11-10-15 上午8.29.xcarchive/Products/Applications/MusicFans.app/FLAC.framework" did not contain a "archived-expanded-entitlements.xcent" resource.}
2015-10-12 02:33:07 +0000 [MT] Canceled distribution assistant
If I remove the dynamic framework from the project’s Embedded frameworks section, then it can pass the validation, but crashes when run in devices due to the missing image of my dynamic framework, any idea?
BTW, dynamic framework has bitcode disabled, so my project also disables bitcode, and is not codesigned.
Check two things for every framework:
The Mach-O type of the framework (in Build Settings of the framework target)
Whether you copy the framework by putting it in Build Phases -> Embed Frameworks (or Copy Bundle Resources as mentioned by a. brooks hollar)
If the Mach-O type of the framework is "static library", it should not be put in embed frameworks; if the Mach-O type is "dynamic library", it should be put in embed frameworks.
In my case it was SocketRocket I added manually which has both a static library target and a dynamic library target with the same framework name. After deleting the static library target and only embed the dynamic library framework, the problem disappears.
Note:
If you don't have access to the source project, you can manually check if it's a dynamic or static framework using this approach: https://stackoverflow.com/a/32591983/308315
I don't know why but somehow pods appeared to become an embedded binary. So I had to remove it, pod install once more, and the issue disappeared.
On Xcode 11 you need to change it to Do Not Embed in the Frameworks, Libraries, and Embedded Content.
Double check Build Phases -> Copy Bundle Resources for a framework or other binary that shoundn't be there.
In my case, it was a 3rd party library (Parse) that I had added.
In my case, I have a framework manually dragged into my project, and it is listed in General->Embedded Binaries, which cause error Found an unexpected Mach-O header code: 0x72613c21. After i moved it from Embedded Binaries to Linked Frameworks and Libraries, problem solved.
If you (potentially but not necessarily) used FirebaseSDK (especially Analytics) and get Mach-O error while running, archiving and uploading, try this:
Add this as a build post-actions script.
rm -rf "${TARGET_BUILD_DIR}/${TARGET_NAME}.app/Frameworks/FirebaseAnalytics.framework"
rm -rf "${TARGET_BUILD_DIR}/${TARGET_NAME}.app/Frameworks/GoogleAppMeasurement.framework"
rm -rf "${TARGET_BUILD_DIR}/${TARGET_NAME}.app/Frameworks/FIRAnalyticsConnector.framework"
if you added widgets and/or other plugin extensions add these lines as well:
rm -rf "${TARGET_BUILD_DIR}/${TARGET_NAME}.app/PlugIns/FirebaseAnalytics.framework"
rm -rf "${TARGET_BUILD_DIR}/${TARGET_NAME}.app/PlugIns/GoogleAppMeasurement.framework"
rm -rf "${TARGET_BUILD_DIR}/${TARGET_NAME}.app/PlugIns/FIRAnalyticsConnector.framework"
Brief explanation:
The below quote is from the relevant discussion under https://github.com/firebase/firebase-ios-sdk/issues/6472 explains the reason behind this problem.
... so right now the firebase framework artifacts are being copied into
the /Frameworks folder of the ipa and are embedded. The frameworks
themselves are static frameworks.... If you delete them from the
xcarchive manually, everything works as expected.
Basically many of the answers here point to the right direction, but the problem remains because the solution is to remove the unwanted artifacts every single time. Currently (Jan 2021) AFAIK there is no other way to solve it.
Scheme->Edit Scheme->Archive->Post Action->Click '+' -> New Run Script Action->
paste below code
LOGFILE="${ARCHIVE_PATH}/static-frameworks.log"
echo "Removing static frameworks from ${WRAPPER_NAME} archive" > $LOGFILE
find "${ARCHIVE_PRODUCTS_PATH}/Applications/${WRAPPER_NAME}" -name '*.framework' -print0 | while IFS= read -r -d '' fm; do
name=$(basename "${fm}" .framework)
target="${fm}/${name}"
echo "Checking: ${fm}" >> $LOGFILE
if file "${target}" | grep -q "current ar archive"; then
rm -rf "${fm}"
echo "Removed static framework: ${fm}" >> $LOGFILE
fi
done
I had a same issue. I did a couple of things and my issue went away. I believe My issue was related to Cocoapods version but you can try couple of things here.
First clean DerivedData by:
1.Turn off Xcode
2.Go to ./Users/YourFile/Library/Developer/Xcode/DerivedData
3.Delete everything from this folder
4.Run Xcode
5.Build&Clean
Second for some reason, with latest cocoa pods version 0.39, I was getting following warning when I ran pod install
[!] The MY_TARTGET target overrides the EMBEDDED_CONTENT_CONTAINS_SWIFT build setting defined in `Pods/Target Support Files/Pods/Pods.release.xcconfig'. This can lead to problems with the CocoaPods installation
I've downgraded cocoapods by removing all installed cocoapods:
sudo gem uninstall cocoapods
then install older version:
sudo gem install cocoapods -v 0.38.1
This removed the warning and I was able to remove the error, "unexpected Mach-O header code: 0x72613c21"
For me, I had Fabric binaries in my Carthage /usr/local/bin/carthage copy-frameworks run script.
After removing those, it fixed the issue.
I'm using Xcode Version 9.4.1 (9F2000)
In XCode 11, click on the project file, select your target, then on General tab expand Frameworks, Libraries, and Embedded Content, change Embed & Sign to Do Not Embed.
Edit: This looks to be fixed in Xcode 8 Beta 3.
I'm currently experiencing this issue with Xcode 8 Beta 2 and Swift 3 with pure-swift Pods (which seems to be causing the issue).
Adding the following to my Podfile has fixed the problem.
post_install do |installer|
installer.pods_project.targets.each do |target|
target.build_configurations.each do |config|
config.build_settings['ALWAYS_EMBED_SWIFT_STANDARD_LIBRARIES'] = 'NO'
end
end
end
Credit goes to this comment by YuAo on GitHub.
Take a look at this Apple documentation
Embedding Frameworks in An App go to the section Embedded Static Libraries they explain this error like this:
This is caused by placing a static library in a bundle structure that looks like a framework; this packaging is sometimes referred to by third party framework developers as a static framework. Since the binary in these situations is a static library, apps cannot embed it in the app bundle.
They also provide a way to fixed:
you can solve this error by identifying the static framework and removing it from the Embedded Binaries section.
You accomplish this by following the instructions in Inspecting A Binary's Linkage
2021! UPDATED
Here is the hack for this:
Build the app with the Pods_Runner.framework marked as Embed & Sign
Once it's built. Go to the same place and set the Pods_Runner.framework to Do Not Embed.
Go to Product -> Archive -> Submit the archive and it will all work as expected.
credits: lifenautjoe
Adding below script into Post-Actions of Archive helped me overcome this issue. It removes static-frameworks which are unrelated.
# https://github.com/firebase/firebase-ios-sdk/issues/6472
LOGFILE="${ARCHIVE_PATH}/static-frameworks.log"
echo "Removing static frameworks from ${WRAPPER_NAME} archive" > $LOGFILE
find "${ARCHIVE_PRODUCTS_PATH}/Applications/${WRAPPER_NAME}" -name '*.framework' -print0 | while IFS= read -r -d '' fm; do
name=$(basename "${fm}" .framework)
target="${fm}/${name}"
echo "Checking: ${fm}" >> $LOGFILE
if file "${target}" | grep -q "current ar archive"; then
rm -rf "${fm}"
echo "Removed static framework: ${fm}" >> $LOGFILE
fi
done
A comment from Firebase issue: https://github.com/firebase/firebase-ios-sdk/issues/6472#issuecomment-771351512
Remove them from Embedded Binaries and add them to Linked Frameworks and Libaries, then Archive again and upload to store.
In my case in xcode 11, i resovle issue to set do not embeded in genral -> frameworks,libraies and embedded content
Check and looking for duplicate frameworks and Libraries in Link Binary With Libraries and Embed Frameworks in Build Phases tab of your project.
Only should be in one side ...
I ran into this error with a FacebookSDK framework. I removed it from the Embed frameworks list in Build Phases and it solved the issue. Inspect the log and find the framework causing the error as mentioned by others.
I encountered this issue in a very simple Framework project. I only had one target in my project for the framework and it was building fine. I wanted to add some unit tests, so I added two new targets: an iOS Unit Testing Bundle target, and a Single View Application target (to act as a host app for the tests). However, both new targets were throwing this error.
I discovered that the problem was caused by the Mach-O Type build setting on the new targets being set to Static Library. Apparently the new targets were inheriting the Mach-O type from the parent Project. When I set the Mach-O Type to the correct settings ("Bundle" for unit tests and "Executable" for the host app) it all worked! I also had to clean build, delete derived data and reset the simulator to get the new settings to take.
In my case, I selected the copy when installing and worked for me
In my case it was caused by change of Developer certificate/team.
I start project with personal Dev Apple ID and by the time I changed it to my work ID.
When we try to export .xcarchive then "Match-O header" fail did appear.
Nothing described here or at other sites don't change anything.
When I change Team back to my personal ID, error logs shows missing .xcent files for only few frameworks now (most recently added). So I start whole new project, paste all the sources and files, then run cocoapod and everything works as expect.
My way of fixing this was to get back to Fabric/Crashlytics installation via Cocoapods instead of fancy Carthage setup (which appeared buggy).
I had this problem with a manually-added PFFacebookUtils framework in a Swift 2.3 non-CocoaPods project. I fixed it by removing said framework from the embedded frameworks section of the "General" page of the build target and linked it in Build Phases -> Link Binary With Libraries
Given the amount of time I've poured into finding this problem, it was caused by Cocoapods. I was working on a Workspace that had both iOS apps and a command line tool to kick off some pipelines and stuff. My file looked like this:
target 'AppPipe' do
platform :osx, '10.14'
project 'AppPipe/AppPipe.xcodeproj'
pod 'Yams'
post_install do |installer|
installer.pods_project.targets.each do |target|
target.build_configurations.each do |config|
config.build_settings['MACH_O_TYPE'] = 'staticlib'
end
end
end
end
I thought the pods_install hook was local to the scope I was writing it in, but it wasn't! It actually turned all of my target's configs into staticlibs! This fixed it:
target 'AppPipe' do
platform :osx, '10.14'
project 'AppPipe/AppPipe.xcodeproj'
pod 'Yams'
end
post_install do |installer|
installer.pods_project.targets.each do |target|
target.build_configurations.each do |config|
# Only AppPipe always gets staticlib
if target.name == 'AppPipe'
config.build_settings['MACH_O_TYPE'] = 'staticlib'
end
end
end
end
If you have an Xcode project for a static framework, your test target must have "Bundle" value for MACH_O_TYPE build setting:
When embedding bundles from library targets they may produce executables even with Mach-O Type = Bundle. So we can simply delete these executables from xcarchive (Products/Applications/APP_NAME/YourBundle.bundle/YourBundle)
Use this code as a script build-phase instead of a scheme post-build action. I found out of all the answers, this works the best:
# Fixes binary framework bug, see:
# https://developer.apple.com/documentation/xcode-release-notes/xcode-12_4-release-notes#Swift-Packages
# https://github.com/firebase/firebase-ios-sdk/issues/6472
echo "Removing static frameworks from ${TARGET_NAME}.app"
find "${BUILT_PRODUCTS_DIR}/${TARGET_NAME}.app/" -name '*.framework' -print0 | while IFS= read -r -d '' fm; do
name=$(basename "${fm}" .framework)
target="${fm}/${name}"
echo "Checking: ${fm}"
if file "${target}" | grep -q "current ar archive"; then
rm -rf "${fm}"
echo "Removed static framework: ${fm}"
fi
done
I encountered the same problem days ago, the root cause of this problem is:
** Some static libraries was wrongly embeded in the .app bundle. **
You can search .a or static .framework in the Products/*.app bundle in Xcode, and check out the project carefully, remove redundant static libraries.
One of the possible reason is nested framework.
Inspired by Golang, I recently refactored my project's code from:
App(with all the code in one target)
to ("->" means link with, ABCD means framework)
B -> C
A -> B
App -> A
App -> B
App -> C
It turns out that nested framework is not officially supported by Apple. So I had to flatten the dependency tree to:
App -> D
D -> A
D -> B
D -> C
I had same issue in Xcode 8 beta 3. I fixed it removing Fabric and Crashlytics from Linked frameworks (Project => Target => General page) (source)
Related
I added react-native-sentry to a react-native project. I followed this manual: https://docs.sentry.io/clients/react-native/
Everything worked fine on Android and ios emulator. But when I tried to archive an app in xcode I got this error.
React native symbol handling failed
The Sentry build step failed while running in the background. You can ignore this error or view details to attempt to resolve it. Ignoring it might cause your crashes not to be handled properly.
If I click 'Show Details; I get this
error: EOF while parsing a value at line 1 column 0
I followed the advice from here https://github.com/getsentry/react-native-sentry/issues/135 and edited Build Phases > Upload Debug Symbols so now there is only this line there
export SENTRY_PROPERTIES=sentry.properties
The error still persisted. So I decided to ignore it. In this case after I upload the version to Itunesconnect and install it with a TestFlight it crashes immediately on start.
If I run it on a simulator or install it directly an iphone it works fine.
It also works fine on Android.
Could you give me any advice what can be done to make it work on Apple Store too?
For me this error was signaled by Xcode because of some problems when running the build scrips.
Using:
https://github.com/getsentry/sentry-react-native
#sentry/react-native": "^1.0.9
I fixed it keeping the index.ios.js always in the root folder (before that I had it in a src folder and trying to use a custom build script to take it from src)
I set the build scripts in Xcode to be similar to the ones from sentry docs:
Build RN code and images script:
// sentry properties file located in `ios` folder
export NODE_BINARY=node
export SENTRY_PROPERTIES=sentry.properties
../node_modules/#sentry/cli/bin/sentry-cli react-native xcode \
../node_modules/react-native/scripts/react-native-xcode.sh
Upload debug symbols script:
I have this script as the last one in Build Phases
export SENTRY_PROPERTIES=sentry.properties
../node_modules/#sentry/cli/bin/sentry-cli upload-dif
"$DWARF_DSYM_FOLDER_PATH"
Note:
1) I haven't tried yet to move sentry.properties file as common for both android and iOS, placed in root folder (with import ../sentry.properties in scripts) but I think that should work too.
2) I used the terminal to test directly the release build:
react-native run-ios --configuration Release --simulator "iPhone 8"
or
react-native run-ios --configuration Release --device "Your Device Name"
In my case the reason was a space included in the name of the hard disk I use to keep the Project, Derived Data and Archives. Looks like the Sentry CLI script doesn't like spaces in the path to the project and it crashes there.
It was enough to rename the disk and update paths to Derived Data and Archives and all is well now.
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)
I'm developing an app using Xcode 6 and cocoa pods.
But it is showing an lexical or preprocessor issue:
“ReactiveCocoa/ReactiveCocoa.h” file not found.
I installed cocoa pods and also updated it. Anyone please suggest how to solve this issue.
I had a lot of trouble installing RAC my first time around, and here's what I usually go through if I'm getting CocoaPods errors :
1 : Check if the Build Active Architecture Only option is set to NO for debug builds. Go to the Pods project in your workspace, make sure Pods is selected and not one of the targets on the inner left side panel, and then search for Build Active Architecture Only and set it to NO. Try rebuilding/cleaning again after.
2 : Make sure you're passing in -all_load to Other linker flags in your target build settings. (Select project > Go to your target > Search forOther linker flags> Add-all_load`
If you want to use Yusef Napora's version of ReactiveCocoa 2 in a swift project :
-BridgingHeader.h set in build settings and containing the import to < ReactiveCocoa/ReactiveCocoa.h >
Linked Frameworks and Libraries: + libReactiveCocoa-iOS.a
Library Search Paths : + < yourPath >/ReactiveCocoaFramework/build/Debug-iphoneos
Header Search Paths : + $(BUILT_PRODUCTS_DIR)/../../include
Compile. :)
I am working on my company's continuous integration server, and the build process is failing because the server does not have access to schemes in an xcode project.
Basically, they are using Cmake to generate xcode projects on the fly to be used for a single build, and then discarded until the next check in.
My research indicates that this problem will be fixed if there is an .xcscheme file with the .xcodeproj file, but for various reasons that can't be generated and checked in ahead of time.
Is there a way to generate this file using xcodebuild or some other command line tool so that we can work it into existing build shell scripts?
The xcodebuild documentation, google, and S.O. are surprisingly lacking on this topic.
I generate the XCode project using the -G Xcode too; I'm using the scan-build plugin ( http://blog.manbolo.com/2014/04/15/automated-static-code-analysis-with-xcode-5.1-and-jenkins ) in jenkins.
It requires the workspace files.
My script to launch & watch xcode looks like that:
($WORKSPACE is set by jenkins)
#!/bin/bash
/Applications/Xcode.app/Contents/MacOS/Xcode "${WORKSPACE}/Build/arangodb.xcodeproj" &
XCODE_PID=$!
# now we wait for xcode to build the workspace:
WAIT_FOR_XCODE=0
while test ${WAIT_FOR_XCODE} -lt 6; do
WAIT_FOR_XCODE=`find "${WORKSPACE}/Build/arangodb.xcodeproj" |wc -l`
sleep 2
COUNT=`ps -p ${XCODE_PID} |wc -l`
if test ${COUNT} -lt 2; then
echo "XCode went away unexpectedly!"
exit -1
fi
done
#ok, we believe its done. kill it, and wait until its realy dead.
kill ${XCODE_PID}
COUNT=2;
while test ${COUNT} -gt 1; do
sleep 1
COUNT=`ps -p ${XCODE_PID} |wc -l`
done
Unfortunately, as of Xcode 5.1.1 there does not exist a mechanism for auto-generating .xcodeproj or .xcworkspace build schemes from the command line as the Xcode UI does. The good news though is that an Xcode project's pbxproj markup is an order of magnitude more complex than the XML markup that describes a build scheme. If you've managed to get CMake to spin up a well-formed Xcode project on-commit, then using a very similar procedure you can build out the 100 or so lines of XML that describe the build-run-test-profile-archive actions of that Xcode project.
If you've not taken a peek at the underlying XML structure of a scheme, create a sample iOS project from the new project wizards and then go poking through the contents of the .xcodeproj or .xcworkspace file for .xcscheme files. The structure is fairly self-documenting and you might even be able to get away without actually specifying the XML markup for those actions you know that will not be run on CI.
Failing that, a less robust approach would be to looking into opening up the Xcode project/workspace file upon the completion of your CMake build process. After a handful of seconds, Xcode's indexer will have had time to identify the projects and auto-generate the schemes for the projects within the master project file itself. Obviously, as you are relying on a UI-layer operation in this approach, you are subject to Xcode's whims, and the indexer may take more than a few seconds to build its index (ex. larger projects will take longer to auto-generate schemes!) ...and there is no trigger advising command-line processes that the indexing and generation has succeeded or failed. You'd wind up having to poll for the existence of a file with an appropriate timeout which can get a bit dicey in an automated build and test environment.
I was actually able to do this by using cmake to generate the project, then using the xcode gui to make the scheme files I need. I used the terminal to extract the xcscheme files from the project and put them in another directory being tracked by source control. As part of the generation process, I just added a bit of shell script to copy the copies I made earlier into the newly generated project, then continue the build process as normal.
The latest version of cmake has added this functionality:
https://blog.kitware.com/cmake-3-9-0-rc3-is-now-ready-for-testing/
The "Xcode" generator learned to create Xcode schema files. This
is an experimental feature and can be activated by setting the
"CMAKE_XCODE_GENERATE_SCHEME" variable to a "TRUE" value.
For CMake based project use XCODE_GENERATE_SCHEME setting for your target.
Setting:
set_target_properties(<your_target> PROPERTIES
XCODE_GENERATE_SCHEME YES
)
will produce following file
your_project.xcodeproj/xcshareddata/xcschemes/your_target.xcscheme
I am a Xcode beginner, and am facing some problems in compiling an OCMock test. I have added the OCMock.framework in "Groups & Files", and then added a very basic OCMock test from the Unit testing target, basically for Canary testing.
When I compile the OCMockTests.m file, the system returns around 38 errors pointing out all the imported headers that is in OCMock.Framework files to be non-existent, and in the top comes "Foundation/Foundation.h : No such file or directory". But when I compile the OCMock.Framework, then everything succeeds. I tried replacing Foundation.h with NSObject.h, but the system is not even able to find that.
I reckon it is some linker error....the system is somehow probably not able to get the location of Sentest.Framework. BTW, I have updated the Executable info - environment variable - DYLD_FALLBACK_FRAMEWORK_PATH with the correct (?) Sentest framework path (the argument is "-Sentest All"), that is of the IphoneOS folder.
Need your advices...thanks a bunch.
~ Sayan
See Colin Barrett's "OCMock and the iPhone" tutorial.