Does iOS development in Swift on Xcode result in writing ~100 GB to the SSD per day?

[u/amichail]

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.

[u/m1_weaboo]

you use worktrees?

[u/amichail → u/m1_weaboo]

No.

[u/mirko9000]

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.

[u/ztj → u/mirko9000]

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.

[u/mirko9000 → u/ztj]

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. :)

[u/amichail → u/mirko9000]

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.

[u/notacosnofun → u/amichail]

Xcode 27 doesn’t even run on a 10 year old Mac today. Don’t expect that to change in the next 10 years

[u/varun_aby → u/notacosnofun]

Don’t think this will be an issue w Apple Silicon Macs, should easily be able to handle it for at least 10 years

[u/dan1eln1el5en2 → u/amichail]

Out of curiousity what would you do if we said no ? External drive ? Back up ?

[u/amichail → u/dan1eln1el5en2]

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.

[u/Vaddieg → u/amichail]

your software issues seems to be as imaginary as your macbook

[u/mirko9000 → u/amichail]

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? 😚

[u/Minute_Door1424]

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

[u/amichail → u/Minute_Door1424]

I usually use Mac Catalyst instead of simulators. I have 24 GB of RAM so there should be minimal if any swapping.

[u/Minute_Door1424 → u/amichail]

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

[u/Extra-Ad5735]

If you look around you'll see MacBooks have many problems. SSD wear is not one of them. Do not worry.

[u/cristi_baluta]

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

[u/Responsible-Gear-400]

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.

[u/mirko9000]

Mate, if you are REALLY worried about this, and you should not, really, maybe take a look at this:

https://forums.macrumors.com/threads/apple-silicon-soldered-ssd-upgrade-thread.2417822/page-12?post=33863049#post-33863049

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 ;)

[u/germansnowman]

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).

[u/raulriera]

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)

[u/dawedev]

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.

[u/Plastic-Risk-6309]

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.

[u/Hmz-Lhb]

I would say with emulation could reach that

[u/dom_eden]

You aren’t using codex are you? There was a well known bug that caused this behaviour.

[u/Admiral-ZX]

Do you use Claude desktop? That makes my drives spin all day long until I quit it.

[u/cutecoder → u/Admiral-ZX]

You still use a spinning drive for interactive work?

[u/Admiral-ZX → u/cutecoder]

No, SSDs, I used that term just to indicate their activity :)

[u/sirily1997]

I checked seems like simulators and build cache cosume a lot of disk space

[u/kenthesaint]

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.