I am using the Jenkins Xcode plugin (https://wiki.jenkins-ci.org/display/JENKINS/Xcode+Plugin) to build an iOS application, however it hangs when running the following command on a project I have inherited from another developer:
$ /usr/bin/xcodebuild -list
It also hangs when I run this command manually from a terminal. Does anyone know what the cause may be? The warning displayed is also displayed on another project I have, but it does not hang in this case.
Running Xcode 6.1 on OS X 10.10
$ /usr/bin/xcodebuild -list
2014-11-12 04:47:21.234 xcodebuild[42642:1431240] [MT] DVTAssertions: Warning in /SourceCache/IDEFrameworks/IDEFrameworks-6604/IDEFoundation/SourceControl/Model/IDESourceControlManager.m:423
Details: Error Domain=com.apple.dt.IDESourceControlErrorDomain Code=-1 "Missing extension: public.vcs.subversion" UserInfo=0x7f9792309200 {NSLocalizedDescription=Missing extension: public.vcs.subversion}
Object: <IDESourceControlManager: 0x7f9792302860>
Method: -loadRepositories
Thread: <NSThread: 0x7f9790d2dbe0>{number = 1, name = main}
Please file a bug at http://bugreport.apple.com with this warning message and any useful information you can provide.
Information about project "DOHSmokefree":
Targets:
DOHSmokefree
DOHSmokefreeTests
Build Configurations:
Debug
Release
If no build configuration is specified and -scheme is not passed then "Release" is used.
TLDR; My solution: Mark the schemes as shared in XCode if building them from the command line as a different user, or without ever opening XCode on the build machine.
I was having this same problem, intermittently on our CI server. I came across this question. The accepted answer with the problem being an issue and fixing the SVN version did not work for me as the SVN being used on the CI server was the default SVN and it was, as mentioned, working intermittently.
What I finally noticed is that, between a working version and a non-working version the schemes were not being listed. I had recently upgraded a library on the project and that got me to thinking about the schemes. After realizing that schemes are stored locally per user, unless shared, the fix for me was to go into the scheme manager and mark the schemes as shared.
The problem apparently being that the CI server user never actually opened the project in Xcode, thus causing the list command to hang because there were no available schemes for the user to build.
The times when it had intermittently worked were times after, logged in as the CI server user, I had opened the project in Xcode to test the build process, thus creating the necessary schemes. Wiping the CI server or refactoring/adding schemes would cause the build to break until the project was reopened in Xcode in desperation.
I had a similar issue when updating to Xcode 6.1 while using a newer version of subversion on the command line.
Disabling Source Control in Xcode Preferences should do the trick.
If that isn't an option you might try replacing the subversion implementation inside Xcode as I have done, using this technique: Use SVN 1.7 in XCode 4.3+
Basically that would be the following steps:
This assumes you already have SVN 1.7 installed to /opt/subversion, you can get it from WANdisco: http://www.wandisco.com/subversion/download#osx
Now open the Terminal and get an elevated shell using sudo -s.
Then, cd to inside the XCode.app package, to where the SVN binaries are.
Make a backup directory and move the old SVN files into it
bash-3.2# mkdir bup
bash-3.2# mv svn* bup/
Lastly, symbolically link the new files into the package:
bash-3.2# ln -s /opt/subversion/bin/svn* ./
That’s it!
I have the same problem on OS X 10.10 with XCode 6.4，just close XCode's Source Control to solved this issue:
run XCode
open Menu: XCode -> Preferences...
Click "Source Control" Tab and uncheck "Enable Source Control"
Related
I have a project that runs some utility I've installed using homebrew on one of its build rules.
On my M1 mac, homebrew is installed on /opt/homebrew/bin.
I have eval "$(/opt/homebrew/bin/brew shellenv)" present in my ~/.zprofile file, but it seems like Xcode doesn't respect that (or maybe overrides it?).
When trying to evaluate the PATH variable during Xcode run script command I get the following:
PATH=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin:/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/local/bin:/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/libexec:/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/usr/bin:/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/usr/local/bin:/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin:/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/local/bin:/Applications/Xcode.app/Contents/Developer/usr/bin:/Applications/Xcode.app/Contents/Developer/usr/local/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin
For clearance, this is the phase I was running, under Build rules.
I've managed to find two workarounds that work with this issue, the first is to symlink the program you want from /opt/homebrew/bin onto /usr/local/bin (protoc in my case)
sudo ln -s /opt/homebrew/bin/protoc /usr/local/bin/protoc
The second is to add the following line to the build rule script:
eval "$(/opt/homebrew/bin/brew shellenv)"
This has the disadvantage of not working on non M1 Macs.
There is a possible, very simple solution provided by this answer.
Basically, freshly upgraded versions of XCode (for example, 13.4.1) running on Apple Silicon-powered Macs (like my M1 MacBook Pro), have components that cannot properly use/output the appropriate object files in all the output platform combinations you need.
This leads to some "interesting" issues and error message cross-overs that find "almost correct" answers on StackOverflow. Hence the many suggestions to exclude "arm64" platform and similar from the build options.
The simple answer to all of that is... to just run XCode with Rosetta enabled. Rosetta will engage with the components that miss the needed cross-platform capabilities.
Here is an example of how to enable an application to use Rosetta. You select the app icon, then go to the File menu and select "Get Info". Then click the "Open using Rosetta" checkbox.
What I’m doing is trying to make bitbucket pipline do my iOS CD, I included docker fastlanetools/fastlane image and in the steps i pull and run the docker image everything is okay and i was able to let fastlane command work by calling fastlane beta in the steps.
What’s happening is that fastlane exits with the error
Apple Generic versioning is not enabled in this project.
I followed apple documentation to enable it from xCode
from here
I changed all the targets in my project to use App Generic and still not working
In case it was this issue xcrun avgtool xcrun: error: unable to find utility "avgtool", not a developer tool or in PATH
after
sudo xcode-select -s /Applications/Xcode.app
fastlane stopped complaining
In my case it was the issue of Command Line Tools, which wasn't specified under the location tab.
Add your xcodeproj path.
Like
increment_build_number(
xcodeproj: '../XXX.xcodeproj',
build_number: number
)
I met the same problem. I searched and tried a lot of ways, but still not worked it out. A flash of inspiration came to my mind. I set a certain version via increment_version_number, it was succeeded magically. Then I tried increment_version_number again to make it automatically increment the version number. Lucky me, it worked.
I had two installations of macOS but Xcode only on one of them, after updating I lost the command line tools location. After setting that up in the preferences it worked again
What i missed was missed setting CURRENT_PROJECT_VERSION
(whz. Current Project Version) build setting, which specifies the current version of your project.
Reason:
By default, Xcode does not use any versioning system & no value for Current Project Version. So setting versioning system to Apple Generic ensures that Xcode will include all agvtool-generated version information in your project.
Reference
So make sure, your below set values for
I highly recommend using this plugin if your issue is not having argvtool accessible in CI/CD when trying to bump stuff uniformly for both IOS/Android before it does it in the macOS runner or action etc
In my case this problem appeared after I updated Xcode and my xcode-select was pointing to the missing folder.
After I executed xcode-select -s /Applications/Xcode_13_4.app Fastlane continued working as it used to before.
I'm installing Crashlytics for my iOS app. I downloaded it via their site link, and went through all the steps for integrating the frameworks, adding the run script, etc.
I was experiencing an issue, so I removed the frameworks and decided to start over and try a fresh install. But the Fabric app updated to a newer version, and now when I try to reinstall Crashlytics into my app, it doesn't give me the option to reinstall the frameworks. It goes straight from clicking "install" to the "Build your project" screen, which I cannot pass.
To help configure your project, please build it now by pressing ⌘B
I press ⌘B, it builds and nothing happens. I think the issue is because I removed the Crashlytics and Fabric frameworks from my project, but I can't see a way to add them back again. The Fabric app doesn't give me that option.
Go into Build settings of the your target.
Find "Debug Information Format".
Set this from "DWARF" in both debug and release to "DWARF with dSYM File"
Moving from Comment to Answer.
Mike from Fabric here. If you back up through the Mac app, then click on the arrow in the top-left, click on "+ New App", that will walk you through re-adding everything.
If you check the resource navigator you may see the following message:
"DEBUG_INFORMATION_FORMAT should be set to dwarf-with-dsym for all configurations. This could also be a timing issue, make sure the Fabric run script build phase is the last build phase and no other scripts have moved the dSYM from the location Xcode generated it. Unable to process eCreditWebWrapper.app.dSYM at path"
Go to Build Settings and search for "Debug Information Format". Ensure "Debug" is set to "DWARF with dSYM File".
Without the dSYM file Fabric won't work.
As for Xcode 10.2.1, the automated installation via Fabric Mac app won't work anymore. New apps cannot be added via the New App Step-by-step guide.
You have to follow the manual installation instructions. Download and add the 2 frameworks into your Xcode workspace, then add the Run Build Script phase (and related Fabric codes), then build the App. Last (very important), run the app in an actual device.
Once the App is successfully launched, the new App information will be available in the Fabric dashboard as well as the Fabric Mac App (needs to relaunch the App to see the new app).
Here are the steps:
Download the 2 frameworks
Drag to your project where your App Delegate is (make sure ticked "Copy items if needed")
Compile the project / workspace in Xcode
Add the "Run Script Phase" as instructed here; note that Xcode 10+ requires an extra configuration at Input Files
Add the required import and initialization codes in App Delegate
Add the Fabric API keys in Info.plist
Compile again
Run the App in a real device. You will see the line Crashlytics in the Xcode log. If no log appears, checks if your active scheme contains OS_ACTIVITY_MODE settings. Set it to default if the current setting is disabled.
If the Crashlytics line appears, that means the manual installation is working; you will see your App appearing at Fabric online dashboard.
I have solved this issue by the following way. Following the advise from above, I began adding a new app to crashlytics. When I reached to adding new "Run script" build phase, I just copied that text and pasted it over the previous one(created with Crashlytics).
I have also unchecked "Run script only when installing".
After this, I canceleed adding a new app and procedeed back to the UPGRADE. At this moment, building the app, can pass you to the next step and you don't get stuck on that screen anymore.
I was stucked on Build phases too.
I have also unchecked "Run script only when installing" and press again command+B and then I passed to the next step.
If the script is not running, you may have checked the "run script only when installing" in the run script section.
I hope it helps
TL;DR
Tap your scheme -> edit scheme -> set build configuration to "Release"
Explanation:
The most voted answer sounds about right, but there are situations where you just don't need crashlytics in debug builds (who wants crashes sent when you just develop and experiment with your code?). In this case you should disable crashlytics by checking debug compilation flags (out of scope of this answer) and for the first time during installation build app for release to let crashlytics know that you built app.
I had the same issue today. The problem was that i didn't have the run-script :
./Fabric.framework/run <api key>
in my project. Once i put this back in then it all worked perfectly. I also cleaned my project and deleted derived data just to be sure.
you must check that your deployment target version because of "Fabric's minimum iOS version is 6.0"
I was only able to get the Fabric app to continue the installation process after setting my build target to 'Generic iOS Device' and creating an archive from the Product > Archive menu.
Simply building the app or running it on an emulator doesn't seem to trigger the Fabric App to proceed.
If you use Xcode 10.
Project Navigator -> your project -> Targets -> Build Phases -> your Run Script for Fabric -> Input Files -> "+" (add input file) -> clear field and past this line:
$(BUILT_PRODUCTS_DIR)/$(INFOPLIST_PATH)
Be sure to remove this: $(SRCROOT)/
In the Run Script build phase there is a call:
./Crashlytics.framework/run <your_api_key_here>
Maybe you added some conditions to trigger it only on certain builds like:
releaseConfig="Release"
if [ "$releaseConfig" = "${CONFIGURATION}" ]; then
echo "Running Crashlytics"
./Crashlytics.framework/run <your_api_key_here>
fi
so that it will not just trigger on ⌘B
See https://dev.twitter.com/crashlytics/ios/advanced-setup
In my situation I was following all the steps correctly but got stuck on 'add build phase' step.
Then I just restarted fabric and all works just fine
Also there are some other possible actions:
1) Just restart Fabric, Xcode and your Mac.
2) Also if you use Cocoapods change build phase line from
./Crashlytics.framework/run [yourAPIKey]
to
"${PODS_ROOT}/Fabric/run" [yourAPIKey]
3) After building project if Fabric will stop responding just wait a while. It took about minute on my Mac.
Thanks, I solved the problem by removing folders:
~ / Library / Caches / com.crashlytics.data
~ / Library / Caches / com.crashlytics.mac
Kindly cross verify that run script you adding is to your actual target if u will add to tests target it will not proceed until you add it to actual target
None of the solutions here worked for me. The scenario for me was someone else added the Fabric framework to our project and committed it to the repo. The run script on their computer launched/triggered the Fabric Plugin, but would not launch/trigger on mine, although it did not report errors.
The solution was to create a separate project, using Cocoapods download the same version of Fabric, replace the run script in our project/repo (and the one referenced in the target's run script) with the downloaded version from Cocoapods. Rebuild and then the plugin would respond.
Comparing the two run script files, they are drastically different, but the run script from Cocoapods was not a flat text file and it was unreadable. So I'm not sure what was different between the scripts, but we somehow got different versions of the script while using the same version of Fabric.
What I did wrong was adding the script to the pods project build phase instead of the main project build phase, adding it to the main projects build phase solved the problem.
If you are duplicating the target, remove the run script from build phase and add it again to solve the issue.
If you have multiple TARGETS,
check your Schema selection is correct before you build project.
For Xcode 10. Add your app's built Info.plist location to the Build Phase's Input Files field:
$(BUILT_PRODUCTS_DIR)/$(INFOPLIST_PATH)
This solved my issue i hope this can solve others issue.
It turned out I had not enough permissions to create new project in Fabric.
Upgrading from Member to Admin resolved the issue.
In my case, removing an app from helped.
1) Remove the app from Fabric.
2) Follow all the steps again to add the app and install Crashlytics.
Nothing helped me. Now Fabric catches my archive creation. But I create the archives via fastlane's build_app.
Open Project in higher version of Xcode. This resolved my issue after waste many hours.
My Project build on Xcode 10.2 and I was running on Xcode 10.1 but when I run the same project on Xocode 11. The build was succeeded.
Try to wrap your run script variable with double quotes ""
"${PODS_ROOT}/Fabric/run"
Go to folder /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/<CURRENT_IOS_SDK>/usr/lib/ and delete all .dylib files.
It worked for me.
I am working with Xcode 6. I am creating new project & adding some files in my project, again i deleted that file with "Remove Reference" click and adding some new files according to my requirement. But when i run this App in Xcode 5 then its showing 2 warning with "Missing File" but if i run with Xcode 6 then its showing so many warning.
How Can i resolve this warning.
I share my screenshot how i deleted file.
This is my warning image
I googled but i got all answer with SVN but i am not using svn and my project also not in SVN server. So without SVN how can i resolve this.
Please help me.
Run the shell script below in your SVN repositories path:
for missingFile in $(svn status | sed -e '/^!/!d' -e 's/^!//')
do
echo $missingFile
svn rm --force $missingFile
done
I can resolve these Missing File warnings just by doing an SVN update (Source Control -> Update), typically after a Commit.
Go to Project Folder then right Click on it
then Delete the XCUserda
Xcode's source control was the culprit for 546 "missing files" warnings on any new project I created. Somehow it searches for the files of other projects I have in a remote SVN server.
In Xcode preferences, source control, I disable it entirely. Now I can create new projects without receiving missing files warnings.
Xcode's source control seems not to work so well, or at least it's not so clear about the way it does things, so I prefer external options to manage my repositories.
Having a problem when building with xcodebuild. My project/app builds fine with the Xcode - gui. It simply isn't finding/building the libcryptopp library which is part of the build process.
The error is:
clang: error: no such file or directory: '/Users/builder/repo/ioskpay/xcode-cryptopp/cryptopp/build/Release-iphoneos/libcryptopp.a'
This particular file should be derived from another project inside the main app - xcodebuild simply isn't correctly pointing at the right file folder which should be:
~/Library/Developer/Xcode/DerivedData
Any ideas?
To fix this, go to your project settings, go to Targets and select your main project target. Then go to Build phases. Under Target dependencies add the static library project.
This way, when you compile the main project, the static library subproject gets compiled before the main project and your static library will be available.
I had the same problem, but for a resource file .m
I opened target -> build phases -> Compile sources
and I found the file the compiler was tell it can't find duplicated: one with strange icon and the other with a normal icon. I simply removed the one with strange icon and it worked. ( I added the file multiple times and I had a merge conflict before that which made something wrong in the project file)
For your case I think you need to remove the lib from target dependencies list and add it again. This may work for you.
In Xcode Version 9.2 (9C40b) this happened when I drug a bunch of files into the project, some of which were duplicate. Rather than simply not adding the duplicates, it added them again and only the name, not the path.
In Target > Build Phases > Compile Sources each of the duplicates showed with no "...in" after them. Each one caused the clang error.
After removing all of the duplicates that Xcode collected, the project compiled and ran.
It makes you use the Project Navigator instead of managing your source files in the Finder. Then the Project Navigator can't replace duplicates like any decent file management system (ahem Finder). 🤨
My xCode info is:
I faced similar errors during xcode building projects (native swift, flutter, react native, native script) in which I got error messages related to clang compilar. Errors like:
clang-4.0: error: no such file or directory: '/Users/xxxxxxxx/Library/Developer/Xcode/DerivedData/xxxxxxxxxxxxxxx/Index/Data Store'
clang-4.0: error: cannot specify -o when generating multiple output files
others
Despite of errors related with DerivedData for native apps can be fixed by deleting the directory and, eventually, restart xCode and even restart the machine... in this case, you will see that after deleting the directory and start building process again, the error comes back.
Then, is the moment of checking the clang installation by running clang --version. The normal output will be something like:
as you can see the InstalledDir is incorrect for xCode. In my case, some days ago I needed to install Anaconda app (R, Python, etc) and, now, I remember that I had to install some dependencies and one of them was clang and its installation was altered.
To fix this problem (in my case that I will not need anaconda any more): (edited)
1.- Delete anaconda and all its dependencies (I recommend to use App Cleaner).
2.- Re-install xCode
After reinstalling xCode, if you type again clang --version, you'll get this:
More info at: https://github.com/flutter/flutter/issues/32457#issuecomment-496161092
Hopefully, this info helps some else.
Best
Ok so by simply adding the correct -target -configuration and -scheme parameters I got this to run correctly. However due to my running this in Jenkins for autobuild purposes it still doesn't work as I'd like - getting stuck in exactly the same place. It's odd because I have the exact same code being built in another job that isn't having this problem. There is no rhyme or reason for it at this point. I will keep shooting rubber bands at it and update when I have an answer...
Sometimes Xcode performs weird.
You have to find that static library project e.g.. "filename.a" under 'Link Binary With Libraries' in Build Phase and then remove it and add it again.
I had the same problem while I was archiving my target. I removed the library and the build succeeded.
For me it was because I had removed a package or pod. I ran pod install and it fixed it
Look for the missing file in the Xcode project i.e the files may be deleted or miss placed.
add the missing files to the xcode, then everything will work fine.
Run this command :
$ conda deactivate