Apple's new Swift development language highlights the company's worst side

Apple's new Swift development language highlights the company's worst side

Summary: Apple's iOS tooling badly needed a reboot, hence the introduction of Swift. It's just a shame they did such a bad job...

TOPICS: Mobility
Swift cover
The Swift language guide. Not even available as a PDF because, you know, Apple...

Software development is not an easy business. Like a lot of technical jobs, people on the outside don't tend to appreciate what's involved. "Can't you just make it do blah-blah, " clients say, and then off we go as developers to try and make it happen.

Now and again, someone comes up with some amazing innovation that makes software developers lives genuinely easier. .NET is a good example -- any developer who worked with Microsoft technology back in the 1990s will remember how downright difficult working with anything other than Visual Basic was. Or jQuery -- a technology that in one single stroke made building web apps a hundred thousand times easier.

Yesterday at WWDC, Apple announced Swift, a new programming language that Apple thinks will make software developers lives easier.

Problem is, it's a total mishit that's badly judged the state of the software development industry, and offers little to the jobbing mobile software developer.


The problem that the industry has when it comes to software development for mobile devices is that each platform vendor produces their own toolset in their own language using their own APIs.

This approach makes it extremely difficult for developers to build apps that run on multiple devices. The only safe way to build good cross-platform apps is to create distinct versions of each app from scratch for each platform that you wish to target. As you can imagine, this greatly increases cost, not to mention hassle.

For example, if you want to build an app for Android, Google would prefer that you wrote it in Java and the Android SDK. For Windows Phone, Microsoft would prefer you used C# and Silverlight. And for iOS, Apple was preferring that you wrote it in Objective-C and Cocoa Touch. You can't have one set of code that hits all of those.

Apple's problem with developers was that they used to be a bit of a backward schoolkid eating paste in the corner when it came to the greater software development community, and then suddenly with the success of iOS ended up in spotlight (no pun intended). With the light shining on them, it was obvious their tooling wasn't very good.

CNET: WWDC 2014 full coverage

Apple's developer tooling was based on technology cribbed together to support NeXT. Objective-C is a mash-up of Smalltalk and C, the end result of which is a crazy and arcane looking language that lends additional meaning to the term "toxic hellstew". It's tremendously awful to work with, compared to the tooling that enterprise software developers work with every day.

To cut Apple some slack, that what iOS developers had to work was with was understandably awful because as previously mentioned no one really cared about developing Apple software and there was no point in the investment. It's amazing really that iOS grew the way it did given how bad the tooling is, which itself just shows how much money there is in developing for iOS.

Objective-C and Cocoa Touch are not proper software development toolsets. They're too weird and backward, and were in desperate need of a reboot.

Some of you reading this that use and love Apple's toolsets will probably baulk at that statement, which is understandable. But come on -- if you do use and love Apple's toolsets you know it needed rebooting, even if you don't like me saying that they are not "proper" software development toolsets.

One job

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 a huge fan of Apple products. The iPad I think is a fantastic device. The iPhone ushered in a new and important era of computing. They've brought the benefits of a connected society to everyone through their technical leadership.

But sometimes the company's over-the-top, supercilious nature really grinds my gears, and Swift highlights that unappealing side.

What software developers need is familiar tooling that builds on open standards and well-understood approaches. What they don't need is a bunch of know-better-than-thou engineers sitting in their ivory tower coming up with something that feels almost deliberately, intentionally different just because they think they know best.

When you look at Swift, that is what you get. Something that has been designed in a way that shows no empathy at all for what the greater community of software developers actually need. It looks to serve only Apple developers, and even then it doesn't do it in a way that actually helps Apple developers be part of the broader and richer community outside of the Apple bubble.

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.


What Apple should have done, years ago, was bought Xamarin. But they didn't. That would have allowed developers to build for all relevant mobile platforms using C# or Java, which in turn would have created a pretty elegant smoothing of approaches that would have been good for everyone.

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.

Case in point: say what you like about JavaScript, but it is what everyone uses, it's deeply expressive, and -- honestly -- it's rather good. But it's only "rather good" because we all as a community have built it up together as opposed to someone sitting there and superiorly dictating that it's how we should work. Look at how Microsoft approached TypeScript for an object lesson in how Apple should have done it.

There's a quote in the Swift language guide: “Swift combines the best in modern language thinking with wisdom from the wider Apple engineering culture.”

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.

Is it coming across that I'm deeply disappointed about Swift? You bet I am.

What do you think? Post a comment, or talk to me on Twitter: @mbrit.

Topic: Mobility

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • If Javascript.....

    is a 'rather good' example of what has resulted from the 'developer community,' then one might simply cheer Apple's efforts with Swift. For lots of us out in the real world subjected to Java and Javascript, they are more of a steaming pile.
    • use C#

      I have been in this industry for decades. I've used Fortran, C, Java, VB, C , Javascript, PHP, Pascal, Objective-C and C#. By far the most elegant language out there is C#. It's brilliantly understandable and insanely powerful. It's also pretty damn fast, though if you need parts of your app to be uber fast you can write them in C and call them from the managed code.

      iOS apps like most mobile apps, are generally very basic. Most of them are not like Office 365 or Evernote, but when you need a complex solution, nothing beats C#. It's built by architects for architects. When I need to work in Objectice-C I squirm in frustration with every keystroke. It's like working in old Fortran. Swift looks better but it could have been so much better if it were more like Java and C# and less like a hacked overly on top of Ovjective-C. Seriously, named parameters still? Backward syntax like String(myvar) instead of (string)myvar or even myvar as string? I can still see the [String myvar] just decorated as eye candy. It doesn't seem all that innovative. I'll try it, and I hope I discover I'm wrong, but initially C# still rocks in comparison.
      A Gray
      • Spluh?

        You don't seem to be very familiar with any of the languages you listed, because none of your objections make a lick of sense.

        C# has named parameters, just like Swift and Objective-C. You like "myvar as String"? Well guess what, that's valid Swift! And [String myvar] makes no sense as Objective-C.

        Is Microsoft Office like Microsoft Office? Because you know that's an iOS app, right?

        Swift is obviously strongly influenced by C#, among many other languages. But Swift improves on it in key ways, such as triggering errors on overflow or eliminating null-by-default.
        • Strong rebuttal!

          You were doing well anyway, but "Is Microsoft Office like Microsoft Office?" put it over the top. Well done.
      • Not so #

        You do realize that Microsoft Office for Windows is not even written in C#? Yep, C# is so great for building things like Office that they wrote it in C++. You know what else? Some of the best software out there is on OS X. You know what it was written in? Objective-C. Almost every app (including the OS itself) has been written in Objective-C. Is Windows written in C#? Still think Objective-C is the language for writing toy, simple apps?
        • Not so # what what?

          C# is intended to be an applications language, not a systems language. (There's System C# that is intended to be a systems language. But that's new news, and the new kid on the Windows block.) It does not make sense that Windows would, itself, be written in C#. Since the former is not an application, it is an operating system.

          Objective-C is darn long in the tooth. Swift looks like the new Apple preferred language that makes programming in OS X and iOS a joy, rather than the chore that it is in Objective-C (2.0 and ARC advances aside).

          Note: the kernel of OS X is not written in Objective-C, it is written in C. There's a few layers all written in C, then a C-to-Objective-C bridge to the applications written on top of that. Which is fine, since C is an excellent systems language. (So is C++. Maybe some of those layers are in C++, but I'm not sure which are or not... and that's a good sign.)
      • I feel about C# the way you do on Objective-C

        I do not find C# to be elegant at all and it's overall architecture leaves me flat. Compared to the elegant simplicity of Objective-C that promotes simple, effective and highly maintainable design patterns, I find C# unduly complex.
      • I appreciate the elegance of Objective-C

        Funny, I've been developing Microsoft software since before Visual Studio. When I first started learning Objective-C, I hated it because it was so counter-intuitive to the Microsoft culture. But once I got over the admittedly steep learning curve and finally reached my AHA! moment, I began to realize how much more disciplined Apple is in its approach to software development.

        And now I've taken what I've learned from Xcode and Objective-C and started applying that same disciplined approach to developing in C#. My coworkers are constantly blown away with how elegant my code is, how everything is so logically laid out, self-documenting, predictably designed and implemented, how all of my modules are designed to work independently, yet are so easy to integrate into their own projects.

        For me, cross-platform development is a complete non-issue. I don't have any interest in trying to develop Android or Windows versions of my iOS apps. There's no real Windows market, and while there is a substantial Android market, they really don't want to pay for apps.
        Mark Petereit
        • Cross development is a non-issue

          Swift wasn't developed as a cross-platform development language. To even think that Apple would be concerned with making it easier for developers to put their apps on competing platforms is the height of foolishness. If you hadn't let hubris get in the way, you'd realize that Apple didn't invest 4 years in creating this language for third party developers in the first place.

          They did it so that Apple's developers would have a tool to make the best designed, most secure apps. It's just a happy coincidence that iOS developers outside of Cupertino will also benefit from having a great tool for developing Cocoa and Cocoa Touch apps.
        • Perspective in the Platform debate...

          I think your experience is the key to these kinds of debates.

          We say "C#" or "Objective-C" but what we're really talking about is a language *plus* all the frameworks we learned with the language *plus* all the patterns we learned to be productive and effective *plus* all the tools we learned that go along them.

          It takes time to learn all that stuff, so a C# programmer getting used to Objective-C will find it counter-intuitive and feel like they are swimming upstream for a while.

          Likewise the other way around.

          I think we should all be willing to admit that even though we've personally learned to be productive with a certain combination of language/framework/patterns/tools that there may be other valid combinations -- ones that may even be *better* than what we currently know (after paying the cost of climbing the learning curve).
    • Unfortunately...

      JavaScript is a terrible language by any metric. It's not typesafe (heck, it barely knows about types). It's horribly easy of hijack code and even accidentally make functions vanish. It has minimal error reporting.
      • ...or not.

        JavaScript was written to support SMALL SNIPPETS of code to modify the DOM state, in expressing tiny little event handlers. It does that very, very well. That is what the language was designed for, and what it does exceedingly well.

        In that JavaScript has crushed the "browser wars" dominant application language of Flash, Silverlight, and Java is itself a shock. Hence we have CoffeeScript and TypeScript and Clojure and whatever Google SDK (AngularJS, at the moment) is promoting to express even more application viable expressivity.

        Judging JavaScript outside of the domain for which it was designed is not cricket.

        In that JavaScript has established a new frontrunner platform is darn impressive. Especially in light of how hard it is for new "Top TIOBE" languages to establish themselves.
  • As a non-techie I don't quite get this

    You write:
    It looks to serve only Apple developers, and even then it doesn't do it in a way that actually helps Apple developers be part of the broader and richer community outside of the Apple bubble.

    Isn't that Apple? Why would they want to help you along with Android? Apple wants to help to make developing iOS apps easier. Why not talk about Swift, instead how it doesn't help Android?

    Negative-Apple-headline-click-bait. You made it to the Google news front page, congrats to you!
    • As a techie I was thinking exactly the same thing

      As long as Apple have the premium and by far most lucrative platform to develop for, it is actively in their interest to make it harder for developers to translate their work to other platforms.

      I agree with the author, though, in that it shows the company's worst side. In many ways Apple are the big monster that Microsoft increasignly isn't any more. So much of what the author accuses Apple of now is what Microsoft has been guilty of in the past, but they are getting better, embracing open source and emerging standards, particularly in the web world. But I think both companies were/are just behaving like any large corporation would when in a massively dominant market position, i.e. doing things entirely their own way, in their own interest, and to hell with everyone else.
    • Exactly.

      As much as the author dislikes the Apple toolset, it still light years ahead of its primary competition Android Studio in stability, speed, usability and most importantly time to market. Far from from being a Toxic Hellstew, Cocoa is a simple and elegant language that provides a rich API for actually getting the job done.

      So Swift makes it even faster to get market. How is this bad for iOS developers? Bad for Android? Bad for Windows Phone? Perhaps. Bad for iOS developers? Not really.

      I was talking to an acquaintance that worked at a cross platform development studio for mobile. iOS and Android. He thought the 80/20 20/80 rule was funny. 80% of their effort went into Android 20% to iOS. 80% of their revenue came from iOS and 20% from Android. Now this was about 12 months back so it might be 80/20 60/40 now but if you leverage Swift, it might shift to 90/10 60/40.
      • sorry

        but if you are going to talk about development environments, please never forget Microsoft Visual Studio. Have you tried to create a Windows Phone app? I bet you don't.
        I do agree that Android development environment is awful.
        • Windows Phone is not a player.

          Might be some day.
          • You're leaning against an open door

            You make an interesting point. Are you aware that there are as many Windows Phone 8 devices in use as there are Mac desktop devices?

            Now, consider that the ratio of Windows desktops / Mac desktops is about the same as iPhone / Windows Phone (the denominators have ~7% market share), and QED your logic states that Mac is not a player.
          • That assumes that the relevant feature of a user-base is its quantity

            Apple tends to see it as how much money they have to spend. Apple is a well-positioned company for the increasingly income-inequal economy. Apple has only a small percent of the personal computer market overall (call their whole iOS/Mac ecosystem ~10% of the market for personal computers, including things like phones and slates and laptops and desktops, etc.) but they make an inordinate amount of the profits, because they can and do overcharge for everything. Indeed, they have positioned their products to be Veblen goods...increasingly inferior and therefore increasingly overpriced, but (ironically) therefore increasingly in demand.

            There is simply no doubt that Android is superior to iOS in nearly every way. But iPhones have quality parts, expensive bills of sale, and enormous markups on top of that. And as society becomes more and more one of haves and have-nots, the affluence of Apple users will only grow, even as their absolute numbers shrink.
            x I'm tc
          • Overcharging?

            > but they make an inordinate amount of the profits, because they can and do overcharge for everything.

            What do they overcharge for? Their phones are, in order, free, $99, and $199. Samsung's comparable models are $99 and $199. HTC's start at $199. I'm not sure where I see the overcharging.