[!] The `SampleUITests [Prod]` target overrides the `ALWAYS_EMBED_SWIFT_STANDARD_LIBRARIES`
build setting defined in `Pods/Target Support Files/Pods-Sample-SampleUITests/Pods-Sample-SampleUITests.prod.xcconfig'.
This can lead to problems with the CocoaPods installation
- Use the `$(inherited)` flag, or
- Remove the build settings from the target.
I am getting the above warning when i try to create a new xcode project and add cocoa pods into the project. I already tried the solutions mentioned in What's ALWAYS_EMBED_SWIFT_STANDARD_LIBRARIES with CocoaPods, Swift 3 and Xcode 8 but nothing worked for me.
In some Xcode versions(in my case 12.2), when we create a new project with tests included, Xcode sets the "Always Embed Swift Standard Libraries" for tests and UITests to Yes and it would be shown in Bold text, which indicates its overridden
To confirm this,
check in your project's build settings and target's build settings if the "Always Embed Swift Standard Libraries" setting has been modified by Xcode.
Typically it should appear like this in Normal text (not bold) meaning its not modified.
Non modified build setting
Certain versions of Xcode modifies this setting and hence it would appear in Bold text
modified build setting
To resolve this,
Go to the project's Pbxproj file (open in VSCode or any editor)
Search and remove all mentions
of ALWAYS_EMBED_SWIFT_STANDARD_LIBRARIES
On doing so, the project
would take default settings for
ALWAYS_EMBED_SWIFT_STANDARD_LIBRARIES.
Try pod install/pod update now and the build setting warning should no longer occur.
I am working with multiple targets in Xcode 8.2, Everything is good except handling files.
To import files, I have used different pch for each target but facing issues in using different class files.
How to work with other target files in the source, it throws an error on build app. When I try to add Preprocessor Macros in Build Settings but I can't find the Preprocessor Macros section in Xcode 8. Is there any alternative to this? please suggest some other approaches to handle different target files in the same source.
Thanks in Advance.
Select the target and go to build setting.
There search for "Preprocessor Macros" you will be able to find out.
Set the macros for particular target.
Use #ifdef in the code to check whether macros is defined or not, based on macros definition write the code for specific target.
That particular code will be reflected to that target only.
If I create a new project in Xcode 7.3 the "Preprocessor Macros" setting only appears for the project. It doesn't appear in the build settings for any of the targets in my project.
How do you create a preprocessor macro for a target only in a project in Xcode 7.3?
When you use the default view in Xcode (Basic), you only see a list of settings that are changed. When you create a new scheme, you have few (or no, can't remember) changed settings, and consequently wouldn't see the Preprocessor Macros region. Change your view to Advanced, and everything should become visible.
I think you can alternatively search the name directly, and that should pull it up too. I can't remember offhand, though, and I'm not at my Mac at the moment.
Created a blank framework in Xcode 6.1 for the Swift language and got this build warning.
warning: PRODUCT_MODULE_NAME may not be overridden for framework target 'MyFramework'
It turns out I had added the build setting "Product Module Name" at the project level and this was overriding the product module name to my new framework. I have 4 targets: a production, a staging, and 2 test targets, and I didn't want to deal with 4 different bridging headers and generated headers for Swift code.
The answer was to explicitly enter a "Product Module Name" build setting for my new framework target using the correct framework name. The alternative would have been to not use a project level build setting and add it as a target level build setting for every target.
In case someone stumbles across this problem the same way I did with Xcode 9.2, my problem was that I set the override on PRODUCT_MODULE_NAME. The setting you want to change is PRODUCT_NAME (the former derives from the latter by default).
Xcode 10.0. During development sometimes I have to change Build System in
File -> Workspace Settings... -> Build System -> New Build System(Default) fixed this problem
I have set up an XCode 5 iOS 7 project for unit tests.
Of course, setting up the unit tests are taking me so long that I'm trying to keep the faith that it's worth it. Struggling for hours over this error:
ld: building for iOS Simulator, but linking against dylib built for MacOSX file
'/Applications/Xcode5-DP5.app/Contents/Developer/Library/Frameworks/XCTest.framework/XCTest'
for architecture i386
Any ideas on how to solve?
Check your Framework Search Paths in your test target settings. These can be corrupted when adding the XCTest Framework.
Adding XCTest to one of my projects prepended a "/" to the paths causing them to not find the correct version.
None of the above answers worked for me. I did find an answer here in a comment left by Tim Macfarlane.
For linker errors looking for a class in your app...
set the “Symbols Hidden by Default” build setting to “NO” in your app
target. This makes all your app classes available to your test target
automatically...
So, that means:
Project Navigator > Select your project
Targets > Select your App (not Tests)
Build Settings > Search for "Symbols Hidden By Default"
"Symbols Hidden By Default" > Change it from "YES" to "NO"
I had the same issue; the problem (for me, at least) was that the FRAMEWORKS_SEARCH_PATHS build setting listed the SDK frameworks folder after the main developer frameworks folder.
The frameworks included with Xcode have three separate builds: one for OS X, one for iOS (device), and a third for the iOS Simulator. The OS X build is in the main developer folder, with the other two being under their respective platform folders. The rub here is that if you don't specify to search the SDK folders first (which are within the platform folders), Xcode (or more correctly, the linker) will find the OS X build first and produce the error you see.
The solution is simple, put:
FRAMEWORK_SEARCH_PATHS = $(SDKROOT)/Developer/Library/Frameworks $(inherited)
in your build settings. If you're putting build settings in the project file (I don't recommend it, but that's another question for another day), it's just named "Framework search paths."
NOTE: Sometimes Xcode's a little slow to catch on; you'll probably need to delete your build folder (better than just a clean) for this to take effect.
Have the same problem after converting tests from SenTestCase to XCTestCase. Reverting framework dirs fixed issue:
"$(SDKROOT)/Developer/Library/Frameworks" (non-recursive)
"$(DEVELOPER_LIBRARY_DIR)/Frameworks" (non-recursive)
So, for me, what I was missing after trying everything else in this post, was:
Other Linker Flags:
-framework XCTest
I'm currently using Xcode 6.0 (with the iOS 8 SDK) so I'm surprised that the "Edit > Refactor > Convert to XCTest..." option doesn't add this automatically.
I was facing problem while adding sentestingkit framework in xcode 5 . These settings worked for resolving linker problem.
I had this problem upon adding another file for tests.
If you do this with (CMD + N) be sure to only target
the Test Bundle (ie. 'AppNameTests').
I guess only these .xctest bundles have access to the
XCTest Framework.
I had the same issue after renaming my Target name and moving things around. It turned out that my tests were part of my Main Target. Make sure that you all your test files belong only to your test target.
Just select a .m file, make sure you have the right pane open.
I had the same problem when tried to build XCTTest-based unit tests with pre-7.0 SDK. When I chose 7.0 as my Base SDK then that kind of link error disappeared.
Had a the same issue but ended up with a slightly different solution.
select XCTest.framework and make sure that only your test folder is checked under Target Membership.
Make sure that the Search Framework Path (FRAMEWORK_SEARCH_PATHS) for the YourProjectTests target includes the path $(SDKROOT)/Developer/Library/Frameworks, and that this one is listed before $(inherited).
In my case, both paths were present, but $(inherited) was the first one.
Credit goes to https://stackoverflow.com/users/181947/brian-clear on Apple Mach-O linker (id) warning : building for MacOSX, but linking against dylib built for iOS