▲ 78 points

Ask HN: Xcode users – how do you make it more usable?

by isomorph·3y ago·72 comments·view on hn ↗

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.

72 comments

Lots of people mentioning AppCode as a replacement, but damn JetBrains apps suck if you're used to macOS. Basic things like windows misbehaving, poor multi-monitor support (yes, really), and being unusably slow for almost every aspect of the user interface. I could go on, but if you hate Xcode I think you'll find AppCode to be just a different set of crap. If you like using a Mac you'll positively hate AppCode.

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.

I've never used Jet Brains products on anything besides MacOS for close to a decade and have been doing professional Android development with Android studio for almost that long. I don't agree with any of your complaints and find it hard to believe they were ever true unless you used their products an extremely long time ago before they got popular.

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.

I use Android Studio on a ~weekly basis, and have tried to get into PyCharm many times. It's clear that the JetBrains team have a very different view of what UX is and should be than Apple and most developers targeting macOS.

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.

Like danpalmer I can't stand the jetbrains tools I've used (PyCharm, IntelliJ). Just seems like a lot of clicking and inconsistent interface.

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"

Not sure if you had any setup issues, but Jetbrains IDEs have been just as great on Mac OS as on Windows or Linux. In some ways, they were even better vs Windows/Linux because of the better font rendering as a result of Retina + the high resolution displays. The only change I had to make was the set the keymap to classic(was used the classic layout on Windows). Everything else worked just great.

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.

More nuanced ideas... I set up my keyboard shortcuts to be as close to VSCode as I could so that Xcode and VSCode were very similar to write code in. I learnt the shortcuts for the UI - toggling panels and things, that was quite beneficial.

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.

1) Here are some tips & tricks for refactoring: https://developer.apple.com/documentation/xcode/finding-and-...

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.

I don't spend very much time in Xcode.

I 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

Check out AppCode by JetBrains. It reduces the need to use Xcode by 90%.

https://www.jetbrains.com/objc/

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.

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

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

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

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

> 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!

Really? 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.

Why on earth are you clean installing so often? Are you polluting your main environment with a bunch of homebrew libraries per chance?

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

20+ 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.

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

This is great advice for people who don't know how computers work.

This has to be satire right? There is no way apple development actually requires an amount of restrictions and effort like this?

> 2. Reformat (clean install) machine every 1-2 months.

What are you even talking about? This is modern macOS, not Windows XP.

DevCleaner (free app on Mac App Store) deletes old simulators and DerivedData etc.

That sounds like the Apple way for sure. Don't forget to zap the PRAM ;-)

By switching to AppCode. In my experience Xcode sucked

Swiftlint[1] is nice and can be integrated into Xcode’s warning panel. For auto-formatting, you can press CTRL-i on any selection to auto-format.

[1] https://github.com/realm/SwiftLint

I developed in ObjC till 2016, so my opinion are dated but:

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

For me the biggest factors for making Xcode “happy” are:

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

Xcode stability has markedly improved since 2016, FWIW.

I think your main pain point stems from the difference in ecosystems. This is not even a good/bad thing, just a "things are done a bit different" thing.

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.

One thing I‘ve really come to appreciate (applies to all code editors) is to actively use keyboard shortcuts for moving selected lines up/down, and for deleting the current line. Vim users will be used to this anyway, but for the rest of us it’s a great way to code faster.

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.

Xcode definitely has it's issues but I think they're moving to a system where Swift, and the Swift Package Manger specifically, can provide a bunch of this kind of functionality.

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.

Use xcodebuild and forget xcode

I have one single tip. Don't use storyboards / nibs. Write all you view code by hand. Stackviews and your own layer of helper functions are you friend. I can write UI faster in code than would ever be possible in nib tooling. To say nothing of managing conflicts in those files. You won't look back!

I’d just switch to JetBrains AppCode, but I’m very partial to their IDEs.

Remove the print key binding and bind quick open to cmd+P

Why haven't I thought of this. I frequently accidentally hit the print shortcut, and the quick open shortcut is ridiculously inconvenient for such a common navigation action.

Why the heck is Cmd+P the key binding for Print, in Xcode, in 2022? Has anyone ever printed anything from Xcode?

for me, main thing is turning on the (now native) vim emulation which is decent though missing some things (dot operator please!), and learning the keyboard shortcuts for the various UI panes

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

Everything you mentioned is possible and going from Xcode => VSCode I have the same experience

You get used to it. I don’t find myself missing any of those functions.

VM on pc with lots of ram. Works fine for me.

How are you running a macOS VM on Windows? I’ve tried basically every combination of hypervisor and macOS version since Mojave and I can hardly ever get them to install right, let alone run even kind of well.

You don't. You ignore it and use AppCode instead.

You do, just learn xcode instead of learning appcode. Get used to instruments, debugger, etc

I improved Xcode usability by ceasing to make iOS apps.