I am working on a Swift package command line tool that has a third-party dependency. It has been working great just opening the repo folder and using SwiftPM, except that I don't seem to have control over the default file header. In other projects that have used an .xcodeproj or .xcworkspace, I was able to control this using the steps outlined here:
https://medium.com/#silmy/how-to-easily-change-your-file-header-text-in-xcode-347fa77d76f4
Putting the Plist in the Xcode data directory isn't what I want since the header could be different for different projects, and in any event I want to commit it to the repo so anyone who might contribute files to the project will use the same header.
We have tried simply creating an Xcodeproj or Xcworkspace using CocoaPods or Carthage, and have run into extremely frustrating issues. CocoaPods says that command line tools can't use third party dependencies, which seems untrue since it works fine when running purely in SwiftPM, and Carthage just completely fails to run correctly on my machine.
Does anyone know a way to set the default file header using SwiftPM in a way that can be committed to the repo and not require other dependency managers?
I have an Xcode project using Xcode 8. I am using Swift if that helps/matters.
A few days ago after really not changing that much except a few funcs in one VC I tried to rerun my app and it had an error (I can't remember what it said unfortunately...but when I google'd it said basically that there was a file missing)
I located what the files were and just copied all changes into a blank project and deleted the file and pulled from Github a clean version and re adde the few funcs I added.
Everything was great and nice, until yesterday I noticed 2 yellow warnings.
I clicked the "Issue Navigator" and it is saying
TestApp project missing file
TestApp.debug.xcconfig is missing
Pods project missing file
pods - TestAPP.debug.xcconfig is missing
I realize that files just don't randomly disappear, but honestly I did not touch anything other than the Storyboard and the one ViewController File I am working on.
Why does Xcode keep deleting my files?
Is this project savable or do I need to start it over (is it corrupt?)
My project also is using Firebase.
xcconfig files are used to separate out build configuration information. Those errors are showing that you're missing entries corresponding to a debug build.
Nothing should be touching them. Only three possibilities come to mind:
You didn't create debug configs in the first place, but have tried to use them somehow.
Your path configurations are placing these in a directory that's getting wiped out when you clean/rebuild your app.
The project directory is under git control and you're doing something with git that removes the files.
Here's a screenshot showing I have two configs under my Pods project, one for "release" and one for "debug".
You might try setting up your project and making sure you see the debug configs listed. If so, see where they're kept and so on to diagnose what's going on. Otherwise, you just haven't created them.
My guess is that the files are not actually missing in any serious way. It's a bug related to use of git (as you say, the files came thru GitHub, so we know the project is tracked thru a git repository). The files were removed, but this is in fact not a problem. If that's right, then, as I explain at https://stackoverflow.com/a/39715083/341994, you can solve this simply by doing a git add or git commit of these files. That will cause Xcode to become happy and the warnings will go away.
I have a curios issue.
I have a project that I've worked on and always built from the XCode IDE, and it worked fine. Now I'm setting up Bamboo to build the project and as such am building it from the command line.
The issue is, if I check my code out of GIT and then use xcodebuild to build it it says that the scheme cannot be found, but if I open the project, it builds and if I then try to build it again from the command line with the same command, it works.
What magic is XCode doing when I open the project or am I doing something dumb, maybe excluding a file in my .gitignore that I shouldn't?
You are definitely on the right track with respect to the .xcscheme file -- I had this problem appear while setting up my own projects!
For posterity, or at least anyone getting here from a search, here are two versions of things -- the "I'm busy, so just the facts please" version and a more involved discussion and rationale. Both of these versions assume you are trying to build from a Workspace file; if you aren't then my apologies as this mostly applicable to workspace-based projects.
Condensed 'Fix-it' Version
The root cause is that the default behavior of Schemes is to keep schemes 'private' until they are specifically marked as shared. In the case of a command-line initiated build, the Xcode UI never runs and the xcoderun tool doesn't have its own cache of Schemes to work with. The goal is to generate, share, and commit the scheme you want Bamboo to run:
On a clean working copy of the code, open your Project's workspace.
Choose Scheme > Manage Schemes... from the Product Menu.
The list of Schemes defined for the project appears.
Locate the Scheme Bamboo is trying to run
Ensure the 'Shared' box is checked for that scheme and that the 'Container' setting is set to the Workspace and not the project file itself.
Click 'OK' to dismiss the Manage Schemes sheet.
A new .xcscheme file has been created in your project at WorkspaceName.xcworkspace/xcshareddata/xcschemes.
Commit this file to your repository and run a Bamboo build.
Deeper Discussion and Rationale
Xcode 4 introduced Workspaces and Schemes as a way to help try and tame some of the chaos that is inherent to dealing with the mechanics of wiring related Xcode projects, build targets, and build configurations together. The workspace itself has its own set of configuration data that describes each of the smaller 'boxes' of data it contains and acts as a skeleton for attaching .xcodeproj files and a set of shared configuration data that gets mirrored to each developer machine or CI system. This is both the power and pitfall of Workspaces -- there are 1) lots of ways in which one can get things configured 100% correctly, but put into the wrong container or 2) put into the correct container, but configured improperly thus rendering data inaccessible by other parts of the system!
The default behavior of Xcode 4 schemes is to automatically generate new schemes as projects are added to the Workspace file. Those of you that have added several .xcodeproj files may have noticed that your scheme list quickly becomes unruly especially as project files are added, then removed, and then readded to the same workspace. All schemes, autogenerated or manually created, default to being 'private' schemes visible only to the current user even when .xcuserdata files are committed with the project's data and configuration. This is the root cause of that cryptic build error Bamboo reports from xcodebuild -- Because Bamboo operates the build through the command line and not the Xcode UI, it doesn't have an opportunity for Schemes to get automatically generated and relies only on those that are defined in the workspace itself. Assuming you've configured Bamboo to build from a workspace using a command like this:
xcodebuild -workspace MyWorkspace.xcworkspace -scheme MyApplication -configuration Debug
xcodebuild goes looking for file <'scheme' Parameter Value>.xcscheme existing at <'workspace' Parameter Value>/xcshareddata/xcschemes.
Obviously there are bunches of ways in which one could configure both Bamboo and a workspace, so keep in mind that your unique configuration may not map 100% to what is presented here. The key takeaways:
Certain automated tasks the Xcode UI magically takes care of are not available via the Xcodebuild CLI.
You can attach scheme and build configuration data to many places in the 'container hierarchy' -- Make sure your data winds up in the right container (Workspace, Project, and/or Build Target)
Consider where in the container hierarchy the xcodebuild tool may be looking for configuration data; a great indicator of where it will start looking is based on the use of '-workspace' or '-project' arguments.
The 'Shared' box is already checked...now what?
I encountered this same issue on my own Bamboo instance; it turned out that the scheme that was committed in my repository was outdated and the latest version of the command line tools wasn't handling it gracefully. Since this existed previously, I took a look through the settings to make sure there wasn't anything glaringly custom about the scheme, deleted and recreated the scheme ensuring that I marked it as 'Shared', and recommitting the new .xcscheme file to the repository.
If everything looks good and rebuilding it doesn't solve the issue, double check that container setting -- it is really easy to get that scheme attached to the wrong container in the hierarchy!
Debug the issue like this:
xcodebuild -list
or if you are using a workspace (e.g. with pods)
xcodebuild -workspace MyProject.xcworkspace -list
If you scheme is not listed fix like so:
Most of the answers would suggest you to make your scheme shared using Xcode, then commit changes to repo. That works, of course, but only if you have access to source code and have rights to commit changes, and couple of other assumptions.
But there's a number of "what ifs" to consider
What if you just can't modify the Xcode project for some reason?
What if you create a new scheme automatically on CI server? This actually happens quite often. If you use test automation framework, like Calabash, you'll normally end up duplicating an existing target, which automatically duplicates a scheme as well, and the new scheme is not shared, even if the original scheme was.
Ruby & xcodeproj gem
I would recommend using xcodeproj Ruby gem.
This is a really cool open source tool that can help you to automate tons of Xcode-related tasks.
Btw, this is the gem used by CocoaPods to mess around with your Xcode projects and workspaces.
So install it
sudo gem install xcodeproj
Then write a simple Ruby script to re-share all the schemes, the gem has recreate_user_schemes method for that purpose
#!/usr/bin/env ruby
require 'xcodeproj'
xcproj = Xcodeproj::Project.open("MyProject.xcodeproj")
xcproj.recreate_user_schemes
xcproj.save
It doesn't just copy scheme files form user's folder to xcshareddata/xcschemes, it also creates those files first by parsing the pbxproj file.
Ok I know its 2 minutes later but I found another stack overflow that says the scheme has to be set to shared... Where does Xcode 4 store Scheme Data?
One common reason for the scheme to be missing is forgetting to push the commits to the origin. If you get a missing scheme message, you should first verify the scheme is shared, then verify you have committed the changes AND pushed them to the origin server.
I had this error while implementing CI.The Question above is identical to my problems except I am using Gitlab's own CI tool.You can check if there is any such file in Bamboo.
I solved it by making some changes to gitlab-ci.yml file.
After you hav made your scheme availabe by sharing. In Xcode Go to Products>Scheme>Manage Scheme and check share to share.
Changes
Set absolute path everywhere.
eg.xcodebuild clean archive -archivePath /path/to/your/project/build/testDemo -scheme testDemo | xcpretty
here you need to change /path/to/your/project/ with your path and testDemo with your project name.
I faced this issue and even if some of the answers here actually provide the solution, I didn't find it very clear. So I will just add one more. In a nutshell how to share a schema from excode.
Navigate to Product > Scheme > Manage Schemes
You will then be shown a list of schemes, with each denoted as being shared or not. Just check the ones that you want to share (it may be different ones for dev and prod builds)
Images taken from this article https://developer.nevercode.io/docs/sharing-ios-project-schemes
Got the same problem but during building with xcode as subproject of main one. Built subproject in xcode standalone - after that this error disappeared.
I want to add solution for my case related to this thread. This one is for you who clone existing project, with all the schemes you need are already being shared:
, with fastlane lanes correctly display all your lanes including all your schemes:
, but fastlane gym only show main schemes (not dev and test schemes):
The solution is to uncheck the shared option for schemes that not listed by fastlane gym and then check it again. It will generates .xcscheme for the schemes:
Now, if you check with fastlane gym, all the schemes will be listed:
Then you should commit those .xcshemes file to the repository, so other developer who clone the project will get the files.
For anyone with Xcode 11.4 trying to find "Shared" button on scheme, it's now moved into the individual scheme.
Select the scheme you want
Press "Edit"
Check the "Shared" box
We have a C++ project which is built using CMake (2.8.7) and versioned with Git. Two of our developers (DevA and DevB) use XCode 4.2. They can generate an XCode project using CMake's -G Xcode feature, no problem, and push/pull/commit changes through the IDE. The problem starts when the project gets restructured. If DevA adds a few files and commits/pushes, DevB can pull the changes (they are visible in the file system), but they won't be reflected in the XCode project setup. We thought that maybe putting the *.pbxproj file under version control could solve this; however, the file is full of absolute paths. So far the only "solution" we could find was to re-create the XCode project by running CMake -G Xcode every time the source tree gets reorganised, which is very tedious. Is there a simpler way? Thanks.
CMake registered a ZERO_CHECK target as the dependency for every "real" target in Xcode, its sole responsibility is to rerun CMake in "CMakeScripts/ReRunCMake.make" and update the Xcode artifacts if one of the CMakeLists.txt files was changed. If you do not see the changes reflected in Xcode, it is because Xcode won't watch its .xcodeproj directory for changes. The pragmatic solution is to close the project in Xcode and reopen it. At which point you could rerun "cmake -G Xcode .." anyway.
The same applies to Visual Studio 10 as well, except that it will ask you for every target whether you want to reload it. It works fine for smaller changes but not for adding / removing files.
I can live with it, as there is a point in a projects life, when the set of source files is not really changing anymore. At least that's my experience.
I have an xcode project that was created on another mac. That make was PROBABLY osx 10.5 using Xcode 3. (When I went to install xcode I could only get Xcode 4 AND was required to upgrade my mac to 10.6) anyway, I am experiencing problems compiling this project that compiles fine on the other computer.
I don't know why. The build always fails and I see it is looking for a path incorrectly.
The physical directory layout is like this
/path/devfolder/devfolderMainProject/mainproject.xcodeproj
/path/devfolder/helpinglibrary/helpinglibrary.xcodeproj
/path/devfolder/anotherlibrary/anotherlibrariesFiles/...
But when Xcode starts doing the stuff for the helping library, it returns linker errors and I can see it is looking for files in the wrong places
linker error /path/devfolder/helpinglibrary/../../anotherlibrary/anotherlibrariesFiles/src/correctfile.cpp does not exist
so I browse and see that the file definitely does exist, and that Xcode is looking too many directory up
../../
should just be
../
so that it only goes 1 directory up, how do I make it look in the right place?
Moving the folders around in finder breaks plenty of OTHER things, so I am not sure what to do here.
I suggest you to open the target properties. In the "Build" tab, look for the settings OTHER_LDFLAGS and LIBRARY_SEARCH_PATH. I have a project with a structure just identical to your one and I have edited these properties to inform the Xcode where to look for my libraries. Maybe you can have some wrong value in some of these settings.