For me the biggest factors for making Xcode “happy” are:
- Writing clean/idiomatic Swift. This might sound silly but a lot of SourceKit instability is tied to things that are code smells, like deeply nesting closures and ridiculously long optional chains. Writing “Objective-C in Swift” where you’re trying your best to ignore types will also make SourceKit grumpy.
- Avoiding huge frameworks. Small focused single purpose libraries are fine, but gangly monster types can cause problems (and with UIKit available, likely unnecessary).
- Avoiding storyboards. For several years I’ve been going code-only on iOS, with XIBs being used only on macOS because there they’re more natural. Storyboards are more trouble than they’re worth on either platform.
- Using SwiftUI only for small, focused components. It still needs some time in the oven to be able to compete with code-only UIKit for speed/stability.
With those Xcode is quite snappy and reliable, allowing me to work all day with no issue.
- Writing clean/idiomatic Swift. This might sound silly but a lot of SourceKit instability is tied to things that are code smells, like deeply nesting closures and ridiculously long optional chains. Writing “Objective-C in Swift” where you’re trying your best to ignore types will also make SourceKit grumpy.
- Avoiding huge frameworks. Small focused single purpose libraries are fine, but gangly monster types can cause problems (and with UIKit available, likely unnecessary).
- Avoiding storyboards. For several years I’ve been going code-only on iOS, with XIBs being used only on macOS because there they’re more natural. Storyboards are more trouble than they’re worth on either platform.
- Using SwiftUI only for small, focused components. It still needs some time in the oven to be able to compete with code-only UIKit for speed/stability.
With those Xcode is quite snappy and reliable, allowing me to work all day with no issue.