Building iOS Apps with Doom Emacs | Hacker News Reader

Building iOS Apps with Doom Emacs

wassimans.com

86 pointswassimans11 comments

I wanted to share in this article the fruit of almost a year of trial and error to shape a configuration that made my Doom Emacs a fully featured Swift/iOS development environment. Xcode is still far ahead (previews, instruments as examples), but still; that config gave me the opportunity to stay in Doom Emacs for 98% of the time.

As someone that has no know how of iOS app development, this post is well written and concise. As a regular doom emacs user, I often try to make the best out of it whenever I can. I don't use LSPs at all but I am curious, do you use the same LSPs as Xcode in this case?

Xcode actually does not use an LSP server under the hood, it’s like the other historic/big IDEs that rely much on a tight integration with the compiler via static analysis and many other complex machinery to get that IDE effect, lsp servers in comparison are very basic, but also very portable and that’s their advantage: we can have a reasonable feature set of Xcode’s in any editor that supports lsp servers.

That's insightful, thanks for your reply

very cool! this article would have saved me quite some time if I discovered it earlier, as I ended up diving into a similar rabbit hole. Still, some useful tips I will incorporate into my emacs workflow, cheers for that.

one thing to add: I recommend piping the output to `xcbeautify` (https://github.com/cpisciotta/xcbeautify) to have sane build output; otherwise it's a mess outside of xcode.

Oh that's interesting indeed! I managed to get Xcode like formatted logs but it was one of the most complicated things to get right (not that right actually), and xcbeautify seems the solution I was searching for. Thanks for sharing!

It’s interesting how easy it is to tell ai was used to write this despite it having none of the obvious mannerisms. I wonder what I would have thought of this article before 2022, or if I just don’t like this style because of overexposure or something

You are free to think like that, and I respect your feeling. The reality is that it took me almost a year to get the config details right and days of preparation to ship that article. I took inspiration from this article if you’re curious: https://www.heinrichhartmann.com/posts/writing/.

Oh, come on. I get when people complain about AI-assisted writing. It's mostly about signal-to-noise. Yes, AI makes it trivially cheap to produce "correct but empty" content - articles that are technically accurate, well-structured, and say absolutely nothing a reader couldn't get by prompting an LLM themselves.

Yet sometimes you do need to see a genuine human struggle, ideation, and a real problem behind the article. Let's try not be dismissive off the bat. I understand your style objection is a proxy. Your actual complaint is probably the feel of absence of a specific, earned perspective. Perhaps, it "doesn't speak to you" because you have not encountered the overlapping problems that article may help you with.

That isn't prose - it's educational, informational, well-structured and has code snippets. Let's not devalue someone's genuine work only because they decided to use AI-assistance - there could be legit reasons, from language barrier to lack of time. Good writing is hard. With and without AI. Not everyone commands the skill of writing, let's not rob them of the opportunity to cultivate it. Sometimes, it starts with dull, spiritless paragraphs.

Nice article. How has lsp mode been with Emacs? I've been continuously battling slow downs and hangs using lsp mode w Python and have tried many approaches like lsp-bridge which tries to do the majority of the work outside of emacs.

Pretty good to be honest. I got much performance problems and cache inconsistencies with Rust lsp server than with Swift’s. The responsiveness is not in par with Xcode but the overall experience is quite good in my experience. My machine is a MacBook Pro M1 BTW.

Reply on news.ycombinator.com