Is iOS DeviceSupport safe to delete? Mostly, yes. The folders in ~/ hold system symbols Xcode copied from your iPhone or iPad, one set per OS version. Xcode copies a set again the next time you connect a device running that version, so old sets can go to the Trash.
The exception is a version no device of yours runs anymore. Its set can't be copied again, so crash reports from that version may lose the names of system functions. Keep those sets only if you still read such reports.
Xcode archives are the opposite case. Each one in ~/ holds the exact build you made and the dSYM files that make its crash reports readable, and no later build can replace it. Keep the archive of every build you've distributed; remove test archives that never left your Mac.
This post goes through both folders: what's inside, which parts you can remove, and how to move the ones you keep. For Xcode's other files, see why Xcode takes up so much space.
iOS DeviceSupport and Xcode Archives at a glance
Both folders are about crash reports, which is why they're often discussed together. They answer different halves of the same question: what was the system doing, and what was your app doing, when it crashed.
Where do they live, and what do they hold?
| iOS DeviceSupport | Archives | |
|---|---|---|
| Where | ~/Library/Developer/Xcode/iOS DeviceSupport | ~/Library/Developer/Xcode/Archives |
| What | Symbols of the OS on your devices | Your builds and their dSYM files |
| One per | Device model and OS version | Each time you choose Product › Archive |
| Comes back? | Yes, from a device on that version | No |
| Level in the catalog | Safe | Review first |
Device support has sister folders for other platforms, such as watchOS DeviceSupport, next to it. Archives sit in one folder per day, named by date, each holding the archives you made that day.
How much space do they take?
- Device support, all platforms5–60 GB · Safe
- Archives1–50 GB · Review first
- 41 archives on one Mac, measured1.9 GB · Review first
Typical ranges from developers' reports, collected for the app's rules catalog. The measured figure is one developer's Mac with a few months of releases of small apps.
Device support grows with the number of devices and updates; archives grow with the number of builds. A developer on Apple's forums once found 121 GB of device support on a 256 GB Mac, from 56 iOS versions collected over the years.
Archives are usually smaller per item. On the Mac we measured for this post, each archive of a small app with a widget took between 30 and 80 MB, so they only add up after many releases. For a budget that includes Xcode, runtimes and simulators, see how much storage iOS development needs.
Why does Xcode treat them so differently?
Because one can be made again and the other can't. Apple's software is the same on every device of a model and version, so any iPhone 17 running iOS 26.2 has the same symbols to copy.
Your build is unique. Apple's documentation explains that a binary and its dSYM file share a build UUID, and two builds of the same code made with a different Xcode or different settings won't match. Once an archive is gone, nothing recreates it.
How crash reports get their names
A crash report starts as a list of memory addresses: where each thread was when the app stopped. Turning those addresses into function names and line numbers is called symbolication, and it needs two kinds of symbols.
Where does each name come from?
Each line of a crash report's backtrace points either into your code or into Apple's. Your lines are named from the dSYM files in your archive. Apple's lines, in frameworks such as UIKit or Foundation, are named from the device support set for the exact OS version in the report.
So the two folders cover the two halves. With only device support, you see what the system was doing but not your own functions. With only the archive, you see your code, and Apple's lines stay as addresses.
How much does a missing half matter?
Apple's documentation describes three states. A fully symbolicated report names every line. A partially symbolicated one names some lines and leaves addresses on others, and it's often enough to understand the crash.
An unsymbolicated report shows only addresses, and Apple says it's rarely useful. Losing your app's dSYMs pushes a report towards that state; losing a device support set usually leaves it partial, with your own code still named.
Which crash reports use your Mac's files?
| Where the report comes from | What names your own code |
|---|---|
| Crashes organizer, symbols uploaded with the build | Apple, before the report reaches you |
| Crashes organizer, no symbols uploaded | Your archive's dSYMs, if they're on this Mac |
| A device's Reports tab in Device Hub | Your archive's dSYMs on this Mac |
| A report someone sends you as a file | Your archive's dSYMs on this Mac |
| A crash of your Mac app | Your archive's dSYMs on this Mac |
For reports you open on your Mac, Apple's documentation adds the other half: when Apple's lines aren't named, get the device symbols for the OS version in the report. For a Mac app, that means opening the report on a Mac running the same macOS version.
What does that mean for cleanup?
If almost all your reports arrive in the Crashes organizer with symbols uploaded, old device support sets and old archives on your Mac do little day to day. If testers, clients or customers send you reports directly, both folders do real work, and the old versions are the ones those people are most likely to run.
What's inside iOS DeviceSupport
When you connect an iPhone, iPad, Apple Watch, Apple TV or Apple Vision Pro for development, Xcode copies operating system binaries that contain symbols from it. Apple says the system saves them in a DeviceSupport folder for each platform.
What are device support files?
They're the system's own libraries and frameworks, with their symbols, exactly as they are on that device. Xcode uses them in two ways: to debug your app on the device, and to give names to the system's part of a crash report.
Without them, the lines of a crash report that point into Apple's frameworks show bare memory addresses. With them, those lines name the function, such as a method in UIKit.
Why is there a set for every version?
Apple's documentation says the symbols are specific to the OS release, the device model and its CPU architecture. Its example: an iPhone running iOS 26 needs different symbols from the same iPhone running iOS 26.2.
So every software update on every device you connect adds a set, and the older ones stay. Two iPhones, an iPad and a watch, each updated several times a year, add up quickly.
How do you read a folder's name?
Each folder is named after the device's model identifier, the OS version and its build, such as iPhone17,1 26.0 (23A341). The model identifier is Apple's internal name for the hardware, not the name on the box.
The version and build are what matter for cleanup. If none of your devices runs 26.0 anymore, that folder belongs to the past, whatever the model.
Why do betas add so many sets?
Each beta of an OS release has its own build number, and symbols are specific to the release. So a test device that runs every beta of a new iOS version adds a set for each one.
Once the final release ships and your device moves to it, those beta sets have nothing left to do. They're usually the first to remove.
Which platforms have their own folder?
| Folder | Filled by | Can it come back without the device? |
|---|---|---|
iOS DeviceSupport | iPhone and iPad | No |
watchOS DeviceSupport | Apple Watch | Yes, by download, at the command line only |
tvOS DeviceSupport | Apple TV | No |
visionOS DeviceSupport | Apple Vision Pro | No |
There's no folder for the Mac. Apple's advice for Mac and Mac Catalyst apps is to symbolicate crash reports with Xcode on a Mac running the same macOS version as the report.
Why are watch sets different?
Apple documents a way to download watchOS symbols for a given release without pairing the watch to your Mac. Since watchOS 11, that download gives universal symbols that work for every Apple Watch model, and its folder name ends in universal.
There's no button for it in Xcode; it's a command-line step in Apple's documentation. So a watchOS set is easier to get back than an iOS one, but only if you're comfortable with that route.
Is iOS DeviceSupport safe to delete?
Yes, in the catalog's terms: Xcode device support files are Safe, because Xcode copies them again the next time you connect a device running that exact version. What you're really deciding is which sets you'll still need when a device isn't there to copy from.
What happens when you delete a set?
Nothing, until you connect a device on that version. Then Xcode copies the symbols again before you can debug, which takes a few minutes for an iPhone and can take much longer for an Apple Watch.
Your projects, builds and archives aren't touched. Crash reports you open in the meantime from that OS version may show addresses instead of system function names, until the set is back.
When can't a set come back?
When no device you can connect still runs that version. iPhones and iPads rarely go back to an older iOS version, so once all your devices have updated past it, its set is the last copy on your Mac.
That matters only if you still read crash reports from people on that version. If your app's users have mostly updated, or you only read reports from App Store builds in the Crashes organizer, the old sets have little left to do.
Which sets should you keep?
| Set | Keep it? | Why |
|---|---|---|
| The OS version your devices run now | Keep | You'd copy it again the next time you debug |
| A version you still get crash reports from by email or from testers | Keep | It can't be copied again once your devices update |
| An older point release of a version you still run | Remove | Your devices have moved past it |
| A device you sold or gave away | Remove, unless you read its version's reports | No device left to copy from |
| A beta version that has since shipped | Remove | The release has its own set |
| watchOS sets | Remove old ones | They can be downloaded again |
How to delete old device support files
There's no setting in Xcode for this, so Finder is the way. It takes a few minutes, and everything goes to the Trash first.
Delete old sets in Finder
- Check which OS version each of your devices runs, in Settings › General › About on each device.
- Quit Xcode, so it isn't copying symbols while you work.
- In Finder, choose Go › Go to Folder…, enter the path to the iOS DeviceSupport folder and press Return.
- Choose View › as List and sort by Name, so the sets for each model sit together.
- Select the sets for versions you no longer need and choose File › Move to Trash.
- Repeat for the watchOS, tvOS and visionOS folders if you have them.
- Connect a device and run your app once, to check that debugging still works, then empty the Trash.
Removing only the old sets keeps the one for the version you run now, so your next debugging session doesn't start with a wait.
How much will you free?
Check before you start: select the sets you plan to remove and choose File › Get Info, or use View › Show View Options and turn on Calculate all sizes in list view. One developer on Apple's forums estimated about 3 GB per iOS version, though sizes vary by version and device.
A worked example
Say your iOS DeviceSupport folder holds nine sets: four for an iPhone, at iOS 18.6, 26.2, 26.6 and 27.0, three for an iPad at 26.2, 26.6 and 27.0, and two for a test iPhone you've sold, at 18.6 and 26.2.
Your iPhone and iPad both run iOS 27.0 today, and you haven't opened a crash report from iOS 18 in months. Keep the two 27.0 sets and move the other seven to the Trash.
If a tester sends you a report from iOS 26.6 next week, its system frames may show addresses, while your own frames still resolve from your archive. If reports from 26.6 matter to you, keep the iPhone's 26.6 set too.
What about Apple Watch device support?
Copying symbols from an Apple Watch is the slowest case, so the set for the watchOS version you debug on now is worth keeping. Older watchOS sets are good candidates to remove, because Apple documents a way to download them again.
What's inside an Xcode archive
Each time you choose Product › Archive, Xcode builds your app for distribution and keeps the result as an archive, a bundle Finder shows as a single file. Apple says the archive holds all the binaries and dSYM files of your app.
What are the parts of an archive?
| Part | What it is | What it's for |
|---|---|---|
Products/Applications | The app exactly as you built it | Exporting or uploading that build again |
dSYMs | One dSYM per binary: app, extensions, frameworks | Naming your code in crash reports |
Info.plist | Version, build number, team and date | What the Organizer shows |
In the archive we measured, the dSYM files took 19 MB and the app 10 MB. Symbols describe every function in detail, so they can be larger than the app itself.
Why can't you rebuild an archive later?
You can build the same version again, but it won't be the same build. Apple's documentation says a binary and its dSYM match only when their build UUIDs are identical, and two builds of the same source made with a different Xcode or different build settings get different UUIDs.
So the crash reports from the build people are running can only be matched with the dSYMs from its own archive. Apple's guidance is to retain the archive of every build you distribute; without it, you may not be able to diagnose crashes in that version.
How do you check an archive has its dSYMs?
An archive is only as useful as its dSYMs folder. In Finder, Control-click an archive and choose Show Package Contents, then open dSYMs. There should be one dSYM for the app and one for each extension or framework you built.
If the folder is empty, check the target's Debug Information Format build setting. Apple's documentation says it should be set to DWARF with dSYM File before you build for distribution, so the archive collects the dSYMs.
How do you match an archive to a crash report?
Start with the version and build number at the top of the report, then find the archive with the same numbers in the Organizer. To be certain, compare build UUIDs: Apple's documentation says the Binary Images section at the bottom of a report lists the UUID of each binary.
In Xcode, open the report, Control-click the process in the Debug navigator and choose Show Library Info to see the same UUIDs. A dSYM matches only when its UUID is identical.
Isn't uploading symbols to App Store Connect enough?
It covers the most common case. When you upload a build with its symbols, Apple adds your app's symbol names to crash reports before they reach the Crashes organizer, so those reports stay readable without the archive.
Apple still says to keep the archive. Builds you shipped another way have no copy at Apple, reports someone sends you directly are symbolicated on your Mac, and you can't export or upload a build again once its archive is gone.
When you distribute through TestFlight or the App Store, Xcode's distribution steps let you choose how symbols are handled. Including them is what lets Apple name your code in those reports, so leave it on unless you have a reason not to.
What about crash reporting services?
Services such as Firebase Crashlytics and Sentry ask you to upload dSYM files for the same reason Xcode needs them. Firebase's documentation points to the dSYMs folder inside the archive as where they come from.
If such a service has your dSYMs, its own reports stay readable. It doesn't replace the archive for Xcode, for reports outside that service, or for exporting the build again.
Which Xcode archives are safe to delete?
The catalog rates Xcode archives as Review first: they never start checked, because only you know which builds reached people. The question for each one is simple: is anyone running this build, and will you need to read its crash reports?
Archives you can usually remove
- Archives you made to test the archiving step and never exported or uploaded.
- Archives that failed validation or were rejected before anyone installed them.
- Duplicates: a second archive of the same version and build number that you never distributed.
- Development exports for your own devices that you've since replaced.
Archives to keep
- Every build on the App Store or in TestFlight that people may still be running.
- Every build you distributed outside the App Store, such as a Developer ID Mac app or an Ad Hoc build for clients. Apple has no copy of those symbols.
- The last build of an app you've stopped updating, if it's still installed anywhere.
How to decide by where the build went
| Where the build went | Keep the archive? | Why |
|---|---|---|
| App Store, uploaded with symbols | Keep, or move to a backup drive | Apple's reports are covered; local ones aren't |
| TestFlight only, long expired | Usually fine to remove | Testers can no longer get it |
| Outside the App Store | Keep | It may be the only copy of its dSYMs |
| Ad Hoc or enterprise builds | Keep while devices run them | Their crash reports come to you as files |
| Nowhere: never exported or uploaded | Remove | No one is running it |
App Store Connect Help says a TestFlight build becomes unavailable for testers after 90 days. An archive whose build only ever went to TestFlight, and expired long ago, has few people left to crash.
What about apps you no longer sell?
If an app is gone from the App Store and from people's devices, its archives have little left to do. But apps stay installed after they're removed from sale, so an app that people bought may run for years. Moving those archives to a backup drive costs little and keeps the option open.
A worked example
Say the Organizer lists 60 archives for one app, from version 2.0 to 3.4, made over two years. Some versions have three or four archives each: test runs, a build that failed validation, a TestFlight build, then the one that shipped.
Keep the archive of each build that reached the App Store, and of any build you sent to clients directly. Remove the test runs and failed attempts, and the TestFlight-only builds that expired long ago. Then move the shipped archives from before 3.0 to an indexed backup drive. The newest releases stay where Xcode looks first.
How to remove or move archives
Xcode's Organizer is where archives are listed by app and version, and it's the easiest place to decide. Removing them goes through the Trash either way.
Remove archives you don't need
- In Xcode, choose Window › Organizer and click Archives in the sidebar.
- Select an app on the left. Its archives are listed with the date and version of each.
- Control-click an archive you don't need and choose Show in Finder.
- Drag the archive to the Trash in Finder.
When you remove archives in the Organizer itself, Xcode asks you to confirm and moves them to the Trash rather than deleting them. Either way, they can be put back until you empty the Trash.
Move archives to another drive
For builds you shipped, moving is better than deleting. Apple's Developer Technical Support has said that the Archives location in Xcode › Settings › Locations can point to an external drive, formatted as APFS.
- Copy the archives you want to keep to a folder on the drive, and check the copy finished.
- In Xcode, choose Xcode › Settings and click Locations.
- Next to Archives, choose a custom location and select that folder.
- Open the Organizer and check that your archives are listed.
- Move the originals in your Library folder to the Trash.
New archives then go to the drive too. If that drive isn't connected when you archive, set the location back first.
Make sure Spotlight can still find them
Xcode finds dSYM files through Spotlight. Apple's documentation says that if a dSYM can't be found, you should check that Spotlight indexing is turned on for the folder that holds it, in System Settings, and that its path doesn't include .noindex.
So a backup drive that Spotlight doesn't index can hold your archives safely, but Xcode won't find their dSYMs there. Keep archives you may still need in a place Spotlight indexes; Apple suggests your home folder as one.
Just keep the dSYMs?
You can, if space is tight. The dSYMs folder inside an archive is what crash reports need; the app beside it is what you'd need to export or upload the build again. Copying an archive's dSYMs to an indexed folder keeps crash reports readable.
Keeping the whole archive is still the better choice. It's what the Organizer understands, and it's what Apple's guidance asks for.
Can you compress old archives?
You can, with File › Compress in Finder, and the zip file takes less space. But Spotlight doesn't look inside zip files, so Xcode won't find the dSYMs of a compressed archive until you expand it again. Compress only archives you're keeping as a record, not ones you still read crash reports from.
Mistakes and edge cases
Most problems come from treating these folders like caches, or from cleaning the whole Xcode folder at once.
Can you delete the whole Xcode folder in your Library?
Don't. ~/ holds DerivedData and device support, which come back, right next to your archives, which don't. Remove the parts one by one, as the post on CoreSimulator's folders does for simulators.
What if you've already deleted an archive you needed?
Look in the Trash first: if it's still there, select it and choose File › Put Back. If you use Time Machine, restore the archive from a backup made before you deleted it. A crash reporting service you uploaded dSYMs to may also still have that build's symbols.
If none of that works, Apple's documentation is plain: without the archive, you can't symbolicate your app's addresses for that version. Its advice is to release a new version and keep its archive, so future reports can be read.
Several copies of Xcode, or several accounts
Device support and archives belong to your user account, not to a copy of Xcode. A release and a beta of Xcode on the same Mac read the same folders, so removing a set or an archive affects both. The post on uninstalling Xcode covers keeping your archives when the app goes.
Each account on the Mac has its own Library folder, with its own device support and archives. Cleaning up yours leaves another account's untouched.
Teams and build servers
When a build server makes your release builds, its archives are the ones that matter, not the ones on your own Mac. Make sure the server keeps each distributed build's archive or dSYMs somewhere lasting, and that your local test archives are what you remove.
On a shared team, agree on one place for release archives. A developer who cleans up their Mac shouldn't hold the only copy of last year's release.
Mac apps
Mac apps have no device support folder, but their archives matter just as much. A Developer ID app you notarized and shipped from your website has no copy of its symbols at Apple, so its archive is the only way to read its crash reports.
Does deleting these make a Mac faster?
No. It frees disk space and nothing else. Xcode doesn't run faster with fewer device support sets or archives, and the next device connection takes longer while symbols are copied.
Keeping both folders under control
Neither folder is cleaned by Xcode, so a short routine after each round of updates does the work.
After each OS update
- Connect your devices and let Xcode copy the new symbols.
- Move device support sets for versions none of your devices run to the Trash.
- Keep sets for versions you still read crash reports from.
After each release
- Keep the archive of the build you shipped, and copy it to a backup drive.
- Remove test archives and failed attempts from the same release.
- If you use a crash reporting service, check that the release's dSYMs reached it.
Once a year
- Move archives of old releases to an indexed external drive.
- Remove archives of TestFlight builds that expired long ago.
- Check the watchOS, tvOS and visionOS folders, which are easy to forget.
The guide to freeing up the space Xcode uses has the short version for every part of Xcode.
How the app does it
Wombit explains both folders like everything else on the disk. Select one in the map, the app's home screen, and the inspector says what it is, how safe it is to remove and what removing it costs, from the catalog's entry. It reads only names, sizes and dates, and file names and paths never leave your Mac.
Cleanup lists them by level:
- Device support folders are Safe. They count toward the safe total and start checked, and the inspector says what removing them costs: a wait the next time you connect a device, and no symbols for versions you can't connect anymore.
- Each archive is Review first. Archives never start checked and never count in the safe total; they wait for your choice, one by one.
Everything goes to the Trash, where you can put it back, and Cleanup History logs what was moved.
~/
Library/ Developer/ Xcode/ * DeviceSupport Symbol files Xcode copies from each iPhone, iPad, Apple Watch, Apple TV or Apple Vision Pro you connect, one set per OS version.
Safe · Moves it to the Trash
~/
Library/ Developer/ Xcode/ Archives/ */ *.xcarchive Copies of each build you archived in Xcode, with the dSYM files needed to read crash reports from that build.
Review first · Moves it to the Trash
Seeing all of this is free. Cleanup is PRO, one $4.99 payment with lifetime access. Every Pro tool's review is free to open, so you see what would go and why before you buy.
Frequently asked questions
What happens if I delete the iOS DeviceSupport folder?
Nothing breaks. The next time you connect a device for development, Xcode copies that OS version's symbols again, which takes a few minutes for an iPhone and longer for an Apple Watch. Sets for versions no device of yours runs anymore can't be copied again.
Why is my iOS DeviceSupport folder so big?
Xcode adds a set of system symbols for every OS version and device model you connect, and never removes old ones. Several devices updated several times a year build up dozens of sets over the years, each often a few gigabytes.
Can I delete old Xcode archives?
Delete archives of builds no one received, such as test archives you never uploaded or exported. Keep the archive of every build you distributed, because its dSYM files are the only ones that match that build's crash reports. Move old ones to a drive Spotlight indexes rather than deleting them.
Do I need archives if I uploaded symbols to App Store Connect?
Apple adds your app's symbol names to App Store and TestFlight crash reports when you upload symbols, so those stay readable. Apple still recommends keeping the archive: reports sent to you directly are symbolicated on your Mac, and you can't export or upload a build again without its archive.
Can I move Xcode archives to an external drive?
Yes. In Xcode › Settings › Locations, point Archives at a folder on an APFS-formatted drive. Make sure Spotlight indexes that drive, because Xcode finds dSYM files through Spotlight when it symbolicates crash reports.
Is there a DeviceSupport folder for Mac apps?
No. Apple's advice for Mac and Mac Catalyst apps is to symbolicate crash reports with Xcode on a Mac running the same macOS version as the report. Archives of Mac apps still matter, especially for apps distributed outside the App Store.
How do I get watchOS device support without my Apple Watch?
Apple documents a command-line step that downloads watchOS symbols for a given release, universal for every Apple Watch model since watchOS 11. Xcode has no button for it, so if you prefer to avoid the command line, keep the set for the watchOS version you debug on.
Sources
- Acquiring operating system symbol information · Apple
- Building your app to include debugging information · Apple
- Adding identifiable symbol names to a crash report · Apple
- Locating a missing debug symbol file · Apple
- Can I move Xcode files to an external SSD safely? · Apple Developer Forums
- Can I delete folders in iOS DeviceSupport? · Apple Developer Forums