[weiming]

Curious question as I am not a compiler expert.

I have to do front-end iOS work from time to time and it's surprising how bad auto-complete can be in Xcode with Swift even after all these years: still randomly sluggish, randomly stops working inside closures including completely losing syntax highlighting inside the closure, and even Cmd+clicking to see the definition is a hit-or-miss as it sometimes opens up a blank editor and just spins. I would have thought that Swift having a strict type system would have made the IDE experience better, not worse. Don't know if the grammar is too complex or if it is the bridging with ObjC stuff or something else that made it difficult to build a robust solution. Can anyone shed light on this?

My points of reference are rust-analyzer, or just VSCode with Typescript, both very snappy although of course the languages are very different. If anything I'd expect Swift to be closer to Rust experience-wise since they both have pretty strict grammars.

[jmenter]

10 year iOS developer here. I don't have any answers for you (not a compiler expert either) but yeah, auto-complete of Swift in Xcode continues to suck in a lot of different ways. It's a shame because autocomplete in Obj-C was so good for so long (I'd put it up there with VSCode/TypeScript with some caveats), and is still pretty great, but seemed to get a little worse itself when Swift showed up.

[novok]

I think it comes down to swift being a way slower performance language on the compiler side because of some bad early design decisions their compiler engineers will grumble about on twitter occasionally and xcode struggling with that fact. And apple underfunding their developer tools team that creates all of this.

[Pulcinella]

Don’t think this will help you, but maybe provide some comfort in that you are not alone. I work in Swift and XCode everyday and still run into this problem occasionally. XCode still indeed will sometimes (seemingly randomly) lose syntax highlighting. It seems to be, at least sometimes, related to when you try to do something a bit too clever with closures (especially closures inside closures) and marking lots of changes at once, especially across targets. The biggest problem is that when the indexing required for syntax highlighting fails, there is no insight into why it failed and no way to force Xcode to re-index except by restarting Xcode. Building should re-index, but in practice this indexing is not as extensive as restarting Xcode.

[LordIllidan]

Instead of restarting Xcode you can also flip the file target, changing it will trigger an index.

[saagarjha]

  killall SourceKitService

[tonyedgecombe]

The JetBrains IDE[1] seems much better at this so I would assume it is an Xcode problem.

[1]: https://www.jetbrains.com/objc/features/swift.html

[kitsunesoba]

I've found that Xcode's performance with autocomplete, highlighting, etc with Swift depends on how you write Swift. Here's how I generally keep Xcode/SourceKit happy:

- Limit interaction between Swift and Obj-C wherever practically possible. Swift headers for Obj-C functions are autogenerated by the compiler, which can act as a bottleneck depending on how much Obj-C is in your project, how often that Obj-C changes, and how often you clean the project.

- Avoid nesting closures deeper than 2 levels (probably good advice anyway).

- Explicitly state types where possible to avoid inference.

- Avoid excessively long chains of optionals and/or casts.

So generally, try to keep code clean and explicit, and when choosing dependencies opt for pure Swift options where viable. Avoid adding new Obj-C code except where needed (e.g. C++ interop) and if possible reduce Obj-C in the project to small, seldom changing bits.

[terhechte]

I wanted to answer that Java has had decades and millions of dollars poured into its ecosystem to allow the very good IDE experience that we have nowadays. But then I saw that you listed rust-analyzer and I found it intriguing. I have a mixed mode project (35k of Swift, ~8k of Rust)[1]. Both are completely separate targets (Rust compiles to a static library), but in general I get much better & faster completion in Xcode than I get in VSCode w/ Rust analyzer. Now, don't get me wrong, I love Rust analyzer, it is leaps and bounds better than Racer but the completion experience in Swift is still better for me...

Well with one caveat. It only works well if the file that I'm currently editing is in the selected target (i.e. if I have a file Bottombar.swift and that is in InterfaceKit.framework, and I'm editing it while the selected target is ExtensionKit.framework, then nothing works)

[1] https://hyperdeck.io

[dmitriid]

> Java has had decades and millions of dollars poured into its ecosystem to allow the very good IDE experience that we have nowadays

A trillion-dollar company cannot create an IDE on par with JetBrains which has 1200 employees, 250 M revenue, and and has not one, but several IDEs and plugins for several languages (including dynamic languages, including support for multiple versions of a language, including multiple versions of runtimes for a language) that are superior to Apple's one single IDE for two languages.

It's not a "millions into Java" problem. It's an Apple problem.