I'm having an annoying issue with Xcode 5 and the shared schemes.
In my team (we're just two, but hey! it's still a team) we're sharing some Schemes to run the app with different configurations (Debug, QA, Release, ...)
Well now Xcode 5 seems to change the BlueprintIdentifier setting of each scheme based, from what I can understand, on the machine of the developer. And of course the change get's noticed bit git and we either have to checkout them, or commit. Both solution don't make sense...
Any idea on how to fix it? I did a google search but found nothing for Xcode 5...
I don't want to give up on those shared configurations! A solution I can came up with to keep having the shared Schemes tracked is unshared them, copy them in a dedicated test folder, then using a strategy like the one used for the Pods to copy those schemes locally, where Xcode can mess up with them without us noticing. Something like a schemes script that reads a Schemefile file which lists the schemes to copy from the Schemes/ folder, and a Schemefile.lock that is updated every time there's some change and that is read by the Xcode build process in order to make sure everything is up-to-date.
This seems a lot of work for such a tiny thing, so before jumping head down into it I would like to know if anyone has some better solution to propose.
Cheers :)
First, I'm assuming you're using CocoaPods because you mentioned it in your question.
I've had this issue for a while and just recently discovered that some of my shared schemes are not getting their BlueprintIdentifier changed with the others. Upon investigation, I noticed that the untouched schemes had a Pods target under builds that was missing–as in it was listed in red like this: Pods (missing). My theory is that pod install and various Xcode events (i.e. crashing, launching, etc) were causing the scheme to change its BlueprintIdentifiers because they had a reference to a Pod target in the scheme build settings.
I removed the Pods reference in all of my schemes and have not been able to reproduce the BlueprintIdentifierchange since. My target that depends on Pods has libPods.a specified under Link Binary With Libraries in Build Phases and set to required, so it still gets compiled before the main target.
Note that switching between branches with this change and without this change might still produce modifications to the scheme files.
#Wes's answer didn't specifically fix this issue for me, but it did lead me to the right place. The solution for me was to turn "Find Implicit Dependencies" from "off" (unchecked) to "on" (checked) from the Edit Scheme screen for the Scheme that keeps changing.
Related
thanks for taking a look.
I had bought the cheapest Mac Mini I could so that I could do some iOS dev, and my project has outgrown it. So I bought a MacBook Pro! It's awesome, uploading my parse cloud code took 15-20 minutes on the mini, and is instantaneous on the MBP.
However, I'm having trouble getting my Xcode project to build. Some of my frameworks are red in the Project Navigator, and I notice that their paths are /Users/[account name]/Documents/Downloads/[framework files]. It looks like on my mini I had created references instead of copying the files into my project.
I know it's against protocol here, but I haven't attempted much out of fear of breaking something. I have tried some googling, but I haven't found any relevant info. I may just be searching the wrong stuff, so feel free to mark this as duplicate and send me on the right path.
I'm using github to host a private repo for the project. What steps should I take to properly move the necessary files into my project folder, re-push the project to github, and pull back onto the other machine?
I am not going to be working from the mini anymore, at least on this project, so if it's easier to copy the file over the the MBP, put it in the project folder, and change the reference or something similar, I can do that. And I haven't made any changes to the code on the MBP, just worked on resetting up signing identities / provisioning profiles. I can always pull the project again if something gets mucked up there, but I'm nervous about changing stuff on the mini, breaking stuff, and not being able to build out my project at all.
Any tips on moving forward before I try stuff myself? Again, sorry that this breaks protocol for posting, I just want to avoid breaking my project... this isn't something a simple undo could fix, and I can't risk losing the entire project because of something stupid.
I would do this:
make sure all your projects are in source code control and committed -- good practice.
backup MacBook Pro (time machine), just in case.
copy the external dependencies over to new MacBook Pro in a way that makes sense.
one by one, delete the red frameworks and re-add them to the projects. Your choice as to copy vs reference.
Afterwards, I'd consider migration to something like Cocoapods for management of dependencies. I say consider because that's exactly the state I'm in - considering this option.
This should move you forward fairly safely. Best of luck!
I'm programming in xcode (actually Phone Gap in conjunction with xcode) with git. I'm having a strange issue. When I create two identical branches and try to check out back and fourth between them with out making any changes git is telling me that I need to commit because a change has been made (this same thing is also resulting in merge conflicts). It says the changed file is:
platforms/ios/Butterfli.xcodeproj/project.xcworkspace/xcuserdata/benpearce.xcuserdatad/UserInterfaceState.xcuserstate
Can anyone explain what's going on and how to deal with it.
Yes, .xcworkspaces are simply files that Xcode uses to describe the workspace or projects.
IMHO, There's no need to check these files in at all, unless you share settings with other folks in your projects (and in your case, I suppose other machines that have a user named "benpearce").
In fact, you can safely add them to your .gitignore file.
More info can be seen here
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
I don't recall having this problem before I migrated to my Retina MacBook Pro, but since doing so, my projects have insisted on loading in the "old" development location. In years past, before XCode 4, we put all our products in /Development/Products. And, after migrating to the new MacBook Pro, they're going back there again. I can use 4.3 or newer and see the same problem with both, so I'm assuming it's some kind of configurable that's at work here.
Of course, the first thing I did was verify that the Preferences/Locations was set to Build Location = Unique. I confirmed this both in the GUI and by popping open the .plist to check the value of IDEBuildLocationStyle and it was set to Unique.
I tried removing my existing configuration files (everthing in ~/Library/Preferences/ named Xcode) and that succeeded in changing the behavior to putting the output in the build directory of the project itself (really not helpful in my world as I have complex multi-project workspaces). Quitting and checking the settings, they were set for IDEBuildLocationStyle=Unique.
So, I copied the working configuration from another machine I had to this one. Since it too had previously had the /Development/Products destination, but had subsequently been moved to the Unique build style, I expected that to work. It did not. It instead returned the output to /Development/Products.
Thinking it might be something with my Xcode install, I created a new user and built from the same source tree (not a duplicate, not a copy, the exact same files). In this case, the output went to the right place (unique subdirectory of the Derived Products for that user). So, I blew away the ~/Preferences/*Xcode* again and copied in the preferences from the new user. Unfortunately, this took us back to the same behavior that the uninitialized configuration had, which is to say building in the build directory of the project itself.
I restored to my backup configuration files, and now I'm back to working at /Development/Products, but this isn't a good long term solution.
When checking the script output for a test script, I can clearly see that somebody is setting SYMROOT to /Development/Products in the case of the older config, and build in the case of the default configuration file.
Clearly there's something here on this system that's influencing the configuration, but I cannot figure out what it is. Any assistance would be highly appreciated!
Also - When I try to use option-Clean to enable Clean Build Folder, it is never enabled, which makes a certain kind of sense, but I thought it might be another data point.
I tried the solution in Strange behavior of Xcode Build Products Path under Build Locations and that had the same result as deleting the preferences: build products as children of the project directory.
Has anyone else seen such a problem? Have you found a solution?
Well, after a very long time of suffering through this on my laptop, I was finally able to track down the problem.
Inside of:
project.xcworkspace/xcuserdata/<user>.xcuserdatad/
there is a WorkspaceSettings.xcsettings file.
It contained a key BuildLocationStyle, which was set to UseTargetSettings.
Deleting the file and thus resetting this value allowed me to get both the Clean Build Folder... working and to get my project building correctly.
Hopefully this will help somebody else.
Every once in awhile, the solution to an aggravating problem in XCode is to hit Product → Clean, and this seems to clear some cache and problems disappear.
But what is it actually doing? And more importantly, WHEN should I be doing this? It seems to be necessary more often when dealing with Core Data, but I haven't really been tracking it.
As a side question, WHY is this necessary? XCode seems to do a lot of stuff in the background (autosave, autocompile, etc). Why doesn't this also just happen in the background?
It's because there are a lot difference when you are working with a very very big project with a lot of files and objects. Imagine that you need an hour to recompile a entire project, so you will think before do this. But in our world, this is a fast task.
XCode use the make program. So, it compile only what was changed.
I can list same cases you need do this:
Always you will create a App for App Store. This safety thing to do.
Always you use the XCode Snapshot. I have bad time when I restore a project and build the app. XCode used old compiled files and a lot of time was lost to search it.
Maybe when you restore a old code with git. Is the same idea of the Snapshot
When you delete or rename a file in project. It don't delete the compiled file, so the program can work, but if you recompile, will see the errors.
When you see that sometime the build have a strange behavior. Or only to have certain that XCode use only your newer files.
I don't remember exactly but i have seen the build use old #defines. Rebuilding can make you more safe about your program. But don't need do this all time.
I am almost certain that XCode loses track of things and sometimes it doesn't recompile (or link, not sure) everything is needed. I have to resort to clean and build all most often than it should. Maybe it's just me, but I doubt it... XCode is the IDE with most bugs I have worked with