I don't know what is happening but when I try to open the file Xcode_7.1.dmg and copy the Xcode.app into the applications folder, there's a point that the progress bar won't move. By the way, I have OS X Yosemite (v10.10.5) installed. Prior to copying, I deleted first the old version of Xcode and emptied Trash.
Gatekeeper takes a while to cryptographic validate the entire app. Just give it the time it needs.
So that progress bar is probably the "preparing to copy xcode.app" and it's just stalling there right?
I had this problem myself. I just kept starting and restarting it (the copying process) and at a point I tried to copy it over to a jump drive. After a few more times starting and restarting it, Xcode began to copy! And the file size was 10.8gb so be warned.
It may also just take a while. I was having issues after an update to Xcode through the app store failed.
It did take a while on that window, but eventually started. I would reckon there are a large amount of files and folder structure that are being mapped at that time. It would be good UX to give some type of indication that something is actually working, though.
Another thing I'd add here--once the copy begins, the time estimate can be misleading. At first, it was indicating that it would take 12 hours to install, but of course, was only a fraction thereof.
Related
I have a 250Gb M1 Mac Mini and it is starting to run out of disk space recently, it seems like the UI Previews is the main culprit which takes roughly 165GB space alone and is increasing each day. Tried to delete the folder using Dev Cleaner but was told not able to do so. Tried to google the issue but only found this thread with only a few replies. It makes me wonder is it just me or everyone has this issue?
I have the same problem. For me, DevCleaner is complaining about permissions, so I had to go to /Users/Me/Library/Developer/Xcode/UserData/Previews/Simulator\ Devices/ directory and manually delete simulator files.
Edit:
Save space by
xcrun simctl delete unavailable
xcrun simctl erase all
Delete /Users/username/Library/Developer/CoreSimulator folder.
I had a similar issue where /Users/Me/Library/Developer/Xcode/UserData/Previews/ "Simulator Devices" and "Simulator%20Devices" where taking up over 400GB of space.
I only found this was an issue when "System Data" on my iMac was over 450GB
I found the solution here, to delete the simulator devices.
https://www.reddit.com/r/iOSProgramming/comments/riguh3/xcode_preview_folder_increasing_in_size_what/
There was a little file called "device_set.plist" which i did not delete.
As to what may have caused this, I used the grand perspective app to see what was using all that space, and it ended up pointing to videos that were being played in previews.
The videos seem to load in a janky way and take a long time, and then to continue in the background when playing in xcode so I think that it might be related to the way SWiftUI Previews loads videos. However I am no expert, this is my speculation.
Xcode 14: Adding to what #TaeVitae wrote, I got tired of watching Xcode try and create the previews, so I did a bit more digging. I found that inside ~Library/Developer/Xcode/UserData/Previews/Simulator Devices/[device ID]/data/, some of the biggest culprits taking up space were Containers, Library and var.
I could easily delete Containers and Library. Deleting var took way too long for Xcode to recreate the preview, so I stopped waiting.
Yes, Xcode recreates Library, but deleting it significantly reduced the amount of storage it took up.
On my computer there's a folder of nearly 1GB in size at the following path:
/private/var/folders/ph/q7jl9fz115g104hfgpsw5k6w0000gn/C/com.apple.DeveloperTools/All/Xcode/EmbeddedAppDeltas
It remains there no matter whether I delete build folders or not. It appears to have every version of my app that I've ever archived in there. What's the purpose of that directory? I'd like to delete it as it's taking up over 900 MB, but I don't know what it's for, and googling did not help. Evidently they have it so well hidden that few people have noticed it before.
Just rm -rf it? That's how I removed mine.
These apparently are temporary files associated with Xcode, but they don't seem to get cleaned up via a reboot. I followed the advice in this OSX Daily article and was able to clean up the folder by simply booting into safe mode. Just hold down shift while your computer is booting. Be prepared for it to take a few minutes. The folder was completely removed after safe booting.
One of my projects seems to be nearly impossible to search through in Xcode 4.3.2 on Lion lately. Using the search navigator to find anything in my project basically locks up my whole computer, with the beach ball, for 30 seconds or more.
I've tried deleting the project.xcworkspace file (which is very small anyway), and that didn't fix it. I've tried clicking on the Xcode activity viewer, but everything is locked up, so I can't see anything helpful.
With the Activity Monitor application, I can see the CPU spike when the search starts, and then it comes down to normal, and then Xcode hangs (appears as Not Responding) until it finally times out or something.
Other projects are fine. Search proceeds normally. And this only started in the last few weeks.
What I'm really worried about is a hard drive problem, but this seems very localized, and Disk Utility thinks my drive is fine.
I guess I can try making a copy of my project and searching the copy.
Has anyone seen anything like this before?!
Screenshot: Find gets stuck...
Rebuilding the code sense index didn't work either.
I did solve the problem though. The problem was a single file in my project - it seemed to be corrupt or damaged in some way. It couldn't be copied (which is how I discovered the culprit). It also couldn't be 'quick looked' or examined.
All I had to do was delete the damaged file, and revert it from my source control. And problem solved.
Now, how did it get damaged? I have no idea.
As a current Xcode project of mine has gotten larger and larger, I've noticed that quite often, Xcode seems to "recompile the world" when I make a change to a single non-header file from emacs. Not always, but a lot. I think it might have always been doing this, but when the project was small, I never noticed or cared. Now that the project's fairly big, it's absolutely killing my productivity. How the heck do I stop this?
(Yeah ... answering my own question [https://meta.stackexchange.com/questions/17845/etiquette-for-answering-your-own-question]).
It took me a fair amount of tracking to nail this ... but definitely worth it.
It boils down to the lock files that emacs creates to detect simultaneous edits from multiple emacs processes. These files are (invalid) symlinks from .#<filename> to <host:pid>. Xcode absolutely hates these files (so do some other tools I use ... though I'm blanking on what they are right now ... might even have been xcodebuild.) Xcode.app doesn't actually raise any errors but it seems to chuck its dependence information. These lock files are not backup files: they exist when you've changed the contents of a file but not yet saved it, so what you get is behavior where just making a local change in an emacs buffer ends up causing a "rebuild the world" even though nothing's been saved.
There isn't, at this point, any way of disabling these lock files. The issue was raised on the emacs list a few months ago but died out without any resolution.
To work around the problem, you have to disable the lock files at compile time. You do the normal configure dance, then in src/config.h, after the #include for the os and machine configs, add #undef CLASH_DETECTION
I've filed a radar with Apple.
I got darwinbuild off macports to get a single unix executable (long story, see Where/how to get the Mac OSX "login" command). I was having trouble figuring out how it worked, so I tried their website's example build, "darwinbuild xnu"
It worked, and when I opened the new volume it mounted in finder, it appeared to be building a whole new mac osx (I know this is probably not the case, but that is what it looked like to me at least.) So I grabbed the binary I wanted, hit control-c in terminal, and unmounted the volume. Everything seemed to work out, but even after restarting the computer, I could not get the 2gig or so that build/mount/kernal/thing took up.
I even tried restoring a timemachine backup, but even that would not bring the free space back.
So how do I get rid of this thing once and for all?
If you know the location the files were written to, navigate there in Finder then delete them. If you don't, read the documentation that comes with the Darwin stuff you downloaded (it'll be there, believe me) to find out or download a drive space analyzer app to locate it.
Really, I don't see how these questions are about programming? They're more "how do I fix something I screwed up ancillary to programming-related efforts," which are of course superuser.com material.