Why Swift was a better option than Xamarin

June 05, 2014 - apple objective-c swift zdnet

swift-hero_2xMatt Baxter-Reynolds over at ZDNet claims that Swift is “a total mishit that’s badly judged the state of the software development industry” and that “What Apple should have done, years ago, was bought Xamarin”. I disagree with this on a number of levels.

I think the crux of the argument hinges on the flawed concept that ‘if only’ Apple supported some sort of standard third party language, it would make switching apps & developers between platforms easy, and everybody wins.  This doesn't make any sense:

I’d go further and say the industry as a whole would be negatively impacted by ‘language homogenisation’ — having a single language across all platforms would stifle development of new languages and technologies that work to make the industry better. Would we all genuinely be happier and more productive if Java 6 was the only mobile development language?

A couple of other choice quotes:

When I first heard about Swift I was pleased as I assumed that Apple would look to solve the key problem faced by mobile developers -- specifically that there is little overlap between developer toolsets making cross-platform mobile development extremely difficult.

I’m one of those developers and that ‘key problem’ is barely even on my list of problems. If it was, I certainly wouldn’t assume it was Apple’s responsibility to solve it.

No, the problems I battle with most are diagnosing obscure app crashes, dealing with header files, dynamic typing issues, forgetting asterisks, counting square brackets and the like (not to mention f*#!ingblocksyntax). Swift goes a long way towards removing this pain.

It’s been a long time since the software development community accepted commercial, “ivory tower” organisations to dictate engineering approaches. The last time this happened was back in the era that brought us Java and .NET itself. Now the community itself decides.

It should make Matt happy to know that the community itself DOES have the ability to decide — there are plenty of cross-platform mobile dev environments available today, including Xamarin. The fact the community hasn’t decided to replace ‘native’ development with these platforms should prompt him to wonder why (and I don’t believe it’s due to them not being first party).

Oh come on — it doesn’t show the best in modern language thinking at all. Modern language thinking comes from the community, building incrementally within that community in a way that’s genuinely helpful to all of us.

I like to think of programming languages as a window into the general attitudes towards language design at the time they were created. Objective-C is clearly a child of the smalltalk era. .NET was influenced by Java which was influenced by C++. The language elements I see in Swift are a reflection of thoroughly modern thinking from (yes, community driven) languages like Go, Rust, F#Ruby, Python and Haskell.

It sounds like Matt’s arguing only open source languages have the right to be called ‘modern’, which seems a bit narrow-minded to me.

In essence, Apple had one job -- create a new baseline tooling for iOS and show a sympatico approach with how the rest of the industry actually operates -- and they blew it.

It looks like he’s called out two jobs there. It’s too early to judge whether they’ve blown the first (and most important) job, but at this stage they certainly appear to have delivered the goods. As for the second, maybe I just don’t understand ‘how the rest of the industry actually operates’, but Platform |> Developer Tools |> Software |> Profit! would be my guess. I get the feeling Matt looked at the language, decided he didn’t like it, and took it as a personal affront Apple didn’t just adopt a language he was already comfortable with.

Lastly, I’ll just add that many commentators questioning the need for Swift seem to be assuming the language selection process was a relatively trivial window-shopping exercise — i.e. “Hey, this one looks nice!” However, that’s oversimplifying the number of factors that needed to be considered, and key amongst those was seamless compatibility with existing C & Objective-C code. None of the existing solutions (like Xamarin) come close to doing this as well as Swift.