Anyone who's worked with Xcode knows how finicky it can be regarding build settings, linker errors, and other generalized nonsense. Add in any dependency manager like CocoaPods, and all of a sudden you're deleting derived data nearly every time you build.
So my question is two-fold:
What exactly is Derived Data responsible for?
and
What would happen if I just dropped its use entirely, by redirecting to /dev/null?
The DerivedData folder contains all the data, well, derived from Xcode processing. This includes any build artifacts such as header maps, intermediate build steps (.o files and such), and built products (compiled code). It is the destination for any and all build logs, run logs, and test results. Finally, it contains any indexing caches used for code coloring and searching.
Basically, it'd break everything. Doing exactly what you say with /dev/null and building causes an extremely large number of issues, mainly because it is actually trying to read and write files there and can't.
Hypothetically, if it could exist without DerivedData or anything resembling it (Xcode used to heavily rely on a Build/ folder, for instance), compilation would be impossibly slow and memory hungry.
Strange behavior in Xcode related to the DerivedData, and issues fixed by the clearing of such, are mostly because cache invalidation is really hard. Like, really difficult.
Related
I'm using XCtest with XCode 6.3 to test an app of mine. I've noticed that it seems to be saving a ton of data to my /private/vars/folders/rx/ folder. If I delete my app's Derived Data these XCTest folders don't get deleted, and if I restart my computer it's still there too. Is this data safe to delete or do I need it?
I used DaisyDisk (awesome program by the way!) to take a look at my computer's memory and I see this:
So I thought I'd take a look at what was in each of these folders. When I looked, it seemed like XCTest was the culprit.
When running my tests I include a large bundle of jpgs that is around 1.7 GB. I'm working on streamlining my app testing so that I don't need the large bundle, but I'm still curious if I can safely delete some of these older folders.
Yes, they are safe to delete. This is where Xcode stores built copies of your applications when built in "Unit Test" mode. Just as Xcode has a Derived Data folder for building OS X apps, it has another location for storing XCTest data (storing this data in the Derived Data folder wouldn't be appropriate, since that is used to store built copies of the application intended to be run by the user).
You should note, though, that Xcode will probably put the data back there again the next time you try to run your app's unit tests, and it may take longer to build/run since some of the cached data is gone. It's up to you whether the trade-off is worth it.
And by the way, Xcode builds your entire project to run XCTest, because your tests might depend on certain resources being there in your app bundle. So that's why the folder is so large.
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.
My Xcode started to behave very heavily from yesterday when working on medium size project (around 200 source files). Project compiles correctly and runs in both simulator and device. I do not use any 3rd party libraries, except few widely used includes (like JSON or facebook ios sdk).
It constantly uses CPU(s) at full speed, even if it is in idle state (no indexing, no compiling, no editing). The usage of RAM is relatively normal (300-50MB).
My machine uses: Core 2 Duo 3.04Ghz CPU, 8GB of RAM and Vertex OCZ 3 SSD drive.
I have tried every suggested solution found at stackoverflow:
Cleaned project
Cleaned Derived Data in Organizer
Cleaned repositories in Organizer
Cleaned xcodeproject bundle from workspace and userdata files as suggested here: https://stackoverflow.com/a/8165886/229229 (it is helping just for a moment and starts again after minute or so).
Restarted Xcode many times (with the same effect as in 4).
Disabled "Live issues"
even Reinstalled Xcode
Nothing helps. In most cases, Xcode indexes the project for a moment, then comes back to the normal performance, but after a while becomes unusable again. CPU jumps back to 95-100% for both cores, intelligence hangs, etc...
I am attaching screenshots of how the Xcode processes are seen by the Instruments:
UPDATE:
After a moment of hope that I solved the problem by moving around few
#import "header.h"
statements from headers to the implementation files and exchanging them with forward declarations ... the problem came back again after a while.
I am adding the console log.
The strange thing is that the logs related to Xcode show up after I quit it, not during the run itsef.
Console logs:
5/11/12 9:27:03.777 AM [0x0-0x45045].com.apple.dt.Xcode: com.apple.dt.instruments.backgroundinstruments: Already loaded
5/11/12 9:27:05.571 AM Xcode: Performance: Please update this scripting addition to supply a value for ThreadSafe for each event handler: "/Library/ScriptingAdditions/SIMBL.osax"
5/11/12 9:27:58.168 AM Xcode: ERROR: Failed to create an alert for ID "enabled" based on defaults: 1
What stopped my nightmare was:
Change Always Search User Path to NO in Project build settings (bolded).
Remove -objC flag Other Linker Flags (also bolded setting).
And then delete Derived Data and wait until Xcode reindexes.
I am not sure which of them helped bacause I changed both of them at the same time and I am so behind my schedule I have no time to test it. I will improve this answer when I reproduce the bug and solution in spare time.
However, there is a hint:
*Rethink and recheck your project / targets build settings.*
It is highly probable that this strange behavior may be caused by some unfortunate combination of build settings.
All my projects does this from time to time. I can shut down X-code and start it up again and it'll run fine for a while, then go back to using 200% CPU time (two cores fully loaded).
My solution is to use AppCode as my primary IDE (has the added benefit of being a much better IDE, but that's another story). I only start XCode when I need to edit storyboards and shut it down when I'm done - usually that keeps the problem at bay.
AppCode runs off the same project files/structure has better and faster indexing and never runs into this issue, so I can't see how this can be a settings/configuration problem - it must be a bug in XCode. Hence, I would not waste time changing your code structure as it will most likely only delay the problem, not fix it.
No way to know if the OP actually had a different root cause, but for me it appears to have been an Xcode glitch with git. Adding / committing my current changes solved my problem. Here is the complete scenario and what I did to get it fixed:
Environment:
Xcode Version 5.1.1 (5B1008)
Macbook Pro OS X 10.9.2
2 GHz Intel Core i7, 8GB RAM
I noticed Xcode was starting to eat 200% of my CPU constantly.
Not sure exactly when it started, but Xcode did freeze up on trying to make a snapshot (400% CPU usage for several minutes until I force-quitted Xcode)
After reopening, I noticed Xcode was still stuck indefinitely at 200% CPU usage.
Closing all projects did not work.
Deleting all derived data and restarting did not work.
Uninstalling Xcode and reinstalling at first held promise, but once I re-opened my main project, the CPU returned to a constant 200% CPU usage. (after indexing finished)
Closing the troubled project did not help. Xcode was now stuck again in forever-kill-200%-of-CPU land.
After looking around Stack Overflow, multiple people alluded to git being an issue.
I have a slightly complicated git repo (has a submodule repo and a subproject within the main Xcode project).
I had pending changes in both the main repo and submodule portion of the repo.
I closed Xcode and git added & committed all my current changes.
Reopen Xcode and VIOLA! No more CPU being killed. Back down to 0.0% idle usage.
Xcode 5.1.x seems to struggle with git in other ways for me too (sometimes does not pick up changes in the GUI, etc.) so perhaps there are Xcode git integration bugs.
It looks like it's spending its time parsing ObjC included in the PCH.
How many PCHs must clang generate? In your project, that would be one for C, one for ObjC, one for C++, one for ObjC++ for each dialect/lang used in your project and any dependent targets. That is -- if you have a dependent library included in your app's PCH and you are hacking on that library, all code sense in the app target must be invalidated and parsed again each time you alter a header included by your pch. And if your target compiles a C file, it will need a PCH for C. If it needs one for ObjC, it will need to generate one for ObjC.
How often do you alter the PCH (or anything included by it)?
Remove includes from the PCH. It's not unusual to see every linked framework included in a PCH (avoid doing this!).
If you change your build or preprocessor settings, it may need to rebuild the code sense index for the target(s) entirely each time.
Have you tried disabling live issues?
On my projects (all of them) it was the autocompletion/intellisense. When I changed one line of code in my .h files, it went haywire, +100% CPU usage (more than one core).
I just disabled it, now I have to think a bit more for myself (like I used to do on windows) and it works great at low CPU usage.
i used to encounter this problem.it is caused by git.Although i don't know the git very well.i removed the file named .git in the project directory and it turned to normal.by the way,the .git is hidden.
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
I hope this qualifies as programming related since it involves how to structure a project.
Because I've always used the web site model with VS.net I never had solution and project files and putting everything into source control worked great. I knew that everything I had in my web site directory was all I needed for the web site.
Now I'm using asp.net MVC and it only has a project model so now I have these solution and project files. If I work on it alone it's fine but once other people start to add/delete files from the project our solution file gets messed up and people end up having to grab the latest solution file, see what got changed and then add back/remove their files and check in the solution file again. It's become sort of a problem because sometimes people don't realize the solution file was changed, they make other changes and then when they check in everything other people do an update on their files they find that their files are gone from the project (although still physically on disk).
Is this normal? Is there a way to structure a project so that we don't need to check in solution and project files?
Your developers are not using TFS correctly. You should have multiple check-outs turned on, and everyone needs to be careful to merge their changes correctly when checking in. TFS will prompt you to do this, and accepting the defaults is nearly always the right thing to do.
It's not uncommon to have one or two developers who never get it, and you might have to help them now and then. But every programmer who works on a team needs to learn how to use source control tools correctly. If they can't manage that, they shouldn't be writing software.
[edit] It occurs to me that you might run into these problems if you check in the *.sln file directly, rather than choosing to "Add Solution to Source Control".
I don't think it's normal - what are you using for source control? It sounds like developers aren't respecting changes that others a making - checking in without merging first.
I know that early on in a project, when lots of files are being added & deleted, it can be a problem to keep up - you need to check out the project file, add your files, then check in the new file & project so other developers can also update it. You'll probably have multiple project files in a solution - perhaps one interim solution would be to have one "holding" project for each developer, then clean them up periodically - though these types of temporary fixes do have a tendency to become permanent.
I don't know of a way to set up a project file that's not in source control, though I suppose you could create a script that would generate them.
Having been through this, the key is respect & good communication between the developers.
This tends to happen with TFS multiple check outs. It can be hard to grasp coming from VSS to TFS as VSS allowed one person to check a file out at one time. Auto-merge should work most of the time for you but a couple of rules should ease the pain:
Check in early and often (if you add remove or rename a file check it in straight away even if it is a blank holder)
Before you check in do a get latest, this will ask you to resolve conflicts locally
Try to get continuous integration set up so that developers always know the state of the buidl and whether it is OK to check in\out.
We had a bit fo pain at the start of our current project but it soon settled down when we followed the rules above.
Personally, I think making changes to project and solution files requires discipline and clear (well understood) rules throughout your development team. These files (.sln, .*proj) are the bottlenecks of your project, and any errors or inconsistencies can cost you in team downtime. Changes need to be well thought out, planned and then executed.
They must be secured by source control (which you're already using, excellent) and your team members should work on the basis of only making the changes they need, and not leaving project or solution files checked out for an extended period.
If you are allowing multiple (shared) checkouts, this could become problematic in terms of overwriting another user's changes. Depending on your source control mechanism, people may be required to manually merge changes. Personally, I'd ask people to negotiate their project/solution changes with each other over merging (this can't always be achieved).
A third option if you are using TFS is the shelve feature. If someone needs to make changes locally, they can shelve the changes and merge later.
Lastly, another strategy is to try to architect your solution to be as modularized as possible - so people are distributed, working on separate projects and do not (ideally) have to overlap on too many common areas.
I'm not sure if you are using TFS, as people have mentioned, but if you are (or if you are using source control with similar capabilities) you can set it such that sln and csproj files are exclusive lockouts and are not able to be merged.
We have done this with quite large teams and while it causes some initial issues as people get used to it in the long run it has resolved many issues that were previously causing problems. Essentially you trade longer term merge issues/complexity for short term compile/checkin issues which we have found to be a good trade off.
Once you have set it to forced exclusive checkout and no merge you then get your dev teams used to the fact they should keep locks on the sln and proj files for as shorter time as possible.
Always check them in.
Always check out latest (merge if possible), make sure your change is there, before checking in a new version.
If your source control doesn't require a special action to check in from an old version, GET A DIFFERENT SOURCE CONTROL.