Mac developers musing on Apple's new Swift language

Mac developers musing on Apple's new Swift language

Summary: At WWDC, Apple released the first version of Swift, the company's new development language. Developers are taking a look-see at Swift and offering some initial opinions.


The Swift platform and what it will offer developers is one of the most important announcements last week at the Apple Worldwide Developers Conference (WWDC). Many programmers found the syntax of Objective-C hard to get used to, so Swift may provide a productivity boost to some.

Apples Swift programming language

While most developers will look to future projects for implementing Swift (meaning at least a year off), some said they are moving ahead more quickly. For example, developer and writer Marco Arment said in a blog post that he would take a while to grok the new behaviors as well as its standards and expectations.

In an interesting and uncharacteristic move, Apple is opening all its WWDC 2014 video presentations to the public; last year only registered developers had access to them. Check out the Introduction to Swift by developer publications engineers Tim Isted and Dave Addey.

On his blog, Michel Fortin talked about Swift's safety features.

Apple says it’s designed for safety. It’s important to note that the design of Swift doesn’t prevent memory corruption that could happen due to multithreaded code at all, however. I find it striking that there’s no mention of threads or concurrency at all in the language documentation. Maybe they’ll just outlaw threads, but that’d be surprising.

Besides this multithreaded hole, the rest of the language seems to be safe from memory corruption bugs. There’s no way to temporarily escape the safeties (like Rust’s unsafe block), so any unsafe thing you may want to do will have to be in C or Objective-C.

There were some posts with interesting discussion about Swift and scripting. Clark Goble at Clark's Tech Blog had several long posts about the introduction of Swift and a first look at its performance. He suggested heading over to GitHub and checking out the surprisingly large amount of Swift code there.

To my eyes, it is much easier to read. I know some ObjC diehards are saying the lack of verbosity makes it harder to read. I don’t see that. In fact, one criticism I have is that so much still uses Cocoa naming conventions that too much remains verbose. I think the rule that the most used methods/classes should be terse has not been a rule Cocoa has followed well. (Especially in terms of string handling)

In an interesting post, the programmer known as Dr. Drang pointed to Javascript taking a place alongside AppleScript as an application scripting method in OS X Yosemite.

I’m not a big fan of JavaScript, but it’s certainly a more conventional language than AppleScript. I’ve forced myself to become conversant in AppleScript because it’s been the only game in town, but that doesn’t mean I like it.

Still, the devil will be in the details. The biggest problem with AppleScript has always been with the applications that implement it. Each app gets to decide which features get exposed and what they’re called. This has led to similar concepts getting different names in the dictionaries of different apps. I doubt that JavaScript will solve that problem.

Clark wondered whether he would bother with Javascript for Automation with the arrival of Swift.

I’ve not yet really tried scripting with Swift. However, the REPL and the Playgrounds give one a lot of nice flexibility for playing around with scripting. Further, since Apple’s Javascript is apparently using its own idiosyncratic Scripting Bridge, there’s not really a lot to be gained over Swift by going with it. I’ve not tried Javascript for Automation yet. Yosemite’s beta 1 is still rough enough that I didn’t really find it usable enough on boot.

Topics: Apple, Software Development

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
  • Concurrency

    Whatever one may say about Swift, it is a language that has paid attention to what took place in language design recently. It did not incorporate the concurrency amenities provided as a priority in Clojure. Defect? Well, Clojure was about making Lisp more efficient, incorporating the java library by running to the jvm, and implementing locks beneath the surface. It built on existing things.

    We are told that there may be changes at the source level to Swift. I expect concurrency to be addressed by future syntax amendments and I imagine it to be one of the next obvious hills to climb. This is a systems language from which to build.
    • Why reinvent the wheel?

      Why not just adopt Rust, for example?
      x I'm tc
  • Concurrency -> GCD

    I see a lot of people suggesting that there's no concurrency stuff in Swift. However, you have full access to the objc grand central dispatch apis. So... am I missing something?
  • Proof that Apple is run by morons

    They have a cross licensing deal with Microsoft, and C# is a standard, so what does Apple do? They spend MILLIONS developing a vastly inferior language that they'll have to maintain for years, probably costing them BILLIONS. Had they adopted C# they would have had hundreds of thousands of libraries, and billions of lines of code already written. And it probably would have killed Windows Phone. They could have bought Xamarin for a song. Swift is the love child of arrogance and stupidity in their purest forms. Microsoft execs are laughing their asses off because they know it's only a matter of time.
    • Huh?

      Why should Apple rely on the competition any more than it has to? Or did you forget that Apple and Microsoft are competitors?
      Michael Alan Goff
      • Yes, but cozy ones

        Apple and Microsoft both liberally use the patented technologies of the other. TrueType is a famous example. Apple wouldn't be afraid of using C# I am sure, but they've got their own ideas of how to model an MVC development paradigm, and probably wanted to keep doing their own thing.
        • They're cozy for now

          But the more Microsoft tries to become Apple, the more likely it will be that Apple will really fire back at some point.
          Michael Alan Goff
      • Adopting C# would have crushed...

        Windows phone and given Microsoft developers an alternative to Android. As it is, corporate America will wait for Microsoft to get its act together. It looks like Microsoft has with WP8.1, so the sun is about to slowly set on Apple's latest run. It will be their last. Good riddance.
        • That's a good joke

          iOS has a much stronger ecosystem than WP.
          Michael Alan Goff
          • And Apple's penetration into corporate environments...

            is virtually non-existent. I'd ask you why, but your reasoning abilities are on par with a crash test dummy.
          • Easy

            Microsoft quickly got into the enterprise and they provided a service that's needed there. It has a certain timetable that they update, patch, and so forth. Enterprise needs those features, as well as some others that Apple hasn't actually been forthcoming with until recently.

            Apple is primarily a consumer-facing company, though.

            I still don't get how your comment refutes what I said in any way. Consumers want an ecosystem, and those are the main people buying smartphones.
            Michael Alan Goff
    • What?

      Isn't C# compiled in an intermediate language and then run on a VM? Swift is built on-top of objective-c and compiles to native code. This allows natively using ObjC from within Swift. So all the effort Apple put into ObjC isn't just wasted. This allows developers to also continue to use their current ObjC libraries without being forced to immediately rewrite them.

      Plus, Swift builds upon multiple languages (including C#). Why would Apple want to limit themselves to just one, when they can build one that contains the good parts of many? And why would they want to have to run interpreted code in a VM when they can easily compile to machine code using everything they already have?
    • Blah blah Linq Blah Blah async

      Look, dude - no one cares. Swift has got Lambda and generics, which for power users, is all you really need anyway (loop performance in LINQ is not good enough for commercial apps.)

      Asynchronous programming and threading work just fine in Swift and all modern languages... C# holds no monopoly on this, even if the way async works in Metro is admittedly awesome.

      Meanwhile, Swift does have some cool stuff, such as great functions in functions support, a great way of doing constant assignment, and super zippy compiled performance.

      C# obsessives already have a solution for Apple - Xamarin. If they can't live with any other language, there you go.
      • More brain dead commentary

        "(loop performance in LINQ is not good enough for commercial apps.)"

        Truly one of the most brain dead things EVER written. So you need to order a list by x, then y, and you think the average developer is going to write better ordering code than the PHDs Microsoft hired to write theirs? How about joining two collections on a common key? How about filtering a collection and ordering the results? You obviously know NOTHING about programming.

        Apple could have had a great programming language for virtually NOTHING, and instantly acquired a huge base of code and experienced developers. Instead they've got a crap language that's gonna cost them BILLIONS to maintain, with minimal gains. Heck, their layout system and limited controls are the real problem. But since you're obviously not a programmer (or a truly pathetic one) you have no clue what the real issues are.
        • Huge load of windows app types?

          No thanks!

          One of the biggest problems with Windows is the apps that get built for it.

          Does Apple need apps written like Windows apps? No.

          Do Apple users need Windows developer thinking & design? No!

          Does Apple have a load of developers? Yes!

          Swift looks pretty good so far in that it will allow a softer entry point and faster simple app development than Objective-C will.

          I'd much rather see more development by people thinking in terms of the platform and design ethos than a load of ported programmers who may know more esoterics about a language but less about people and the platform they are developing for.
          • Are all Apple fans completely brain dead?

            More comments from filth who has obviously never coded a day in his life. It took me about an hour to learn Objective-C. The language was less of an impediment than the horrible dev environment (XCode is a joke) and the lack of decent controls (not that filth like you even know what controls are.)
          • When all else fails

            I notice you resort to personal attacks as soon as anyone questions your bizarre and usually bad logic.
            Michael Alan Goff
        • Oh please

          you think ordered lists are some form of magic, known only to Dumbledore at Microhogwarts?

          I think people are going to get along just fine.
          • Every time you post...

            you prove that you are completely brain dead. You obviously don't even know how developers use LINQ in their code. Not surprising given that you are a moron in desperate need of psychiatric counseling. Let's have some fun. Show me some sample code in Swift for joining two lists on a common key, removing items from the result where the items in list B have a Price greater than 5, and then order the result based on the ReleaseDate of items in list A, skip the first 2 items, and then select 10. And I'm not talking about LINQ to SQL, LINQ to objects. Provide the code, or admit your filth. Which will it be?