Swift is the new Java… and I don’t mean that in a good way.

Swift is the new Java… and I don’t mean that in a good way. I’ve got the feeling that XCode is getting worse with every new release, buggy and laggy, but to be fair, it’s not XCode’s fault entirely, swift 3 adds to the equation.

Warning: ranting and utterly opinionated post follows about Swift 3, XCode and the current trend at Apple of loosing interest for excellence in software. You’ve been warned.

I remember when I started coding in Java, back in college. It was 1999-2000, Android didn’t exist yet, and most java applications were targeted towards the J2EE, desktop and enterprise market. Back then, Java IDEs (like JBuilder, IntelliJ, Eclipse, etc) were laggy, slow and painful to work with. If you are unfortunate enough to work with Android Studio and its Android emulator, you know that this situation hasn’t really improved a lot since those early years, but XCode had always mostly been different… until recently.

I didn’t like swift 3 syntax and language changes at all. While I’ve been supportive in the past to swift evolution, the last changes to swift 3 have made my code harder to read and understand, and some of them are just a step backwards in my humble opinion. Besides, migration from swift 2.x to swift 3 was a real pain in the ass, and the automatic migration tool simply doesn’t work as it should. Up until some days ago, I still had some projects to migrate, and had to spend hours and hours fixing things and testing all my projects to make sure the migration process was successful and didn’t alter the app functioning. At least I can code in Android Studio with the same Java syntax that I learned back in college, more than 15 years ago.

One of my main rants about the migration process was the “Segmentation fault 11” error. You would spend countless hours fixing a large project only to end up with this error and no indication whatsoever of what was causing the compiler to crash. Ahhhh, remember those times when compilers didn’t crash?

Ahhhh, remember those times when compilers didn’t crash?

mini1476442764In the worst case scenario, a Segmentation fault 11 error required you to create a new project and start adding your old project files one-by-one to the new project (taking care of the order for compilation dependencies, of course) and checking if the new project compiled, until eventually getting to a file where the compilation caused the segmentation fault, and then comment all that file’s code and start uncommenting functions one-by-one… you get the idea.

However, once you finally got to the issue, you could more or less change the offending code and get your code to work… or almost. Swift, or more specifically, the Swift compiler, seems to have problems with structures and constructions that are, honestly, not that complex. This is an example:

// Un-comment the line below to get a weird error indicating that the expression is too complex (sigh).
func thisCalculationIsOhSoComplex() {
   let inputRadius = 1.0
   //let radius = UInt32(floor(inputRadius * 3.0 * CGFloat(sqrt(2 * M_PI)) / 4 + 0.5))
}

If you uncomment the line depicted above, you will receive an error (not a warning, an error) indicating you that the expression is too complex. If I am able to solve that calculation myself, I expect a modern programming language in 2016 to be able to solve that as well. Or is it Swift the programming language for millenials, and I need to specify every math operation in a different line?

Another (in)famous scenario is when XCode 8 ends up getting stuck at “indexing” and not letting you compile, build or run the project, with no indication whatsoever of what’s causing it. After some tests, I discovered that in my last project, this situation was happening because I was trying to define and initialize an array with more than, say, 14-15 elements. I created a sample project that, in less than 10 lines, will freeze your XCode and leave it stuck at “indexing”, unable to compile, build or run. After some time, if you don’t comment a method that simply defines and iterates through an array, your machine will run out of memory. This is production software. By Apple. Please download it and check it out by yourselves. Why is swift unable to deal with an array to the point of crashing your computer?

Even worse are some errors that cause XCode, or more specifically, the source kit extension in charge of interpreting/displaying the code, to crash. Since XCode 6.X, I code in constant fear of getting that annoying “SourceKitService crash”, in it’s original, raw form, or in the new beautiful top alert message in XCode. cfbbaifugaaukt6-png-largeOh, and of course this crash on SourceKitService will sky rocket your CPU up to a happy 300%. In my experience, trying to define hash, hashValue, isEqual and == for a custom object always ends up in a SourceKitService crash eventually. This is happening since 2014, and Apple has yet to address this issue in a serious and definitive way.

captura-de-pantalla-2016-10-14-a-las-10-44-18

If you, like me, are an iOS developer, and your main work tool is XCode, all these problems end up affecting your productivity, cost you hours of extra work and cause you a lot of frustration. This situation is only getting worse since XCode 6, which makes me wonder, has Apple lost its way? Is excellence and polished tools and software not its priority anymore? Are you suffering this situation too?  Let me know your opinion in the comments below.

Comments(3)

MichaelM
October 18, 2016 At 12:29 pm

Apple has ironically almost singlehandedly devalued software to zero. It started with the race to the bottom in the app stores. It culminated in a free OS and tooling. Now we are beginning to get what we have paid for.

    Ignacio Nieto Carvajal
    October 18, 2016 At 12:29 pm

    Hi Michael,

    While I think you are right about the race to the botom (I’ve ranted about that too :), I actually cannot fully agree with your blame to Apple. In my mind, the policy of “everything for free, ad-supported” is tightly tied to the appearance of Android and cheap, low-budget devices for a mass that didn’t want to pay for anything.

    The perfect example is WhatsApp. At the beginning, you had to pay for it on Apple iTunes, but not on Google Play (I think it was called Google Market at the time?), and then when Whatsapp added the $1/year subscription fee on android devices (they couldn’t do that for iTunes because we had already paid for the App) a lot of my friends with android devices switched to Line because “paying $1 a year was a robbery”.

    So I agree that all developers followed that disgusting trend, thus devaluating software and the work of developers, but I don’t think it’s Apple’s fault (this time ;).

      Michael
      January 4, 2017 At 12:29 pm

      I agree with these points. I have been working with Swift since version 1.2 and so far the new changes are indeed a step backwards. Also XCode has progressively become slower and the MacOS with it (too much memory, cpu? all?)
      And lets not get started on the storyboards and constrains… try to work on a 1+ team with source control tools and more than one persons to work on the same storyboard, 1 word…Hell!

Leave a Comment

sing in to post your comment or sign-up if you dont have any account.