5 ms·
1. Have a dedicated Apple machine for Xcode. Don't put anything else on it. 2. Reformat (clean install) machine every 1-2 months. 3. Upgrade machine every 1-2
by zkirill 4y ago
1. Have a dedicated Apple machine for Xcode. Don't put anything else on it.
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.
- laumars 4y agoMan that sounds depressing. I didn’t even reformat macOS 8&9 and Windows 9x that frequently, and I consider them the dark times for operating systems.
- pivo 4y agoI’ve been developing on a Mac with XCode for years and never done this. It’s just not necessary.
- smoldesu 4y ago> 2. Reformat (clean install) machine every 1-2 months. 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.
- dlyons 4y agoNix makes my dev life on MacOS so much more manageable. The "dirty" feeling has, for the most part, gone away. I'm also able to easily share common config between other machines I use. Here's my Nix setup for my M1 Macbook using nix-darwin, if it helps anyone: https://github.com/dustinlyons/nixos-config https://github.com/dustinlyons/nixos-config
- kitsunesoba 4y agoIt’s been a long time since I’ve played with Nix, do you still need to maintain a nixfile or whatever? Maybe I just wasn’t “holding it right” but I recall not being able to just pop open a terminal window and do “X install Y” like with traditional package managers which was a turnoff.
- smoldesu 4y agoI've got something very similar! https://github.com/toasterrepairman/boostrap/tree/main/nix https://github.com/toasterrepairman/boostrap/tree/main/nix 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.
- oneplane 4y agoLots of people can't "give it a shot" because it is so different from everything else. That's also why it has no foothold in any corporate environment. Even the amount of small businesses that use Nix for development is so small it's insignificant (but is exists). 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.
- waspight 4y agoI still use the same installation of macOS as I began using seven years ago. I only moved it to new MacBooks a few times using the built in solution for that. I thought that formatting like crazy was a windows thing?
- willio58 4y agoIt is, anyone who needs to clean install isn’t running commands right, or doesn’t fully understand what they are running when they run commands
- dagmx 4y agoEspecially because it’s all relatively self contained. 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.
- jrmg 4y agoOr it’s an elephant powder, and they just think that it’s doing something. 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!”
- SOLAR_FIELDS 4y agoIt’s crazy how long this issue has existed. Homebrew complaining about XCode command line tools being an incorrect/outdated/nonexistent version is an issue I’ve faced every few months since I started developing on a Mac almost a decade ago.
- throwmcquaid123 4y agoWhy hasn't Apple created its own official package manger? Homebrew is open source. Just fork it. They don't need Mike McQuaid.
- 95014_refugee 4y agoThere is one; you drag the app into /Applications to install it, and you drag it into the Trash to uninstall it. 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.
- odo1242 4y agoThe main issues with dragging .app files (or their cousin, .pkg files) are: - 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.
- capableweb 4y ago> like a decades-old UNIX environment 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!
- MrWiffles 4y agoNix? Are you talking about the package manager from NixOS? I didn’t know that was MacOS-friendly these days, neat! Can you link us to any good articles discussing differences between it and Homebrew? Also, what is/are Flakes?
- lambdaba 4y agoNix can manage Homebrew (via nix-darwin) too! home-manager works great too. 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.
- deleted 4y ago[deleted]
- alerighi 4y agoI bought my Mac in 2015 and I've upgraded from every release of the OS to the other, used for development, even changed hard drive (good times when you could do it) and copied my old installation with Time Machine. When I started using it the standard was MacPorts, then brew started to gain interest and I switched to it. I used Xcode, Android studio, IntelliJ, and a ton of development tools, and still it works without any issue. 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.
- oneplane 4y agoThis makes no sense at all. I'm on Monterey right now, with a OS install and user that has been with every upgrade and Time Machine migration to new hardware since 10.3 (2003). That's 19 years of upgrades, virtual machines (which always have programs that mess with networks, kernel extensions and file handlers), package managers (including Fink, Macports and brew) and devtools (including many JetBrains products, Xcode, Sublime Text, BBEdit, VSCode, Atom (which is now dead), Docker Desktop which I replaced with Rancher Desktop and then have Podman on the side. Even the Apple mail app has had its database upgraded all those years, as did iTunes (which eventually became Music). 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.
- dagmx 4y agoWhy on earth are you clean installing so often? Are you polluting your main environment with a bunch of homebrew libraries per chance?
- tcldr 4y agoReally? Xcode has its issues but it isn't Charles Manson... 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.
- generalpf 4y agoUnder Preferences > Locations you can make DerivedData relative to each project and I recommend you do that so different apps you work on don’t force you to wipe all the artifacts from all apps when you clean it manually. As for removing old simulators after you remove an old Xcode, run $ xcrun simctl delete unavailable
- kitsunesoba 4y agoBeen doing iOS dev professionally for 7 years, and have been tinkering with Mac development since OS X 10.1 or so. 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?
- thought_alarm 4y agoThis is great advice for people who don't know how computers work.
- jmull 4y agoLOL, I just deleted my sibling reply... you put it so much better than I could.
- jdmoreira 4y agoSorry. Equally 10+ years of daily iOS development. 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.
- deleted 4y ago[deleted]
- hyperjeff 4y ago20+ years of Xcode. This advice is ludicrous. Something traumatic must’ve happened 10 years ago to produce this policy. I only ever reboot for system updates and run zillions of things happily along with Xcode and many other full dev environments at the same time.
- diebeforei485 4y agoDevCleaner (free app on Mac App Store) deletes old simulators and DerivedData etc.
- ofrzeta 4y agoThat sounds like the Apple way for sure. Don't forget to zap the PRAM ;-)
- OrderlyTiamat 4y agoThis has to be satire right? There is no way apple development actually requires an amount of restrictions and effort like this?
- rewgs 4y ago> 2. Reformat (clean install) machine every 1-2 months. What are you even talking about? This is modern macOS, not Windows XP.