Building IOS Apps With Doom Emacs | Wassim MansouriI shipped SPEEM, my first iOS app, from Doom Emacs. Not from Xcode.<br>I don&rsquo;t mean I just edited a few files in Emacs and switched back when it was time to build. I mean the whole loop: write Swift, build, boot a simulator, install the app, launch it, stream logs, restart LSP, scaffold new projects. All from inside Emacs, all driven by SPC i keybindings I wrote myself.<br>This post is about how, and why it&rsquo;s even possible.<br>TL;DR#<br>Apple ships a small army of command-line tools, xcodebuild, xcrun simctl, xcrun swift-format, sourcekit-lsp, and most iOS developers never touch them directly. Xcode is just a fancy wrapper around them (of course with many other utilities built into it). If you&rsquo;re willing to glue those tools together yourself, you can build a real iOS workflow in any editor that lets you run shell commands and read process output. Doom Emacs happens to be very, very good at that (or any Emacs distro for that matter really).<br>The result, for me, is a ~1000-line modules/ios.el that gives me an SPC i b to build, SPC i s to install and launch on selected simulators, SPC i l to stream filtered logs, SPC i n to scaffold a new SwiftUI project, and a few more things I&rsquo;ll walk through below.<br>Why I did this#<br>I live in Emacs. I&rsquo;ve been using Doom Emacs daily for 4 years: Rust, Elixir, Kotlin/Android, web, org-mode, Magit, all of it. When I came back to iOS development for SPEEM, I tried Xcode for two weeks and it felt like wearing someone else&rsquo;s shoes. Not bad shoes. Just not mine.<br>I also have a multi-language config. I have a modules/rust.el, a modules/elixir.el, a modules/kotlin-android.el, a modules/web.el, and so on. Each language has the same shape: a major mode, LSP, keybindings for build/run/test. iOS being the one exception felt wrong.<br>So I sat down and wrote modules/ios.el. This is what&rsquo;s in it.<br>What Apple actually gives you on the command line#<br>Before any Emacs Lisp, it helps to know what&rsquo;s even there. When you xcode-select -p you get the active developer directory, which contains all the tools Xcode uses internally:<br>$ xcode-select -p<br>/Applications/Xcode.app/Contents/Developer

Inside that, the tools that matter for building and running an iOS app from a terminal are:<br>xcodebuild , compiles your .xcodeproj or .xcworkspace. It accepts a scheme, an SDK, a destination, and a list of actions like build, clean, test. This is what Xcode itself calls when you press Run.<br>xcrun simctl , controls the iOS simulators. Boot, install, uninstall, launch, terminate, take screenshots, override the status bar. Anything you can do clicking around in the Simulator app, you can do with simctl.<br>xcrun swift-format , Apple&rsquo;s official Swift formatter. Works on stdin/stdout.<br>sourcekit-lsp , Apple&rsquo;s language server for Swift. Ships with Xcode at Toolchains/XcodeDefault.xctoolchain/usr/bin/sourcekit-lsp. This is what gives me completion, jump-to-definition, errors, refactors.<br>xcode-build-server , not from Apple, but essential. It generates a buildServer.json that tells sourcekit-lsp how the project is actually configured (build flags, modules, etc). Without it, LSP works but it&rsquo;s blind to half your project. brew install xcode-build-server.<br>xcodegen , also not from Apple. Generates an .xcodeproj from a small YAML file. I use it to scaffold new projects so I don&rsquo;t have to ever open Xcode&rsquo;s project editor.<br>Once you know those exist, the rest is just orchestration.<br>The structure of my Doom config#<br>My Doom config is split into modules. The top-level config.el is tiny:<br>;;; config.el -*- lexical-binding: t; -*-

(setq doom-font (font-spec :family "Fira Code" :size 13 :weight 'semi-light)<br>doom-variable-pitch-font (font-spec :family "Fira Sans" :size 14)<br>doom-theme 'doom-monokai-pro<br>display-line-numbers-type t<br>org-directory "~/org/")

(load! "modules/core")<br>(load! "modules/lsp")<br>(load! "modules/rust")<br>(load! "modules/elixir")<br>(load! "modules/ios")<br>(load! "modules/kotlin-android")<br>(load! "modules/web")<br>(load! "modules/slint")<br>(load! "modules/projectile")<br>(load! "modules/org")<br>(load! "modules/tools")<br>(load! "modules/keybindings") ; all map! calls live here, loaded last

The iOS-specific bits live in modules/ios.el, and the keybindings for them in modules/keybindings.el. I keep keybindings separate from feature code so that everything map! is in one place, easier to grep, easier to reason about.<br>On the Doom-modules side, init.el enables the standard (swift +lsp) language module:<br>:lang<br>(swift +lsp) ; who asked for emoji variables?

That gives me swift-mode and LSP plumbing for free. Everything below is built on top of that.<br>Pointing LSP at the right sourcekit-lsp#<br>There&rsquo;s a subtlety here. There are usually two sourcekit-lsp binaries on a Mac: the one in /Library/Developer/CommandLineTools/... and the one inside the active Xcode. They&rsquo;re not always the same version, and using the wrong one can break...