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.
Related
I am currently working on a game (Mac, Objective-C) that uses prerecorded cutscenes. All the mp4-videofiles are really big. In total I have 86 video files that are 3.77 GB all together. Whenever I build the app it takes well over 15 minutes. Way too long if you are working on just one line of code and you need to test it.
For testing purposes I always deleted the files from the 'Copy Bundle Resources' so that the files would still be in my Xcode project but not in my app. I only included the files that I needed at that moment (so from 3.77 GB to ±100 MB of files). When I built the app then, it was only 40 seconds or so. This has always worked out fine.
However, this week Xcode started acting strange. Even if I removed all of the files in the Copy Bundle Resources all the video files would still be in my application. This means that every time I have to correct a mistake I made, I have to wait 15+ minutes.
After being frustrated for a while I started to remove the files manually (I clicked on Delete -> Move To Trash). So now all the files are removed from the Copy Bundle Resources and out of my Xcode project. But still Xcode includes them in my application if I build it. How?!
So, a long story short, Xcode does not remove files out of my application. The files aren't even in my project anymore but still Xcode finds a way to include them in my application. Does anyone know why/how Xcode does this? Any suggestions/solutions?
I gave up trying to look for answers and I just deleted the build and made a clean one. Right click on the YourApplication.app > Show In Finder > and delete it from there. Then build the app again and it will only contain the files you selected.
After going through and cleaning my disk with old things that I didn't need anymore, I came across the iOS DeviceSupport folder in ~/Library/Developer/Xcode which was taking nearly 20 GB.
A similar question has been asked before, but since then many things have changed and I would like an up-to-date answer.
As long as I have the version I use for testing, can I delete the older/unused versions without breaking anything?
The ~/Library/Developer/Xcode/iOS DeviceSupport folder is basically only needed to symbolicate crash logs.
You could completely purge the entire folder. Of course the next time you connect one of your devices, Xcode would redownload the symbol data from the device.
I clean out that folder once a year or so by deleting folders for versions of iOS I no longer support or expect to ever have to symbolicate a crash log for.
More Suggestive answer supporting rmaddy's answer as our primary purpose is to delete unnecessary file and folder:
Delete this folder after every few days interval. Most of the time, it occupy huge space!
~/Library/Developer/Xcode/DerivedData
All your targets are kept in the archived form in Archives folder. Before you decide to delete contents of this folder, here is a warning - if you want to be able to debug deployed versions of your App, you shouldn’t delete the archives. Xcode will manage of archives and creates new file when new build is archived.
~/Library/Developer/Xcode/Archives
iOS Device Support folder creates a subfolder with the device version as an identifier when you attach the device. Most of the time it’s just old stuff. Keep the latest version and rest of them can be deleted (if you don’t have an app that runs on 5.1.1, there’s no reason to keep the 5.1.1 directory/directories). If you really don't need these, delete. But we should keep a few although we test app from device mostly.
~/Library/Developer/Xcode/iOS DeviceSupport
Core Simulator folder is familiar for many Xcode users. It’s simulator’s territory; that's where it stores app data. It’s obvious that you can toss the older version simulator folder/folders if you no longer support your apps for those versions. As it is user data, no big issue if you delete it completely but it’s safer to use ‘Reset Content and Settings’ option from the menu to delete all of your app data in a Simulator.
~/Library/Developer/CoreSimulator
(Here's a handy shell command for step 5: xcrun simctl delete unavailable )
Caches are always safe to delete since they will be recreated as necessary. This isn’t a directory; it’s a file of kind Xcode Project. Delete away!
~/Library/Caches/com.apple.dt.Xcode
Additionally, Apple iOS device automatically syncs specific files and settings to your Mac every time they are connected to your Mac machine. To be on safe side, it’s wise to use Devices pane of iTunes preferences to delete older backups; you should be retaining your most recent back-ups off course.
~/Library/Application Support/MobileSync/Backup
Source: https://ajithrnayak.com/post/95441624221/xcode-users-can-free-up-space-on-your-mac
I got back about 40GB!
I wrote a small command-line utility based on the great answer by #JamshedAlam for those who are tired of deleting the contents of those folders manually. Check it out here if you think it would help you.
Yes, you can delete data from iOS device support by the symbols of the operating system, one for each version for each architecture. It's used for debugging.
If you don't need to support those devices any more, you can delete the directory without ill effect
I have an Xcode Project I'm working with for a client. The project has around 78 targets in order to facilitate a main app and a split-off of around 77 "sub-apps" that display varying information from a web server (using the main app as a kind of template).
Also, this isn't exactly a small app. There are around 70-80 classes, 5 storyboards and probably 30-40 different screens.
I'm having a problem with Xcode seriously bogging down. There are two problem areas:
Indexing takes forever. Xcode is indexing each and every single target separately.
In Storyboard: Refresh all Views takes around 30 minutes as Xcode builds each target separately before it actually gets around to refreshing the storyboard's views... and I have to do this 5 times, once for each storyboard.
What I need is a way to prevent Xcode from indexing anything except the "Main" target. Likewise the Refresh all Views option.
Any ideas? Is there perhaps a better way to structure the project?
This is a possible answer. I'm not entirely sure yet how well it's going to work in the long run. Note: I use cocoa pods, so I've gotta deal with a workspace, which in the end may cause me the most problems.
I copied both my .xcworkspace and xcodeproj files and renamed them.
In the copied workspace file, I removed the main Xcode project and inserted the copied project.
In the copied project, I removed the main, test and documentation targets mostly to avoid confusion. The only targets left are the 77.
In the main workspace, I removed all 77 of the 'sub-app' targets. It took about Xcode 20 minutes to do this. Seriously comical.
I will do all of my development in the main workspace. In the copied workspace I will only build the sub-apps as needed.
One downside is that I'll need to add any new files to both projects, but I don't think this will be too onerous.
Probably the biggest problem will be when I need to add/update a cocoa pod. I'll cross that bridge when I get there.
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.
I have an application to be distributed.
Pretty much everything is self-contained within one bundle so I could just put the bundle in a DMG for the first version-- however this won't work for upgrades, so I figured I'd best work out the process ahead of time.
I've been looking at PackageMaker and it seems straightforward enough. However I have a couple of very specific requirements which may cause problems, and it wasn't apparent from reading the PM docs as to whether this is even possible:
First of all, I want the installer to automatically choose between installing two different versions of the app, depending upon whether a previous version of the application has previously been installed.
Secondly, I don't want to just overwrite the previous application's bundle, I just want the installer to overwrite files within it and add new ones -- in other words, I want certain files within the application bundle to remain from the previous version.
Is this something I could achieve with PackageMaker, or should I look for a different approach?
You can do a lot with an installer package, for example run a shell script which in turn allows you to do everything.
I get the feeling that you're doing it not the Mac way. It's uncommon to store data in the application bundle, normally such stuff goes to ~/Library/Application Support/. I presume that those two different applications are quite similar, why not just set a preference?
Personally, I feel that today a .zip is the best way to distribute your apps. It gets automatically decompressed and shows up with your application icon in the downloads stack. (Only if you get it from the internet, of course.)
For updating look at the sparkle framework. The forst install is just copy the application bundle from the internet and te user then just asks to do update and does not have to leave your application to do anything