Ask HN: Xcode users – how do you make it more usable? | Hacker News Reader

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

78 pointsisomorph72 comments

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.

View on HN

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.

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.

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.

Also a cross platform mobile dev, couldn't agree more. Feels like I'm in a different OS when I have Android Studio full screen. There are some things I like about it but if I could stick 100% to iOS strictly from a devex point of view I would.

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.

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.

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.

I’ve been developing on a Mac with XCode for years and never done this. It’s just not necessary.

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

Nix 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

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

I've got something very similar! 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.

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

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?

It 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

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

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

The problems associated with impure programming environments are well-documented, I should hope I don't need to repeat them here. Anecdotally though, the packaging for lots of popular programs (rabbitmq, minio, mongo) is pretty consistently terrible. Many packages lack behavioral parity between x86 and ARM (software is installed to different locations) and linking becomes a total headache when your libraries are spread out across /opt/ and your lib folder. On top of that, Homebrew is extremely slow and processor-intensive, and demands root access for trivial operations. It's unsafe, impure, and wastes my time.

What are you talking about? Homebrew flat out refuses to work under sudo.

Are you seriously suggesting using system-wide installations and modifications to run development environments? Even if all else fails, you should at least have a chroot for that. Or if you don't know how that works, virtual machines have been a thing for decades. Vagrant exists. Containers exist, heck, even in a user-friendly button-click interface with Docker...

Googling around for answers to Mac related problems, I can easily see that about half the people "answering" questions are completely clueless, just cargo-culting various voodoo stuff. I suspect that among the other half, half of those are equally clueless, but I can't tell which ones because I'm myself not mac-savvy enough!

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?

For me it’s 15 years of upgrades, including betas. Everything is fine

Just don’t run things as root you don’t understand / copy/paste blocks of shell script because stack overflow says so

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

Why hasn't Apple created its own official package manger?

Homebrew is open source. Just fork it. They don't need Mike McQuaid.

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

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

Sparkle Framework exists.

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

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

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

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

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.

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

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.

Under 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

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?

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

LOL, I just deleted my sibling reply... you put it so much better than I could.

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.

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 ;-)

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.

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.

Xcode stability has markedly improved since 2016, FWIW.

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.

Yeah, nobody should be using UIbuilder and storyboards any more. swiftui is so much better, faster, usable, extensible.

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 :)

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.

Reply on news.ycombinator.com