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.
Related
I have been developing with React Native for some years now but the following behaviour only started recently. After running any React Native app on the iOS simulator (either directly from Xcode or via react-native run-ios) the diagnosticd process slowly increases CPU usage to 150% after a couple of minutes. My laptop becomes unusable because the process is also eating up all file handles of the OS. Googling around only points to excessive logging, but either I'm not looking in the right location or no huge amounts of logging is taking place.
Closing the app by pressing the Home button in the simulator immediately stops the high cpu load.
Is anybody also experiencing this? How can I find out what is causing this?
MacOS Catalina version 10.15.3, Xcode version 11.4, React version 16.9.0, React Native version 0.61.5, Simulator iPhone 11 (iOS 13.4)
I think I found the solution. Xcode was logging a lot of lines containing: xcode nw_connection_get_connected_socket Client called nw_connection_get_connected_socket on unconnected nw_connection. This started after some update of Xcode a couple of months ago. Disabling the logging has stopped the diagnosticd process from eating up all OS resources. I followed these instructions: Hide strange unwanted Xcode logs
Basically comes down to adding an environment variable OS_ACTIVITY_MODE with value disable to the Scheme (Run).
What the real reason for the logging is I still don't know. It looks like some sort of polling from React Native.
It's more of a workaround than a solution, but it seems that resetting the simulator to factory default temporary fix this problem (at least on my case).
It looks like diagnosticd is processing some files which may be located on the simulator internal memory, so it may takes more and more cpu as the files are growing over time ?
Anyway try to go to the simulator menu : Hardware -> Erase All Content and Settings
Then close the simulator and start it again from XCode in order to copy your app on it.
workaround from Xcode 9.3 Playground - diagnosticd,
kill $(ps -ef | grep Xcode.app | egrep "diagnosticd|homed" | awk '{ print $2 }')
I found this to be useful
Finally found the solution! I was always wondering why the default url in AppDelegate.m did not work. So I started focusing on that. It turns out that my huge adblocking hosts file was the cause of this. Restoring the original /etc/hosts file solved both problems! 🎉
One more thing you can try, this is a very drastic measure and only do this at your own risk,
first try this,
sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.diagnosticd.plist
and if you get a message about system protection (SIP),
you can try turning off SIP, then running that command again,
That will pretty much guarantee diagnosticd never run's again... no idea about the implications of that though...
read more about those two things here,
https://makandracards.com/dev/16439-disable-daemons-services-in-mac-os-x
https://www.imore.com/how-turn-system-integrity-protection-macos
*disclaimer, this is probably not the safest solution messing with SIP, but I did it on my old 2015 i5 macbook because I was getting desperate, and literally couldn't do any work on simulator with the diagnosticd bug.
So far everything seems happy...
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.
Our iOS automation tests on simulator have gone through disaster since upgrading to Xcode6.
We can observe view switching slowing down, UIAutomation felt it too and often returned an empty or not fully updated app main window, you can imagine the stability.
Part of the reason is that we have slow VMs, but still we need to find ways to workaround it.
Then I notice there's the CoreSimulatorService process staying alive between the launches and shutdowns of simulator. So I killed it to see what change would it make:
killall -9 com.apple.CoreSimulator.CoreSimulatorService
After it was killed and relaunched, the performance of simulator seem to get much better, at least I don't see random fails anymore (hopefully). I guess this is kind of cleaning up.
So I hope to get a better idea about what function does CoreSimulatorService perform exactly?
Also, I am confused about where to find the documents when Apple releases new things (forgive my ignorance). For example, I didn't find any documents in iOS developer library mentioning simctl except Xcode Release Note.
Thanks!
I just faced a unexpected CPU spike due to this process (Xcode 12 & macOS 12).
A quick look on the web showed that most of the time your look for com.apple.CoreSimulator.CoreSimulatorService you will find people afraid of "something" and that are resetting everything. Ultimately this will "resolve" (as a workaround) the problem that isn't really one.
I opened ActivityMonitor (and not just looking at iStat Menu CPU widget), I found that the process update_dyld_sim_shared_cache was responsible for this CPU high usage.
Just reading the name show that the process is probably doing something expected after all (I got this issue after an OS update).
I just waited a around half a hour and the CPU went back to normal.
Since installing XCode 6 GM, it has been freezing and locking, showing the spinning wheel of death while I attempt to edit code that has syntax errors. Has anyone else seen this, and are there any known work-arounds?
I foolishly abandoned my cautious strategy of saving the previous version (Beta 7) and it appears that Beta 7 is no longer available for download. Are there any known archives of / for the link?
I have also posted to the dev forums and will follow up with a bug report, but it is hard to pin down the exact circumstances.
Edit:
Additonal Notes:
CPU: SourceKit Service is generally around 100%, but that has seem to have been the norm for the flavors of XCode, and the CPU seems to properly drop off when it finishes recompiling.
RAM: SourceKit is no longer exhibiting the memory leaks that used to cause it to halt and catch fire, memory does not appear to be a factor, and there are several ~ 5+ gigs to spare.
Environment:
Late 2012 Mac Mini, 16GB RAM
OS X 10.9.4 (to be fair, this was new today as well, driven by the requirements of XCode 6 GM).
That said, only the software changed today.
Update
Apple claims that this bug is fixed in Beta 6.1, for what it's worth.
You should look if you have any imports missing in your bridging header file. Sometimes even commented out imports will cause this behaviour. For me it was commented out Pixate Freestyle Cocoa Pod. I had to remove pod completely from my project to stop SourceKitService from crashing.
https://stackoverflow.com/a/25173389/527539
I can't say any of these fixed the issue, but they alleviated the situation:
I removed all playgrounds from the project tree. Saved them somewhere else.
I removed all objectiveC code from the swift project (when possible). This Spinning-wheel, BTW, is a problem only in my swift projects. My other Objective-C-only projects are fine.
It looks like it's the background indexing process which is taking all the CPU. Open "Activity Monitor" and see it right there at the top, using 360% CPU. Lowering the priority for this process helped as well (type in terminal):
renice 10 -p [pid]
Make sure to take the correct process id from Activity Monitor.
The higher the number (should not exceed 19) the lower the priority.
I make significant changes one at a time. It seems that the amount of errors in the file affect how many times and for how long the spinning wheel spins. It looks like some type of errors trigger it more often than others, but I'm not able to pin point which exactly.
XCode had a similar indexing issue in previous versions (see this Xcode4 issue: How to disable indexing in Xcode 4?) which gives me the hope they will fix this issue sometime, hopefully soon...
I create a new tab via menu File->New Tab and close the old tab that is frozen.
CmdT does not work that time.
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.