2. Reformat (clean install) machine every 1-2 months.
3. Upgrade machine every 1-2 years.
* Regularly export and back up your Xcode developer profiles and certificates.
* If you're thinking about doing something fancy, don't. It will come back to haunt you in ways you cannot even imagine.
Source: 10+ years of iOS development.
I haven’t found any of this to be necessary. I only reformat every 2-3 major releases at most and sometimes go most of the lifetime of a machine without reformatting, and I have various backend and cross platform desktop dev stuff set up on the same machines. Have rarely if ever had issues with Xcode acting up…
Is there something we’re doing differently to get such dramatically different outcomes?
This drove me crazy when I developed on Mac. It must be a combination of Homebrew issues and MacOS idiosyncracies, because there's no escaping the feeling of a "dirty" machine. A few good months of MacOS dev work can make a formidable machine feel like a decades-old UNIX environment.
If you do general-purpose development on MacOS, I beg you: please use Nix. The dev experience is head-and-shoulders above Homebrew or MacPorts, and the package selection is immense. Learn Flakes, and your cross-platform dev experience will feel downright magical.
Here's my Nix setup for my M1 Macbook using nix-darwin, if it helps anyone: https://github.com/dustinlyons/nixos-config
It's also interesting to hear comments from the Nix detractors here. There's ample room to criticize the language and even the design philosophy behind the package manager, but it's a shame that most people never give it a "proper shot". Maybe that's the fault of Nix maintainers though.
The main issue (I think) is that it boils down to "a worse shell script" shaped in a LISP kind of wrapper. Plenty of people know about LISP too but will simply not even look at it because it is too different. Even if you take away the functional paradigm it just doesn't look like anything that can map to an existing knowledge base. This is also why C-esque languages (and I'm talking about the non-edge-cases here) are so prevalent and successful; they don't have to be 'the best' or even 'good', they just have to be easy to map to existing knowledge to be useful. And Nix doesn't do that.
Removing brew stuff is trivial, and with sip being the default it’s really hard to put the machine in a state that requires a clean install.
I’m really unsure how someone could put up with clean installing needing to be part of their workflow for that long without questioning whether that’s normal or not.
Even in the pre-sip days, I’d have to go out of my way to make my Mac unusable since it’s a very opinionated platform of isolating data/apps into very specific locations.
unless a kext is involved. Then all hell breaks loose.
What are the symptoms of an ‘unclean’ Mac? It should be possible to say with some exactness what’s causing them with the use of diagnostic tools like ‘top’, or just the Activity Monitor app.
I’ll admit that _fixing_ issues might not be straightforward - but I can’t recall the last time I reinstalled my Mac aside from buying a new one with a new installation - although I don’t think that should really count...
Dave is out walking early one morning. The streets are quiet, but for one man sprinkling a white powder along the middle of the road. Intrigued, Dave approaches the man and asks what he is doing.
The man explains he is sprinkling elephant powder - he does it every morning. Dave is visibly puzzled. The man continues “it keeps the elephants away”.
Dave, still puzzled, says “But there are no elephants here!”.
In agreement the man exclaims “Great stuff, isn’t it!”
And Xcode itself does not help. I install Xcode. Well, actually, I didn't, because you need to actually start Xcode for it to completely install itself. It seems to come with a complete set of command-line tools; I can compile and run plain Unix stuff from the command line. Great. Except when you try to run Homebrew, that complains that you don’t have the True Command Line Tools; you need to run xcode-select --install to install what appears to be a completely different copy of the same things. Wtf?
Just don’t run things as root you don’t understand / copy/paste blocks of shell script because stack overflow says so
Homebrew is open source. Just fork it. They don't need Mike McQuaid.
The "problem" is that 3p developers don't want to get with the program, and insist that the only possible way to install their magic sauce is to spam files all over the system. And that therefore there must be a super-complicated set of add-on tooling to deal with tracking all these files and their dependencies.
It's job security, of a sort, I guess.
- That's only for GUI applications. Almost everyone reasonable developing GUI apps for macOS uses this method. However, CLI apps also have to update $PATH, which involves running a script. Package managers handle doing this better than macOS's frameworks because they were designed to do such a thing.
- There's absolutely no system for updates. Each app has a separate daemon consuming background resources just to check whether it has an update available for itself, and every app has a different way of actually installing the update. Just try having a system with Audacity, Adobe, Chrome, and Microsoft Office installed and you'll see what I mean (Microsoft Office and Adobe have a separate app installed just to update their original apps, Chrome installs updates in the background by sneakily updating its .app file, and Audacity just tells you an update is available and makes you restart the app to install it). This is why Homebrew manages .app files despite the fact that a “package manager” already exists for these*.
[note] I'm ignoring the App Store because most macOS developers don't submit their apps for the App Store because it's restrictive in many ways
- Using a package manager allows saving storage space and RAM usage for dependencies – only one copy of a library is loaded into memory and stored on disk
This is why apps to manage packages (e.g. Homebrew) exist. While we can debate the merits of Homebrew itself in terms of how well it does that, Homebrew does, in fact, solve a problem. If you believe it's not necessary to solve this problem, you can install the apps yourself, of course.
Hey now, I've been running the same Arch installation for close to a decade with tons of random stuff tried and installed on it, borked the whole thing a few times but managed to recover, and it doesn't feel old at all. It is much leaner than my partners one year old MacBook in fact, even if the specs of the machine are worse!
Also, what is/are Flakes?
Re: flakes, IMO, don't worry about them too much, Nix is complicated as it is.
IME while the package selection is indeed huge it does happen the odd package is missing or temporarily broken. In that case, I just use Homebrew via nix-darwin.
[edit]: okay, maybe do learn about Flakes, I've read parent's comment and got the part about helping with cross-platform stuff, plus Flakes are the future. But you might not need those features right away, people have been happily using Nix for years without them.
The thing is that as every OS it needs maintenance, every year or so I take a day to cleanup the system, remove caches, leftover from old installations, fix things that are not working, remove unused brew packages and applications that I no longer need, upgrade any software running on the machine, etc.
> If you do general-purpose development on MacOS, I beg you: please use Nix
After using macOS for a long time, I learned that the best thing to do is to use whatever stock configuration you have and touch as few things as possible. One example, I encountered a bug in React Native caused by the fact that in my PATH I had the GNU coreutils instead of the stock macOS one. If you keep things simple it's less likely that things break and if they break it's easier to fix them.
On a second machine that started from 10.5 onwards (on a PowerMac G5) I have a nearly identical setup that ended up in the same state but also had the hop to M1 done. No "eek my Mac feels so dirty" there either.
Granted, I have a Debian install on yet another machine that has been with me since Woody (2002-ish), and that is similarly just upgraded over the years, switched from 32-bit to 64-bit in-situ, switched between ext2/3, ext4, ZFS, root-on-zfs, from BIOS to UEFI, and it still works great.
I think that while the OS and vendor definitely have an impact, it's really going to depend on the user how it works over time.
Just a cleanup of ~/Developer/Xcode/DerivedData every once in a while seems to keep it ticking over for me.
There was a time when the cache of simulators from every Xcode would build up and eat all you disk space just appearing under the amorphous grey 'System Data' categorisation under the 'About this Mac...' storage tab, but think they might have finally sorted that out.
I do still need to relaunch Xcode every few hours as it struggles with 100s of files open and suddenly I get a keyboard lag or copy paste refusing to work.
I'd definitely like to see something more lightweight for actual code editing, maybe de-coupling the SDK, and providing a decent LSP client that can be used with any language... but I don't see that happening anytime soon.
As for removing old simulators after you remove an old Xcode, run
$ xcrun simctl delete unavailable
Is Xcode annoying at times? Sure. Do I like deleting the DerivedData folder once in a while? No.
But I really can't relate much to what you wrote except maybe upgrading your machine often.
What are you even talking about? This is modern macOS, not Windows XP.