Saturday, January 17, 2015

Real World Swift

Chris Surowiec (via iOS Dev Weekly):

Our biggest gripe – and source of frustration – with Swift is probably not the language itself, but the tooling around it. Xcode (Apple’s Objective-C and Swift IDE) does not yet feel solid with Swift code. During development of our app, the IDE would often slow down noticeably or crash. There was no (or very slow) code completion most of the time, basically no debugger, unstable and unreliable syntax highlighting, a slow text editor (once the project reached a certain size), and no refactoring tools.

Additionally, compiler errors are often incomprehensible and there are still quite a few compiler bugs and missing features (e.g. type inference sometimes goes awry).


The number one crash group (at ~30% of all crashes) comes from an external Objective-C library. In fact, four of the top five crash groups come from Objective-C land (the fifth being a failing assert, which we leave enabled in production builds).

Also of note, the seventh most common crash comes from the previously mentioned Apple-provided Objective-C function that will sometimes @throw exceptions without being documented as such (-[AVAssetWriterInputHelper markAsFinished]).


You can certainly tell that some of Xcode’s features become slower and slower as your project grows, and we are not the only ones noticing. Iteration time (the time it takes after making a code change, hitting CMD+R, and having your app run in the simulator) is also worse than in Objective-C. A quick test shows that adding a single line brings the wait up to 14 seconds, and this varies greatly depending on what you do. Making a similar change in our Objective-C based app takes about two to three seconds.

Comments RSS · Twitter

Leave a Comment