Ask HN: Xcode users – how do you make it more usable?
I’ve come from JS in VSCode (with loads of extensions) to Swift in Xcode.
In XCTest, I miss the red and green diffs between expected output and actual output.
In Xcode itself, I miss the ability to perform code refactoring easily (extracting code to new files etc - more than just extracting to new functions).
I also miss linting / prettier.
What tools and plugins for Xcode do you all use to make developing Swift in Xcode faster and easier? General Xcode hints and tips welcome.
75 comments
[ 2.9 ms ] story [ 142 ms ] threadI try to use the command-line tools instead.
xcodebuild and xcrun are solid. check out xcpretty[^1] to improve the output of xcodebuild.
Here's a blog post that someone wrote about using xctest from the terminal with xcpretty to make the output nice: https://mokacoding.com/blog/running-tests-from-the-terminal/
[^1]: https://github.com/xcpretty/xcpretty
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.
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
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?
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.
https://www.jetbrains.com/objc/
for "prettier" all I've ever needed is just auto indentation of a block, which works fine
other than that, I just submit to what Xcode is and live with it
- Xcode is an acquired taste. A bit slow and crash prone, but most of my issues came from the frameworks. Completion and linting were good enough and the integration with dtrace was enough to help me move faster than my colleagues. I even did use Xib :D
- I tried multiple time app code: it’s not good either. In fact, I don’t like most of the jet rains product, but they’re easier to set up than the competition so….
- but now I’m back to nvim or emacs.
I don’t develop as my job anymore, so my tooling seems pretty barebone to what seems to be the trend :) I nearly make do with the Processing/Arduino IDE and they’re both horrible.
- Writing clean/idiomatic Swift. This might sound silly but a lot of SourceKit instability is tied to things that are code smells, like deeply nesting closures and ridiculously long optional chains. Writing “Objective-C in Swift” where you’re trying your best to ignore types will also make SourceKit grumpy.
- Avoiding huge frameworks. Small focused single purpose libraries are fine, but gangly monster types can cause problems (and with UIKit available, likely unnecessary).
- Avoiding storyboards. For several years I’ve been going code-only on iOS, with XIBs being used only on macOS because there they’re more natural. Storyboards are more trouble than they’re worth on either platform.
- Using SwiftUI only for small, focused components. It still needs some time in the oven to be able to compete with code-only UIKit for speed/stability.
With those Xcode is quite snappy and reliable, allowing me to work all day with no issue.
But wow, the hoops you jump through to use it with c++ - via obj-c (And iirc can't use .mm files either). Im sure I wasn't helping things by exposing that to javascript too :)
[1] https://github.com/realm/SwiftLint
The “rename in project” and “rename in scope” functions are quite neat.
2) Check out SwiftLint: https://github.com/realm/SwiftLint
I have not used it in a while, but it comes with good defaults and is highly customizable to your own preferred Swift style.
Take a look at this 'Meet Swift Package Plugins' talk from WWDC 22 which goes into detail: https://developer.apple.com/videos/play/wwdc2022/110359/
What's nice about this is that it's not restricted to Xcode, it can be integrated with your CIDI, too.
I personally have little problem with Xcode now. My recommendations would be: don't use the built-in source control integration, it mostly sucks. Get an M1/M2 Mac, the speed boost is great. Use a lighter weight editor (not IDE) for editing data files, large text files (>5k lines) and for anything that's not Swift/Obj-C/UI work. And lastly, stay up to date. Xcode has crashed much less for me on 12/13/14 than it did on ~9/10/11.
Another approach is to find the bits that are _great_ and that you don't get with other platforms. The debugging, particularly UI debugging with the visual hierarchy is great. When you have a good set of schemes set up for different purposes, potentially tied in to scripting in the build process, you can get quite a flexible system for running apps under different environments.
I had to use XCode in grad school for a single iOS class and ended up switching to app code for any parts of the assignments I could. At work the developer that switches back and forth between iOS dev and Android dev and he has a similar work flow of doing as much as possible in AppCode until forced to use XCode.
The fact that JetBrains uses its own UI toolkit is the cause of a lot of the friction I experience, it's buggy on multi-monitor systems, focus works in a different way interrupting many micro-interactions. The pseudo-windows-in-a-window model feels wrong on macOS, it's the only application I know like it and it's a very Windows like model.
People value different things, and I know many get lots of value out of JetBrains products. I just suspect that most people working on a Mac because they like Macs will not align well with the JetBrains products.
I use Xcode but do most of my code editing, building and debugging in Emacs; I have to use Xcode directly for all the UI plumbing. The best I can say is a weak, "not as bad as jetbrains"
On the contrary, XCode seemed to be incredibly feature crippled and going backwards (in terms of how they have a counter-intuitive design for the average developer). If It wasn't for the iOS work I had to do, I would have never even opened that IDE for a second time. I hated how Apple forced us to stick to Xcode and change our orientations and get used to their IDE, without leaving a second option...... until AppCode finally arrived. This is the best thing that happened to iOS development. Similar to Android finally partnering with Jetbrains to get out the Android Studio.
Long live Jetbrains.
If you take a look at the functionality that you are after, perhaps moving out outside of the scope of the editor may help you far more than trying to re-compose the editor to be more like something that it isn't.
I personally don't have much of an issue switching between them, I mostly prefer Sublime Text over everything but it doesn't have the features I need for everything so I just use whatever tools the project needs the most. For iOS and macOS the whole workflow split in two parts: a common CI part where all the external tools run, and the in-editor part where you mostly just write the features you want. This applies to AppCode too, but we also do that for C# code where it really doesn't matter if you do it in Rider or Visual Studio on Mac, Visual Studio on Windows or Visual Studio Code anywhere. In the end, the pre-commit and CI tasks will do the common workflow anyway.
While I understand that people enjoy digging deep into the features of a single specific IDE to do everything, in reality this is probably not the 'best of all worlds', unless you are working solo.
The other thing (since Xcode‘s clipboard feature is IMO clunky) is to use a clipboard manager with the history set to a decent size. I use Paste (happens to come with SetApp) and never once lost a copied snippet - it‘s rock solid. I’ve developed a habit of just copying whole files in case I want to revert to that state (or partially) later.