My project uses Xcode 11.3.1 and is structured as followed:
MyProject
- MyProject.xcworkscapce
- MyFramework
- MyApp
-MyApp (main-target)
-MyAppUITests (uiTest-target)
MyApp imports MyFramework and can be built und run just fine. For this to work I added MyFramework to main-target into main-targets General/Frameworks and Libraries.
In my UITest target I need to access some classes (Accessibility-Identifier-Definitions) from MyFramework, so I need to import these somehow.
Both targets are building and the main-target works without any issues. I am also able to run ui-tests on a simulator. Unfortunately I am forced to run my tests on real devices, and here I get this runtime error:
The bundle “MyAppUITests” couldn’t be loaded because it is damaged or missing necessary resources. Try reinstalling the bundle.
(dlopen_preflight(/var/containers/Bundle/Application/E581B3BA-A9A2-4AA3-A1BA-91C57DCD3846/MyAppUITests-Runner.app/PlugIns/MyAppUITests.xctest/FHCommunityUITests): Library not loaded: #rpath/MyFramework.framework/MyFramework
Referenced from: /var/containers/Bundle/Application/E581B3BA-A9A2-4AA3-A1BA-91C57DCD3846/MyAppUITests-Runner.app/PlugIns/MyAppUITests.xctest/MyAppUITests
Reason: image not found)
I am fairly new to this framework-thing (and also to ui-tests) and it's been two days I am dealing with this issue now. Most posts about similar issues are related to misspecified Podfiles, but in my barebone sample project which I setup to not destroy my real project I am not using any Pods. I tried probably all of the suggested solutions (and almost all combinations :() and none of them seem to work.
It took me a while to figure out that in my uiTest-target build phases I can actually add a New Run Script Phase and I assume I need to somehow link MyFramework here.
Is this correct? Can someone help me defining the run script?
And yes, I tried to clean my app (and I also deleted derived data).
Help is highly appreciated. Thank you!
Ok, finally I figured it out. The solution is fairly simple and I haven't seen anyone suggesting this. Here we go:
To use your custom framework in your app target simply add it under Frameworks, Libraries, and Embedded Content:
Now you can access MyFramework from the main target.
I could also run my ui-tests from the simulator, but still got the error described above when executing my ui-tests from my real devices.
To get rid of the The bundle “xxxUITests” couldn’t be loaded because it is damaged or missing necessary resources. Try reinstalling the bundle.-Error I had to go to my uiTest-target and link the framework in my build phases.
As Destination choose Frameworks and select the Framework you want to use in your uiTest-target.
Now you should be able to run your ui-Test from your device.
I have been experiencing a troubling problem lately that has to do with the running of tests on a project which has a cocoapods dependency to a framework which crashed at runtime with error:
Library not loaded: #rpath/libswiftSwiftOnoneSupport.dylib
Referenced from: MyCocoapodsDependency
There are other stackoverflow topics out there about that particular problem but none of them address root cause (for example here), which is that during the "Copy swift standard libraries" step of the test build, the missing library is not copied over.
It looks like this (this is the build log when I build the tests):
When it should look like this (this is the build log for a test app that uses the exact same dependencies):
OnOneSupport seems to have to do with with a project setting that has to do with "Whole module optimization".
But even if I change to "not onOne" it doesn't make a difference. The dylib is referred to in https://github.com/apple/swift/blob/master/cmake/modules/AddSwift.cmake
I cannot for the life of me figure out why it's omitted from the standard libraries build step for one target and not for another, but its obvious that my tests needs it. Anybody know how I can force the compiler to include SwiftOnoneSupport?
Workaround
Add a build phase to the test target (in the project file) that copies libswiftSwiftOnoneSupport.dylib to Frameworks. The dylib can be found at:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/bitcode_strip /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift/iphonesimulator/libswiftSwiftOnoneSupport.dylib
I also had this same issue with two of my frameworks. The strangest thing was that everything was working fine with one of them but not with the other.
While I wasn't able to figure out why this happens (since it seems to be an Xcode bug), I was able to find a pretty neat workaround.
Turns out that using print() anywhere in your code will somehow force libswiftSwiftOnoneSupport.dylib to be loaded. So, by adding something like this the problem should go away:
private func dummy() {
print("Hello world!")
}
I'm using Xcode 10.1, Swift 4.2 and the pod that was giving me this issue was Nimble.
Hope this helps!
I am getting this error:
"error: unable to spawn process (Argument list too long)
** ARCHIVE FAILED **
The following build commands failed:
CompileSwiftSources normal arm64 com.apple.xcode.tools.swift.compiler
(1 failure)
Exitcode =65 "
I went through this link:
Xcode export localization throws error "Argument list too long"
This article provides a good temporary solution of the problem stating to reduce the path hierarchy. But this does not seem to be an appropriate approach. Can anyone provide me with a different approach to the solution for this problem?
In my case, it was about custom configurations in .xcconfig files.
My config files were including Pods configurations like:
// Development.xcconfig
#include "Pods/Target Support Files/Pods-MyProject/Pods-MyProject.debug (development).xcconfig"
#include "Pods/Target Support Files/Pods-MyProjectTests/Pods-MyProjectTests.debug (development).xcconfig"
#include "Pods/Target Support Files/Pods-MyProject/Pods-MyProject.release (development).xcconfig"
#include "Pods/Target Support Files/Pods-MyProjectTests/Pods-MyProjectTests.release (development).xcconfig"
// Production.xcconfig
#include "Pods/Target Support Files/Pods-MyProject/Pods-MyProject.debug (production).xcconfig"
#include "Pods/Target Support Files/Pods-MyProjectTests/Pods-MyProjectTests.debug (production).xcconfig"
#include "Pods/Target Support Files/Pods-MyProject/Pods-MyProject.release (production).xcconfig"
#include "Pods/Target Support Files/Pods-MyProjectTests/Pods-MyProjectTests.release (production).xcconfig"
This produced the error you mentioned, when I added Firebase pods into my Podfile.
So to make this compile again I had to:
remove all inclusion (#include ...),
set them explicitly in the Project -> Info -> Configuration, as follows:
Quick tip:
If you don't want manually setting up corresponding target configurations (those with red icon), mark them as None and run pod install. This will automatically change it for you.
A few days ago I faced a similar challenge. I want to provide details and share my research with SO community.
First of all I found this thread and I followed the link in the asked question.
And yes, thats right, the answer marked in the link is correct, but the solutions to this problem did not suit me.
Problem
In my case, I had this problem when I changed the folder hierarchy in my project to be more convenient and suitable for me.
#oOEric option did not suit me, because according to the rules, the hierarchy of groups in Xcode should coincide with the hierarchy of folders in the system.
But I've already had about 1680 swift files to compiling.
The problem was that I had too long path to the compiled files and their number was too large.
Research
Then I start research and found swift jira with the same bug.
Here some links:
Main
Linked Issue 1
Linked Issue 2
Linked Issue 3
Bug on Open Radar
But here I didn't find some solutions for me.
Most of all I was pleased with this response of the swift developers.
Again, this is an Xcode-side issue, not a Swift-side issue. Commenting here won't make the Xcode engineers work any faster!
(We're not all the same people at Apple.)
Okey, after this answer, I was finally convinced that if it is an Xcode bug, then the solution should be sought in Xcode.
Solutions
Temporary solution
You need to move your project higher in the hierarchy of your system.
I choose this one, because I have really big project and the use of other solutions will require more than one day from me.
In my case, I conducted an experiment and calculated that the length of the path to the project should be no more than 50 characters.
But this is a temporary solution. If your project grows further, you will have to shorten the path or use other solutions.
Cocoa Touch Framework target
This solution is suitable for files that do not use dependencies.
First of all you need to add Cocoa Touch Framework as a target to you main project.
This target should be added automatically to Embedded Binaries and Linked Framework and Libraries.
After this you need to find some files without dependencies and change target membership to your "TestTarget".
Don't forget classes, properties, methods, enums, protocols from cocoa touch framework should have open or public access.
And don't forget clean your DerivedData folder.
Modular iOS
This solution has a more integrated approach.
If you want to use any dependencies in your Cocoa Touch Frameworks you should go to this guide and make more complex refactoring for your big project!
Link to solution
I think this is the best solution.
I hope this big answer will help someone!
I solved this by setting build system to Legacy build system
in file-> workspace setting -> select workspace setting
I solved this by reducing the hierarchy of groups in Xcode.
e.g. original files at project_name/project_name/About/Model/Text
I removed the groups "Model", "Text" and moved files under project_name/project_name/About/
I made simple script for temporary fix that problem. https://github.com/gregoryvit/flatter
It simply move all swift files in Xcode project to root group.
Error - unable to spawn process (Argument list too long)
There are many reason for this error. Some of these are mentioned below:
Your project might have many swift files (say more than 2000)
Most of the Swift source files may be deeply nested inside directories
Many of these files have absolute paths with more than 150 characters (eg. /Macintosh HD/Users/jayprakashnd/mySampleProject/Module1…)
Xcode swift complier takes the absolute paths of all source files while so compiling, the ARG_MX limit is reached and build fails.
This has been fixed in Xcode 11 wherein a flag is used to set unlimited number of swift files.
Solutions:
Switch to Xcode 11 and add USE_SWIFT_RESPONSE_FILE to YES in build settings - User Defined Section
If you cannot switch to Xcode 11 then take a new checkout of your project in Macintosh HD ▸ Users directory with folder name as minimal as possible.
Solution 2 worked for me like a charm!
It happened to me when I use Xcode 11 beta version using Live Preview. Then I solved it by restarting Xcode after that error has gone.
I have fixed this issue, moving my folder of My Xcode project to the mac root and changing my name Folder to less characters.
Terminal: cd /
Change name folder to BX (example).
xcode11
-build setting
-user-defined
-add setting: USE_SWIFT_RESPONSE_FILE
-setValue: YES
Doing this you enable xcode to have more files than is allowed. But im not sure if this always solve the problem.
I have changed build type to legacy and it also resolved problem for me, both locally and on our CI builder. For me it was caused during checking Podfile.lock and Manifest.lock. Probably this could be skipped in our pipeline since we are always installing pods on CI.
If you faced this issue on your Flutter project while building in Release mode (or Archive) check out my this answer: https://stackoverflow.com/a/61446892/5502121
Long story short:
set your build system to New Build System in File > Project Settings…
remove ios and build_ios folders
run flutter create . to init new ios module
run pod install
run flutter pub get
check your Xcode build config (it should be Release mode and General iOS Device)
and you're good to go
I have the same problem. I fix it using a temporary solution, however that work for me.
My solution is to change the Derived Data folder to a directory with a shorter path.
The Steps is as the following:
Xcode -> File -> Workspace Settings... -> Select Custom Location for Derived Data and give a shorter path as the location.
I'm trying to distribute my iOS app. I'm trying to build the archive. The app runs fine, but when I try to archive it, it tells me it can't find ".h" files that it no problem finding for Build > Run.
They are ".h" files from different projects and libraries I have included in my project.
What's going on?
I've never come across this problem when archiving, but what I can offer to you is to take a look at the accepted answer in the following thread to see if it helps you resolve the issue you are experiencing: Compile, Build or Archive problems with Xcode 4 (and dependencies)
I'm trying to produce gcd a files from an iOS Xcode 4.2 (4D199) project called CocoaTouchHax on Lion and I'm having incredible trouble. I followed the steps here and I went as far as trying to build llvm/clang from source following steps here. However I continue to get this error:
Library not loaded: #executable_path/../lib/libprofile_rt.dylib
Where am I going wrong? I've tried to use the install_name_tool to fix the executable path to no avail. Am I over analyzing something? Am I missing something simple? I put this in as a "Run Script" phase prior to linking to ensure I've updated the #executable path and I use tool to examine the file after and the name is updated:
install_name_tool -id #executable_path/Users/cliff/dev/CocoaTouchHax/build/CocoaTouchHax/Build/Products/Debug-iphonesimulator/lib/libprofile_rt.dylib build/CocoaTouchHax/Build/Products/Debug-iphonesimulator/lib/libprofile_rt.dylib
What am I doing wrong? Help!
Update
Merely adding lib profile_rt.dylib crashes my test run immediately giving the following error when anything is run:
#executable_path/../lib/libprofile_rt.dylib
So I am certain that something needs to happen or something needs to be done to the lib profile_rt.dylib prior to execution.
Another Update I tried creating a sum link to
/Developer/usr/lib
under /Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator5.0.sdk/Developer/usr
Which I believe is part of the base the path forming the current working directory when test runs. (Assuming it runs from the bin folder there.) This would, in theory, complete the relative lookup path of ../lib/libprofile_rt.dylib from that base path but it didn't work. I've tried running the install_name_tool command prior to copying the dylib in place but I still get this error:
Library not loaded: #executable_path/../lib/libprofile_rt.dylib
I don't know what I'm doing wrong. I somehow did manage to get test coverage files to emit using some combination of the above but I was not paying close enough attention and cannot reproduce the occurance. I know this can work, I just need a little more help figuring out how.
Update: In Xcode 4.3.2 (4E2002), just switch on Generate Test Coverage Files and Instrument Program Flow, the build system will link libprofile_rt for you. Xcode 4.3, and later, is a standard Mac app and the /Developer folder is gone. So, skip steps 5-7 below. You will also have to create a class file to workaround a bug in Apple's unix implementation as described here. You'll want it in the project under test.
For Xcode 4.2 (4C199) in Snow Leopard:
Create a project, say MyProduct. Check Include Unit Tests.
Once Xcode does its thing and loads the new project, you should have two targets, MyProduct and MyProductTests. Duplicate the MyProduct target.
Select the MyProduct copy target.
Go to Build Settings. Under Code Generation turn on Generate Test Coverage Files and Instrument Program Flow.
Go to Build Phases. Expand Link Binary With Libraries. Click the +. Click Add Other.... Browse to /Developer/usr/lib. Choose libprofile_rt.dylib.
Select the MyProductTests target.
Repeat steps 4 and 5 for that target.
Go to Build Settings again. Find Bundle Loader under Linking. Change the path to the MyProduct copy app. Something like $(BUILT_PRODUCTS_DIR)/MyProduct copy.app/MyProduct copy.
Change your schemes so that the tests run under the MyProduct copy scheme and not MyProduct. If you're compiling clang on your own, you can figure out the details here.
That should work. Step 8 took me hours to figure out, it's the key. If you only see gcda files in the test build directory, that's the likely issue.
On Lion you can symlink the dylib into /usr/lib to avoid that error
sudo ln -s /Developer/usr/lib/libprofile_rt.dylib /usr/lib/libprofile_rt.dylib
I cant guarantee that that wont bust something the future however. Remember that you have done it.
Create a new configuration called "Coverage" (or whatever).
In the Coverage config variant you have created go to Build Settings and...
Add -fprofile-arcs and -ftest-coverage to Other C Flags
Switch on Generate Test Coverage Files
Switch on Instrument Program Flow
In Other Linker flags add -lprofile_rt
The reason to do it this way with a config is that you can keep your normal build untouched. Also only works on Simulator. So dont try running this on device.
And from http://mattrajca.com/post/8749868513/llvm-code-coverage-and-xcode-4
Finally, open up the Intermediates/$TARGET.build/$CONFIG/$TARGET.build/Objects-normal/$ARCH subfolder. Inside, you’ll find the aforementioned gcda and gcov files
You can open that folder with CoverStory.
Note that coverage is not cumulative (unlike Coverity) so each run starts afresh. There might be a way to change that.