Swift: The Churn

It has been an interesting experience for me to follow what the Swift community has been up to over the last few months. I’ve been excited to see them slowly adding and discussing features that I grew to love using in C# and have sorely missed while using Swift — things like async/await and much of the Generics Manifesto. These are the kinds of features that will finally move Swift ahead of Objective-C for your everyday iOS developer. With that said, I’ve been having a reoccurring question in the back of my mind…

An Honest Question

Sometimes I feel the need to ask basic, borderline silly questions at the risk of looking like a complete moron. Typically, this need arises when I can’t find the answers to these seemingly simple questions or I get the feeling that no one has asked the question yet. To make matters worse, these kinds of questions are often inflammatory! They typically call in to question a lot of hard work and progress that is being done on something — That is not the intent of the question. The intent of the question is to better understand why something is happening and what we can do better.

This question did not come to me until I listened to a recent podcast discussing “The Churn” as described in Uncle Bob Martin’s blog post: The Churn. As I read the post, I could not help but think of all the effort I’ve put into learning Swift over the past few months. This particular exchange from the post stood out to me:

Yet every time a new language comes along we dash away from those powerful tools to use the NEXT NEW THING. And the tools for that new language are like programming in the third world. God, you often don’t even have a reasonable rename refactoring!

It takes time to build up a reasonable toolset. If we keep on switching languages, we’ll never be able to tool those languages up.

>> But the newer languages are better.

Oh bull! They’re different; but they aren’t better. Or at least not better enough to justify throwing our toolset back into the stone age.

And think of the training costs for adopting a new language. Think of the cost to the organization of having to use 84 different languages because the programmers get excited about shiny new things every two weeks.

At this point you might be anticipating my question as something along the lines of —  Why not just put all this effort into Objective-C and stop with these Swift shenanigans?


That is not my question. To preface my actual question, I should mention that as a developer who is fairly new to native iOS work, I am not a big fan of Objective-C. I don’t like it’s syntax or structure. I personally believe that those are two big reasons as to why Swift even exists. Swift is much easier for new developers to understand and develop with and will allow current developers to be even more productive.

No my friends, my question is much more inflammatory than that. My question is: Why didn’t Apple just use C# instead of Swift? *Gasp*


Yes… I went there. On the surface it seems completely ludicrous to ask why Apple didn’t adopt a language heavily tied to the Microsoft technology stack; however, if you dig a little deeper I think it’s a completely fair question to ask.

Digging Deeper

Below are the top 5 points I could think of as to why C# could have been a good option for Apple to build on:

1.  Xamarin is already doing this!

Yes it’s true. Xamarin takes C# code and compiles it down to ARM assembly code. For all intents and purposes, the code ends up being native iOS/Mac code. The main point here being that if a 3rd party vendor can do it, Apple could surely do it.

2.  Many problems with Swift are already solved in C#

There are a number of limitations in Swift presently that are actively being worked on by the community. I have great faith that these limitations will be taken care of in the not to distant future; but they could have been building on a platform that already has many of these problems solved. Things like a robust generics system, async/await, and most of the things in the Generics Manifesto come to mind.

3. Visual Studio

I’m sorry but Xcode isn’t even in the same league as Visual Studio. Xcode doesn’t even have the ability to refactor Swift code (See Uncle Bob’s exchange above)! Visual Studio is a fantastic IDE that can certainly make developers more productive. I know Visual Studio is not yet available on the Mac but Microsoft has been making great strides to bring Visual Studio-like experiences to multiple platforms. Even if Visual Studio never comes to Mac, Apple could have built in support for the language in Xcode similar to what they are doing for Swift.

4. C# is open source and cross platform

A year before Apple made Swift open source, Microsoft open sourced C# and the .NET Core. This is no longer a Microsoft proprietary language. At this point, Microsoft has the .NET Core running on Mac, Linux, and Windows. The ability to write your app and server side code in the same language would be amazing for Swift developers! This is already happening for C# developers… And yes — it’s awesome.

And that brings us to my last point:

5. Robust dependency/package management

If you’ve spent any significant time around NuGet, trying to use anything like the Swift Package Manager feels like being in a 3rd world country — It is a mess right now. It’s not integrated with Xcode and has lots of manual configuration that is hard to understand and hard to set up properly. It has a long, long way to go. Even CocoaPods and Carthage can also be annoying to use. If Apple had used C# they could have adopted NuGet and started with a mature package management system from the get-go.


I have thoroughly enjoyed learning Swift up to this point and will continue to do so going forward. I really do believe that at this point Swift is the the best way to do iOS/Mac development since the ship has essentially sailed. With that said, I am a little sad thinking about what could have been. If I take a step back and compare Swift to C#, Java, or others, I have a hard time nailing down what exactly Swift brings to the table that’s moving computer science forward as a whole. Often times while developing in Swift I feel like I am just using a more limited and opinionated version of C#. It will surely aid iOS/Mac developers, but it will do so at the cost of creating yet another wheel when there were many different wheels that could have been built on top of.

Leave a comment

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.