I use it almost weekly to clear out the tens of gigabytes of garbage Xcode regularly generates.
(This doesn't necessarily apply to apps who don't put things in Caches folders…)
How about not trying to guess when the user needs the space?
For a while, the browser could reasonably assume that it was the only application that used this strategy, and it was a true assumption. Now that native executables are being replaced by web-based applications, every program is trying to maximize its RAM usage, with predictable results.
Of course getting swapped out is usually fine too.
Huge memory usage is more likely because they don’t know how to check for memory leaks, not because they’re trying to use it.
https://en.wikipedia.org/wiki/Time-of-check_to_time-of-use
Similar assumptions about filesystems fail if they do data compression or dedupe files - you can easily overestimate how much space something is taking.
That's what sustainability looks like in the eyes of a hardware supplier.
Lol.
That said, I think that code signature on Xcode does let you delete whichever sdks and simulators you want without invalidating the main package signature? (This is _very_ much an "I think" case). That would remove the "force" element you find to be a problem.
of the download/onboarding! Which is not what I should spend most my time with Xcode anyway.
I would eagerly spend 5 minutes more choosing if I could reduce the several hours (sic!) download time and save insane amounts of energy.
No, of the runtime use. There is no need to have a up front "what hardware are you planning to target?" "what OS versions are you planning to target?".
The several hour download when high speed internet is not available is obviously annoying, but it is not remotely "insane amounts of energy".
But on the other hand you don't get in a position where you think you've made the correct selection, and then a little bit later you go to do something and can't, so have to wait on another download, right when you were wanting to do something.
The approach of "everything in one bundle" is the correct option from a usability point of view, which is clearly what has been favored. It is also clearly and reasonably frustrating that that one download is large and on slower connections is very long. The thing is that the single download means that the install path is "set it to download; go to bed; get up and use freshly downloaded gigantic bundle" with no risk of thinking your done, but then not having everything you need. I suspect the latter would result in many more people complaining on twitter, or needing support.
I do want to be clear though that I agree the large download is annoying, and surely something could be done to reduce the size.
du -h -d0 Xcode.app
12G Xcode.appI'll flush it, from time to time. I may also delete old archives. I have hundreds of them.
I find those symbols to be kinda worthless, though.
My best tool for diagnosing a crash report is a Ouija board.
Frankly, it’s not been much of an issue. I tend to be super-anal about Quality, and post-release crashes are rare as hen’s teeth; which makes the ones that do happen, more important to diagnose.
I usually get a general idea of where the crash happens, and scanning the source, has always shown me the issue.
There are a ton of services that handle all the “mechanical” stuff for you (e.g. AppCenter, ex-HockeyApp), and you can just look at symbolicated crash in your browser.