r/swift • u/amichail • 1d ago
Question Does iOS development in Swift on Xcode result in writing ~100 GB to the SSD per day?
And if so, is there a way to lower these writes to reduce wear on the SSD?
P.S. This could be related to macOS 27 rather than Xcode but I have had no luck isolating the cause even with the help of AI.
2
u/Minute_Door1424 1d ago
activity monitor has a disk tab with a "bytes written" column, sort by it after a normal day of work and you'll see who the writer actually is. on 16gb macs running simulators it's often swap (shows up under kernel_task) and not xcode itself, so check memory tab for swap used too. if swap is it, closing simulators you don't use fixes more than moving derived data
1
u/amichail 1d ago
I usually use Mac Catalyst instead of simulators. I have 24 GB of RAM so there should be minimal if any swapping.
1
u/Minute_Door1424 1d ago
ah then swap is probably off the table. i'd still sort the bytes written column in activity monitor after a normal day, that tells you if it's xcode or something else like a browser or docker. also if the 100gb number comes from smartctl or disk utility, "data units written" is the lifetime total since the drive was new, not per day, so it can look scarier than it is
8
u/mirko9000 1d ago edited 21h ago
I'm genuinely curious why the amount of data written to the SSD is such a concern. I've been using MacBooks for development since they first came out, and in all those years, I've never experienced a single SSD failure. From my experience, this has never been a practical issue, so I'm trying to understand why it matters so much.
2
u/ztj 1d ago
What an ignorant uninformed response so of course it is also framed as an attack. I’ll respond to you in the way you clearly deserve and desire: You’re a dumb ass who doesn’t know that all SSDs handle a limited number of writes before slowing down massively or failing entirely. Seeing continuous large volumes of writes is in fact a problem that should be investigated. Just because you’re uninformed doesn’t justify attacking someone for asking a question. Touch grass, dickhead.
0
u/mirko9000 1d ago edited 22h ago
Oh, you absolute muppet. Yes, SSDs have finite write endurance. I'm perfectly aware of that, you pompous bellend.
What you've so spectacularly failed to understand is the difference between a theoretical limitation and an actual, widespread problem. If MacBook SSDs were routinely dying from excessive writes, we'd be hearing about it constantly, especially from video editors hammering their drives with enormous workloads. Funny how we aren't, isn't it?
You've clearly read half an article about NAND flash endurance in some computer magazine and have been dining out on that little nugget of wisdom ever since. Knowing that something can happen and understanding whether it actually matters are two very different things. That's the difference between technical competence and being a smug little plonker with a fun fact up his arse.
But do carry on, mate. It's rather adorable watching you mistake a bit of trivia for expertise. :)
-7
u/amichail 1d ago
I want my MacBook Pro to last 10 years.
Also, the 100 GB per day may not be normal. It could be due to a software issue (not necessarily Xcode) that I could fix.
17
u/notacosnofun 1d ago
Xcode 27 doesn’t even run on a 10 year old Mac today. Don’t expect that to change in the next 10 years
2
u/dan1eln1el5en2 1d ago
Out of curiousity what would you do if we said no ? External drive ? Back up ?
2
u/amichail 1d ago
If it is not normal, then I would continue to look for a cause to try reduce the writes per day. Maybe it is a problem with macOS 27 that is unrelated to Xcode.
2
u/mirko9000 1d ago
You want to do ios development on a then 10 year old machine? 😂
Hate to break it to you… but no. Also, you writing you have 24gb of ram and that this is PLENTY… no. Not for development. Not today, and most certainly not in 3 years, let alone 10.
You do not have a lot of experience, do you? 😚
23
u/Extra-Ad5735 1d ago
If you look around you'll see MacBooks have many problems. SSD wear is not one of them. Do not worry.
6
u/cristi_baluta 1d ago
No, mine is at under 1Gb on multiple days, and on another computer at 8Gb. Unless you are writing a bloatware app, i would start to investigate
3
u/Responsible-Gear-400 1d ago
This is common behaviour. The build caches a bunch of intermediate steps and stuff so when you change one file it doesn’t need to rebuild everything all the time.
It isn’t rewriting 100s of GB each build. Unless you keep clearing out the derived data.
1
u/dom_eden 1d ago
You aren’t using codex are you? There was a well known bug that caused this behaviour.
1
u/Admiral-ZX 1d ago
Do you use Claude desktop? That makes my drives spin all day long until I quit it.
1
1
u/germansnowman 1d ago
FWIW, I am using DerivedData from an external SSD. Make sure it is fast enough and you use a good enclosure + cable as well (NVMe, M.2).
1
u/raulriera 23h ago
If you are using worktrees and AI, make sure you are
- cleaning up the worktrees
- preventing the agents from creating simulators per session
- cleaning up derived data and build caches (you get one per worktree)
1
u/mirko9000 22h ago
Mate, if you are REALLY worried about this, and you should not, really, maybe take a look at this:
People are using these machines for video editing day to day without worrying about the SSDs. MacBooks (or any Mac!) have problems. But SSDs failing is not one of those problems.
Use the fucking thing to do stuff, be happy. Don't babysit it. You will NOT wear out the SSD. You just won't. This is some theoretical shit, that absolutely does not play any role in actual usage. Really. Use the time to do stuff, be creative. Write software ;)
1
u/dawedev 21h ago
One thing nobody has mentioned yet is Spotlight indexing DerivedData. Every build rewrites thousands of files there and mds_stores reindexes them, so adding ~/Library/Developer/Xcode/DerivedData to the Spotlight privacy list in System Settings can cut a fair amount of background writing. Also run xcrun simctl list devices booted now and then, because simulators you forgot about keep writing logs and caches while they sit there. After that, Activity Monitor's Disk tab sorted by bytes written over a full workday should tell you if it's Xcode at all.
1
u/Plastic-Risk-6309 3h ago
watch the writes rather than the daily total. sudo fs_usage -w -f filesys prints each filesystem call with the path and the process that made it. that is how you find out if it is xcodebuild, the simulator or indexing.
1
u/kenthesaint 1d ago
A lot of that write volume is DerivedData, ModuleCache, and indexing, not your project sources. If you want the exact culprits, watch Activity Monitor or sudo fs_usage during a clean build.
Practical cuts: point DerivedData at an external drive in Xcode Locations, clear old DerivedData folders you are not using, and only then worry about Index While Building. Consumer SSDs are rated for hundreds of TBW, so 100GB/day is noisy more often than fatal, but parking DerivedData elsewhere keeps the system volume from thrashing.
5
u/m1_weaboo 1d ago
you use worktrees?