A JavaScript Developer’s Take on Apple’s Swift

June 24, 2014

This year Apple succeeded in making their 2014 WWDC one of the key talking points throughout their entire developer community. The event’s keynote contained what many analysts predicted, a new point release of OS X (10.10) as well as a new major release of iOS (8). However, Apple decided to treat developers to a brand new programming language that they hope will supplant Objective-C, Swift.

Hello, World Swift

Apple wanted a language that would be modern, fast and safe. To anyone who has done a bit of Objective-C in the past, hearing the term “modern” should be music to his or her ears. Apple has delivered in that regard, with adding plenty of syntactic sugar onto the language. It is evident that they were inspired by modern scripting languages such as Ruby, Python, Groovy and of course JavaScript.

I’m now going to put my JavaScript goggles on and give you my first reactions of things I like, hate, and don’t care too much about when it comes to Swift. Disclaimer: I am by no means an expert in Swift. I do not think anyone outside of those who worked on the project is at this point, so I may draw some invalid conclusions. Please feel to correct and/or debate me on them in the comments below.

The Good


One of my biggest pet peeves with Objective C is that any kind of source code written in the language looks like a tornado of non-alphanumeric symbols (reminds me of Perl & PHP).

In contrast, Swift looks very elegant and minimalistic, like the modern scripting language it’s trying to be. Just the little simple things like invoking functions with (), or declaring a string variable using “” is a pleasant sight.


One of my favorite features of Swift is “String Interpolation” (a.k.a templating). Using () you can build a string using constants, variables located in scope as well as the results of expressions.

let constantString = "Hello";
let intValue = 1;

var helloWorld = "\(constantString) World; 1+1 = \(intValue + 1)";

Simple definitions of Arrays and Dictionaries

Now you can define arrays and dictionaries (key/value maps) using shorthand operators ([], [:]).

// Arrays
var emptyArray = String[]();
var emptyArrayAlt:String[] = [];
var myArray = ["foo","bar","baz"];
println(myArray[1]); // returns bar

// Dictionaries
var emptyDictionary = Dictionary();
var carMakesModels = [
    "Honda"  : ["Civic", "Accord", "S2000"],
    "Toyota" : ["Corolla", "Camry"]
println(carMakesModels["Toyota"]); // returns [Corolla, Camry]


Looping an array or dictionary has become greatly simplified compared to Objective-C. Especially for dictionaries you no longer need to call the objectForKey method as you now specify a tuple for your key and value in the iteration statement.

// Looping an array
for value in myArray {
    println("Value is: \(value)");

// Looping a dictionary
for (key,value) in carMakesModels {
    println("Make: \(key) and Model: \(value)");


In Swift you can now write functions as you would a function expression in JavaScript. One of my other favorites is that now your function can return a tuple. You no longer need the overhead of defining an array, dictionary or some sort of data structure when you want to return multiple values. It is similar to returning a plain JavaScript object, and you can interact with it as one.

func getValues(input:String) -> (result:String, count:Int, valid:Bool) {
    var result = input;
    var count  = countElements(result);
    var valid  = true;
    return (result, count, valid);

var values = getValues("Hello World");
println("\(values.result) \(values.count) \(values.valid)");


Defining classes is vastly improved in Swift. It is now far simpler and more intuitive, especially when extending other classes.

class Car {
    let make:String;
    let model:String;
    let price:Int;

    init(make: String, model: String, price:Int) {
        self.make = make;
        self.model = model;
        self.price = price;
    func drive() {

class SportsCar: Car {
    let isExotic:Bool;
    init(make: String, model: String, price:Int, isExotic: Bool) {
        self.isExotic = isExotic;
        super.init(make: make, model: model, price: price);
    override func drive() {
        println("Driving fast");

var toyotaCamry = Car(make:"Toyota", model:"Camry", price:20000);
toyotaCamry.drive(); // prints "Driving"

var ferrari458 = SportsCar(make:"Ferrari", model:"F458", price:200000, isExotic: true);
ferrari458.drive();  // prints "Driving Fast"

REPL and Playgrounds

For any developer working with a scripting language a REPL is invaluable, especially when toying with ideas. The conventional compile & run cycle does not allow for rapid experimentation, thus the addition of a REPL and live-reload Playgrounds are great things to have.

The Bad

Can not change type after variable assignment

Swift allows you the privilege of not having to define the type of a variable. However, once you assign a value, the variable is locked in to that type. This is unnecessarily confining in my opinion.

var myValue = "FOO";

myValue = 5; // Compile-time error

Conditional Statements do not evaluate expressions

A great thing about JavaScript is that it will evaluate objects and literals as booleans inside a conditional statement. In Swift, these expressions must explicitly return a boolean value. For those who used to writing JavaScript will find this cumbersome.

var intValue = 5;

// Works
if(intValue > 0) {
    println("Hello World");
if(intValue) {
    println("Hello World");

Optional semicolons and parenthesis in conditional statements

Call me old school but I like to explicitly end my statements. This is also a topic of contention in the JavaScript community. I also like to put parenthesis around if conditionals. I believe it helps readability and can lead to a lack of uniformity across code bases.

Optional Values

The Swift programming guide did a poor job describing this feature; this link does a much better job of it. I do not like the fact that you cannot assign nil (null) to a non-optional value (most of the variables that will be created).

var optionalValue: String? = "FOO";
println(optionalValue); // FOO
optionalValue = nil;
println(optionalValue); // nil
optionalValue = "ABC";
println(optionalValue); // ABC

var nonOptionalValue = "FOO";
nonOptionalValue = nil; // Error

The Superfluous

Parameter name aliases in functions

In Swift you can write an alias to a parameter that will be used inside the function. This alias is different than the parameter name used when invoking the function. Why not just pick one correct name? This is a code smell in my book.

func calculate(arbitraryValue value:Int) -> Int {
    return value * 2;


I understand the reasoning behind this, but I believe this could have been implemented in a much simpler fashion. Why not do it as you would in JavaScript and assign a reference to a variable (or constant in this case)?

typealias UnsignedInt = UInt16;


From a JavaScript developer’s perspective Swift is a leap in the right direction coming from Objective-C. Like with any first impression of a new language, there are some things that just do not sit right. I feel the language is in an identity crisis caused by its own fundamentals. It tries to be modern but many of the features are strained by its desire to be safe for the developer. In trying so hard to be modern it makes some great deviations from the beaten path of procedural programming, but even those moves are hindered by its overbearing protection and inflexibility. I see Swift as a complete replacement of Objective-C and do look forward to seeing many existing libraries (primarily Cordova) being rewritten in Swift in the not-too-distant future. With only four years of development Swift is still immature. However with Apple’s full support as well as an emerging developer community we should expect promising improvements in the coming months and years.

Further Reading

Bershadskiy_Stan square
Stan Bershadskiy is an architect at Modus Create and specializes in all things JavaScript with vast knowledge in Sencha frameworks. Recently, he has directed his focus towards React Native and has co-authored The React Native Cookbook, which was released in December 2016. Stan is located in New York City and can be found co-organizing NYC.JS Meetups and presenting at conferences around the country.

  • Chris

    “Can not change type after variable assignment” and “Conditional Statements do not evaluate expressions” are the result of a strong-type system. You may as well argue against C# or Java at those points…

    • Dom DiCicco

      In his defense, he said he had is JavaScript goggles on.

    • HiRez

      I hated these things when I first started with Swift and I did find them cumbersome and restraining. But they are there for a very good reason. There is no question the number of runtime errors in my code has gone down significantly in Swift vs. my Objective-C code. Once I get past the numerous compiler errors and frequent optional-checking, I find my code is rock solid in production, so much so that hard crashes/hangs while running are almost a thing of the past for me.

  • amezghal abdelilah

    for parameter name alias in function, you can use

    func calculate(#arbitraryValue :Int) -> Int {
    return value * 2;
    if you add # before the param name, the name will be used for both…

    Ah and you forgot to mention the perfect operators overloading implementation in the “The good” section…

  • Peter

    I will call you Old School! :)

    After many years of writing a lot of JS and Lua code I can tell you that there is no added value for code readability in having mandatory parenthesis in if statements and semicolons at the end of statements.

    In fact code I find code without parenthesis and semicolons much more readable.

    • HiRez

      I agree. After doing a lot of Swift programming for the last 2 years, I find languages with if-parens and semicolons look unnecessarily cluttered. Though it did look odd to me at first as well. As with most things, just a matter of getting used to it. After a while, it won’t bother you.

  • André Teunissen

    Great explanation but what about looping through Array < Dictionary > ?

  • caweissen

    Excellent review of the new language, can’t wait to see what Modus comes up with using Swift.

  • caweissen

    Excellent review of the new language, can’t wait to see what Modus comes up with using Swift.

  • http://filimanjaro.com Filip Zawada

    I’m a bit terrified after skimming through this article.

    All things that you described as “bad”, are good or great features of Swift.

    > I do not like the fact that you cannot assign nil (null) to a non-optional value (most of the variables that will be created).

    That’s one of the most powerful features of swift. It reduced number of run-time errors in my app significantly, since compiler catches them before I even run the app.

    • Stan Bershadskiy

      I appreciate the comment. The point of this post was for it to be opinionated from a JavaScript developers perspective. Some developers may enjoy the restrictions or guidelines imposed by a compiler, while others prefer the flexibility of a more dynamic language. Personally, I lean more to the flexibility side of things as it gives you more opportunities for creativity. To each their own :)

      • Derrick Ho

        RE:> I do not like the fact that you cannot assign nil (null) to a non-optional value (most of the variables that will be created).

        In Swift 2 you actually are allowed to set nil to a non-optional value.
        For example String! Will accept nil, but you are giving the compiler a guarantee that by the time String! Is used, it will have a non-null value.

        var aNonOptionalVariable: String! = nil // String! Is treated like a String
        aNonOptionalVariable.characters.count // No compile-time check since you “promised” the variable will be non-nil by the time it is used.

        Implicitly Unwrapped Optionals, (IUO for short) are used quite a bit when developing links to storyboard elements. Try dragging a UIView to your UIViewController and it will create:

        @IBOutlet weak var aView: UIView!

        We need to use IUO because aView won’t be able to have a value until after the init method is called; More specifically, it will be created after the loadView() method is called.

        IUO allow you to called the view without using ? everywhere.

        i.e. aView.backgroundColor = .redColor()

  • Gabriel Peart

    About this topic: “Can not change type after variable assignment”

    Just type as Any or AnyObject.

    Any can represent an instance of any type at all, including function types.

    AnyObject can represent an instance of any class type.

    var myValue = “FOO”;

    myValue = 5; // Compile-time error

    var myValue:Any = “FOO”;

    myValue = 5; // Works

    • Stan Bershadskiy

      Thank you for that bit of info. I did not know those types existed!

  • Liero

    Type safety (cannot change type after variable declaration) prevents you from a lot of mistakes. It helps compilers to do better compile time checking. It should be among The Good, if not Very Good. In fact it does not limit you anyhow.
    Second, the fact that IF statement accepts only boolean expression is also great. it prevents developers from very common mistakes like if (i=1) instead if(i==1). it has been proven The Good in many lanugages, C# for example.

    • Michiel van der Blonk

      Type Safety, yes. But the assignment of a variable happens at runtime, after which it is fixed. Finding out the type is then much harder for a compiler. Does the Swift compiler do this correctly?

      • http://capnslipp.com/ Cap’n Slipp

        Does the Swift compiler find out the type at runtime correctly??? If that’s what you’re asking… um, sure. That’s what `Mirror(reflecting: …)` is for. Also, lldb has zero problems reporting the types of data at runtime, so yup I guess, as correctly as correctly can get.

      • Liero

        assignment of variable happens at runtime, but the variable type is determined at compile time in swift and every further assignment statements can be easily checked at runtime.

        Being that said, variable type at runtime is not important, because everything has been checked at compile type. Determining variable type at runtime makes only sense when thinking about polymorphism, but that’s another topic

  • http://zettlina.com greench

    Swift Cheat Sheet link is dead. If you can, please update it :)

  • http://capnslipp.com/ Cap’n Slipp

    So wait… languages that use a lot of `()`s and `{}`s don’t qualify as “a tornado of non-alphanumeric symbols” but languages that use a lot of `[]` do?

    I think what you meant to say here is “One of my biggest pet peeves with Objective C is that any kind of source code written in the language looks like Lisp; whereas I’m familiar and comfortable with languages that look like C++.”

  • http://capnslipp.com/ Cap’n Slipp

    “Now you can define arrays and dictionaries (key/value maps) using shorthand operators” Since 2012 (Clang 3.1), Objective-C has had these also.

    Your examples in using Modern Objective-C:

    // Arrays
    NSArray *emptyArray = [NSArray new];
    NSArray *myArray = @[@”foo”,@”bar”,@”baz”];

    NSLog(@”%@”, myArray[1]); // returns bar

    // Dictionaries
    NSDictionary *emptyDictionary = @{};
    NSDictionary *carMakesModels = @{
        @”Honda” : @[@”Civic”, @”Accord”, @”S2000″],
        @”Toyota” : @[@”Corolla”, @”Camry”]

    NSLog(@”%@”, carMakesModels[@”Toyota”]); // returns ( Corolla, Camry )

What We Do

We’ll work closely with your team to instill Lean practices for ideation, strategy, design and delivery — practices that are adaptable to every part of your business.

See what Modus can do for you.


We're Hiring!

Join our awesome team of dedicated engineers.