Thursday, November 9, 2017

Enduring Xcode and SourceKitService Problems

Ling Wang:

This is how I’ve been coding in Xcode 9 since WWDC. Code completion is totally broken. It’s basically TextEdit with syntax highlight.

Many issues beside code completion:

  1. Jump to Definition shows menu not jump
  2. to ObjC header not Swift

Tony Arnold:

My experience isn’t as bad, but it’s still poor enough to have made me think seriously about starting a different career. There were a few points in the last year where Xcode made me want to give up coding entirely.

I file bugs, I sympathise and I try to understand where I can. But I have jobs to do, too - there are limits to my time.

Sadly and ultimately, working with Xcode is a minefield where the basics sound amazing on paper, but just don’t live up to the promises made.

I had a realisation earlier this week that the only reason I was considering buying an iMac Pro (which is likely to be a $10-15k AUD Machine) was to make Xcode run faster because I spend half of my professional time cleaning & rebuilding my projects to get basic editing working.

My recollection is that the old ProjectBuilder was solid but that Project Builder and Xcode have been perpetually buggy. It used to be that the compiler tools were reliable and the interface was buggy and crashy. Lately, the app itself has gotten better, but the Swift support (highlighting, jumping to definitions, and compiler) have been dragging it down. It is rare for me to make it through a day without the compiler crashing or the editor breaking. Fixing these issues would save developers inside and outside of Apple countless hours and frustration.

Previously: Swift 4.0 Released, Why I Don’t Write Swift.

Update (2017-11-09): Slava Pestov:

I think we’ve reached an inflection point and general compiler crashes have been getting fixed at a good pace since 3.1

SourceKit crashes have the same root causes often but are more challenging because SourceKit sees more invalid states

Source compatibility as a goal means we can grow the body of code we test against with the source compat suite

Up until Swift 3 we had the double whammy of spending most of our time on language features and changes and also breaking compatibility meaning we had trouble getting good test coverage

There is still a lot of work to do but I’m much happier with our priorities now that the language has settled down and things are moving in the right direction

Update (2017-11-10): Joe Groff:

Turns out Ling’s problem was a bug that is fixed in master SourceKit. You can remove -v from OTHER_SWIFT_FLAGS to work around it.

6 Comments RSS · Twitter

You should try AppCode. It still has multiple flaws and is different but it works good with code (well, at least much more stable). And it is getting even better lately (try EAP builds).

Overall what we’ve learned is that Swift is an insanely hard language to support in an IDE.

My “Swift code completion simply doesn't work” bugs keep getting closed as duplicates. Great. It would be nice if Apple would start fixing the problems before I start giving up on donating my time reporting things they already know. (This cycle of desperation and futility repeats a few times a year, and yet I keep coming back…)

Just out of curiosity, considering the Swift toolchain is still not good, why do people want to code the UI instead of using xibs? I get the SCM thing but from a compilation time point of view, I'm not sure it's a good idea to code the UI.

@someone Code is more flexible and maintainable than xibs, and Interface Builder is frustrating to use.


also I'm pretty sure that the XIB format has changed at least twice since it was introduced, with breaking changes each time.

Doesn't seem possible to move the instruction pointer during a debugging session in Xcode 9.1. Appears to be fixed in 9.2 beta. No mention to be found in the release notes.

Leave a Comment