My Xcode 7.3 compiler is constantly breaking and causing extremely long Build and Compile times
This Issue Occurred On A SpriteKit Xcode Project
I have an issue with Swift where, once my project reaches a certain level of complexity where I have tons of classes and methods around, my autocompletion breaks so that “Jump To Definition” ceases to work and my IDE is reduced to the usefulness of a basic TextEditor/Notepad.
My code’s color will change to white completely, which causes a lot of strain on my eyes, and this seems to only happen when I remove and add large blocks of code as I watch my CPU activity climb up to 75% usage on all CPU cores.
I think this started happening when I switched the target iOS from 9.3 over to 8.0. Is this an issue with the compiler trying to interpret old Swift syntax?
I also will have cases where I wait two minutes for minor changes to compile, only for the build to fail due to “Linker command failed with exit code”, which is easily fixed by compiling twice.
Here’s my specs:
OS X 10.11.4
Core i7 Skylake 4.0GHz
16 GB DDR4 RAM
I’m thinking about building a system running OS X with dual processors which might alleviate the issue, since it can take upwards of 2 minutes just to compile code that’s different by 1 line.
2 Solutions Collect From Internet About “My Xcode 7.3 compiler is constantly breaking and causing extremely long Build and Compile times”
Welcome to Swift! Great language, awful tooling.
Joking aside, there are a couple of issues at play here. First off, syntax highlighting disappears when SourceKit crashes. SourceKit is the library which parses Swift on-the-fly so that Xcode can do things like indexing, syntax highlighting and code completion. It’s a lot better than it used to be (using Swift 1.0 in Xcode was almost comical at times), but it’s still far from perfect. Until SourceKit improves, you won’t see much difference.
As for your build times, it’s worth trying something like the Swift Build Time Analyzer to see which functions are taking a particularly long time to compile. I recently halved the compile time of the project I work on by removing all lazy vars set via closures. A recent compiler change made type inference for these sorts of closures incredibly slow, so each one was taking ~6 seconds to compile.
Okay, I found one solution which resolved my issue.
Remove All Emojis From Variable Names & .Swift File Names
Contrary to Apple’s official Swift 2.0 textbook, DO NOT use ANY kind of Emoji’s for things like Variable Names and Swift File Names UNLESS you know that the emoji you’re using is a very old emoji (but even then, I wouldn’t recommend it).
After opening my project in AppCode, AppCode had unicode problems with file names such as:
foobar🔵.swift. It was very buggy and it would break Xcode later if I opened and saved a project with pre-existing emojis in AppCode.
So avoid using emojis in your code unless it’s for strings like:
let someString = "⬛️🗡💣📚"
- Adding two Table Views to the main View in Xcode
- How do I name and link an IBAction button created in a storyboard
- iOS 7 TableView like in Settings App on iPad
- Extracting images from a PDF
- Drawing curved lines without lagging?
- Swift – Method chaining
- iOS: How to share text and image on social networks?
- Are AFNetworking success/failure blocks invoked on the main thread?
- Cut Out Shape with Animation
- iOS call log access api
- In iOS6, trouble forcing ViewController to certain interfaceOrientation when pushed on stack
- Why specify in blocks where you depend on self being there?
- Cordova 3.0 – Open link in external browser in iOS
- Facebook Login Swift iOS 10 – Nothing Works
- Is there any particular use of closure in swift? and what's the benefit?