TL;DR: Xcode started slowing me down (autocomplete issues, ghost warnings, noisy errors). I’m moving to Neovim for a calmer, keyboard‑first workflow—without going dogmatic or abandoning Apple’s tooling.

After years of building iOS apps in Xcode, I’ve reached a point where the editor slows me down more than it helps. This series documents my move to Neovim—not as a crusade, but as a practical shift toward a calmer, keyboard-first workflow that still plays well with Apple’s tools.

Xcode Frustrations Hit The Limit

I was genuinely happy inside Xcode for a long time. Before iOS, I learned to code on microcontrollers in school—bare-bones tooling with a text editor and a terminal. After university I taught myself iOS, and Xcode became the first “real” IDE I committed to. For a while it felt like the full package.

But as projects grew more complex, the quality-of-life issues piled up and the cracks showed:

  • Autocomplete failed or lagged.
  • Ghost warnings and phantom build errors appeared, then disappeared.
  • Missing compile errors—or worse, completely wrong ones.
  • Occasional UI flakiness around indexing and diagnostics.

More than once I had to drop to the CLI and run xcodebuild just to get the real error message. The moment that finally broke me was the simplest thing: initializers. Autocomplete inits stopped working reliably. My workaround became muscle memory—jump into the struct, type Self.init(...) so Xcode would suggest parameters, copy the generated call, then paste it back where I actually needed it. That’s not the workflow of a healthy tool.

I'm trying to get autocomplete for "init" in the actual initializer since it doesn't work anywhere else in the code.
I'm trying to get autocomplete for "init" in the actual initializer since it doesn't work anywhere else in the code.

Sliding Toward Vim Motions

In parallel, I started taking touch typing seriously. Reading about writing and ergonomics made something obvious: I was losing time every time my right hand left the keyboard for the mouse. I started using Raycast, which leans heavily into hotkeys, and it nudged me halfway toward a mostly‑keyboard workflow. Vim motions felt like the next logical step.

I enabled Xcode’s Vim mode as a gentle introduction. I’m a complete beginner here—I don’t know many motions yet—but I can feel the improvement: fewer trips to the mouse, quicker small edits, more deliberate movement. Motions are available right inside Xcode, and this phase is about learning them well first; Neovim comes after.

Example for Vim Motions
Example for Vim Motions

VS Code and Cursor Didn’t Stick

Whenever I needed a “distraction” from iOS—usually writing backend logic for my apps—I used VS Code or Cursor. They never stuck for me. The way extensions and configuration are structured, the overall look and feel—it’s all taste, but I left those sessions more annoyed than energized. If I’m going to invest in learning something new, I want it to match my motion model and reward hotkeys, not fight them. I enjoy backend work; I’ll be happier doing it in a keyboard-first editor too.

Influenced and Inspired

Watching creators like ThePrimeagen demo their Neovim setups didn’t hurt either. More importantly, I want to grow as a developer, and deeper keyboard-driven editing feels like a skill that pays off everywhere. With today’s ecosystem— with beginner-friendly distros like LazyVim, solid LSP support, and tools that bridge into Apple’s world—the switch is more achievable than ever.

Two resources deserve special mention if you’re iOS/macOS focused:

  • Great end-to-end guide by Wojciech Kulik:
The complete guide to iOS & macOS development in Neovim
In this article, I will describe step by step how to configure Neovim to move away from Xcode. It took me several months to figure it all out piece by piece and to combine it into one working iOS development environment. Hopefully, it won’t take you more than half a day to configure it with my help.
Wojciech KulikWojciech Kulik
  • Excellent xcodebuild.nvim plugin also by Wojciech Kulik for bridging Xcode builds into Neovim:
GitHub - wojciech-kulik/xcodebuild.nvim: Neovim plugin to Build, Debug, and Test applications created for Apple devices (iOS, macOS, watchOS, etc.)
Neovim plugin to Build, Debug, and Test applications created for Apple devices (iOS, macOS, watchOS, etc.) - wojciech-kulik/xcodebuild.nvim
GitHubwojciech-kulik

More broadly, Wojciech’s work gave me the confidence to take the last step and actually switch.

Not Going Dogmatic

This isn’t a breakup letter to Xcode. There are still tasks that only happen there, and I plan to keep it close for the jobs it does best. The goal is to cut out the frustrating parts of my day: features that lag, autocompletion that fails, waiting for the editor to catch up. Neovim can take over those areas while Xcode remains my safety net for Apple‑only tooling.

Also, I’m far from an expert. I’m exploring this setup for myself and sharing along the way in the hope it helps, inspires, or at least entertains someone on a similar path.

Will still use Xcode besides Neovim
Will still use Xcode besides Neovim

Early Impressions and What’s Next

I’m brand new to Neovim and, for now, I’m slower than in Xcode. I’m looking things up constantly. At the same time, I’m learning a ton, and I really like the look and the responsive feedback Neovim gives me—it might still be the honeymoon phase, but it’s motivating.

Coming up next:

  • Part 2: Setting up Neovim with the LazyVim distro
  • Part 3: iOS/macOS development setup (SourceKit‑LSP, builds/BSP, linting, testing) and my Swift configuration, plus how I keep parity with Xcode’s debugging/build tools and where the gaps still are

In the next part I’ll set up Neovim with LazyVim. The Swift configuration and how I keep parity with Xcode’s debugging/build tools—plus where the gaps still are—will follow in Part 3.