Musings on Swift

Introduction to Swift programming language.

Apple’s introduction of new programming language – Swift, commonly referred to as “Objective C without the C,” caused quite a stir amongst the developer community. Swift is hailed as being simpler, more modern, and interactive compared to its counterparts. Some special features of Swift include:

  • Cocoa and Cocoa Touch
  • Build with LLVM compiler
  • Optimizer and Auto-vectorizer
  • ARC memory management
  • Same runtime as Objective C

At Sourcebits, we always strive to help our team learn new skills and explore new possibilities. And that includes switching teams to learn a new language. Our resident Android expert, Chris Dietz, tells us how he got a bit more than he expected when he was assigned his latest project… start using Swift. Here’s his account of his first week developing with Swift.

A little while ago, I was studying up on iBeacons, defined by Apple as:

iBeacon is an exciting technology enabling new location awareness possibilities for apps. Leveraging Bluetooth Low Energy (BLE), a device with iBeacon technology can be used to establish a region around an object. This allows an iOS device to determine when it has entered or left the region, along with an estimation of proximity to a beacon.

My task was to create a proof of concept linking iBeacons to hospitals, in which a doctor or nurse can automatically get all patients on a floor, room, or bed based on the location and proximity of iBeacons. “Cool!” I thought. “I could whip up something like that in a couple of days.”

“No,” they said. “You will be using iOS and Swift.”

Say what?

I started my career as a C/C++ and assembly programmer focusing mainly on microcontrollers. Before long I moved to the Android mobile development 2.2 era and beyond. I should also mention I don’t adhere to the iOS vs. Android wars that have sprung up over the past few years. I ignore iOS fans who say, “Glad you finally saw the light,” as well as Android lovers who ask, “How could you join those plebes?” To me, both iOS and Android have their benefits and downsides.

“OK,” I said to myself. “This may take longer than I originally thought, but I’m willing to expand my horizons and learn. It may actually be fun using a layout editor and simulator that actually works. It’d be nice to see how the other side lives.”

So Swift.

Comparison between Swift and other languages (chart).

What is there to say about Swift? 
It’s new. It’s different. It’s sexy. I get the sense it tries to be a little bit of everything in one package: both object-oriented and procedural; compiled and interpreted; salt and pepper; peanut butter and jelly; Rocky and Bullwinkle. It’s being touted by Apple and Apple kin alike as a perfect “everybody” language, which may sound familiar if you’ve ever heard someone describe Ruby, Python, C, C++, C#, Object-C, Java, or Haskell. Since I’ve only been using it for a week, I’m going to reserve my judgement pending more experience.

One of the first challenges anyone faces when learning a new language (any language) is syntax. The number one thing that caused the most syntax errors for me in Swift was declarations. I’ll give you an example. In Java, a variable would be declared as so:

String name = “The Good King Snugglewumps”;

That’s it. It’s simple and to the point. I want a String variable called name and equal to The Good King Snugglewumps. It’s like a complete sentence with adjective, noun, verb, and predicate noun. Here’s what Swift wants:

var name: String = “The Good King Snugglewumps”

What is this? Trying to adjust to this is like an English speaker learning Spanish for the first time. They’ll suddenly change the ordering of the adjectives and the verbs, spending the first few days saying “azul luna” (blue moon) instead of the correct “luna azul” (moon blue) while everyone laughs.

Similarly, be prepared to argue with xCode. Your brain will fight it, saying, “This is right!” but the compiler will just laugh and throw red all over your screen. Inferred types help, but it’s inescapable when dealing with writing methods.

iOS 8 plus Swift logos in a mobile screen.

Exploring Swift’s Quirks

In all seriousness, there are aspects I genuinely like about Swift. For one, Swift heavily encourages immutability. Simply declaring “let” on an object will ensure that not only does the reference never change, but the state of the object itself will never change. Structs are also always copied by value which will help maintain overall integrity. However, classes are not, and I could see this easily being confusing as projects expand using both structs and classes.

Another useful little keyword goes like this:



lazy var myObject = MyClass();

What’s that?! A keyword specifically designed for lazy loading.

It may not seem like much, but what lazy loading basically means is don’t load an object until you actually need it. In (Android) Java, this can mean littering your code with a bunch of ugly “if myObject is null then set” statements, making a helper method, or simply not doing it. Now you can reference the object at any time and use it normally just like you would any other object. It’s also possible to combine an object with a closure to defer more computationally heavy initialization until you’re actually ready for it:


lazy var bigStringArray = [String] { 
    var tempArray = [String]() tempArray.append(“String1”) tempArray.append(“String2”) 
    // many more return tempArray 
}

Of course, that’s not the best example because you would never do it. It’ll be useful if you don’t know values at compile time, or the structure is pretty big. You can defer part of the initialization when allocating a class to only allocating objects if and when they’re actually used. I’ll admit, the idea initially made me giddy.

A final weird quirk about Swift is the ability to use Unicode characters. When my team first learned about this we joked about using emoticons and if anybody would be stupid enough to make an entire class in them. I decided to do exactly that.

Code written in emoticons with Swift.

This is working code, and it’s a little hard for me to believe Swift let me do this. Now, unfortunately there aren’t enough emoji to represent everything, so this may take some explanation. This is part of my Patient class.

  • Patient class is denoted as a woman in a wedding dress because it looks the most like a patient in a gown.
  • String is a box with letters.
  • UInt32 is four boxes with numbers. Each box represents a byte so likewise UInt8 is one box, and UInt16 is two boxes.
  • Dictionary<string, anyobject=""> was replace by a book, box of letters, and a “NEW” box.
  • The default values are scary faces because it generally means some error in this case.
  • ID is a keycard.
  • name is a person of some sort.
  • type is a German flag because it’s a type of flag.
  • blood is a water drop because there was no blood drop emoji.
  • iBeacon is a pair of eyes and a bright light.
  • final is replaced with a back arrow over “end”.
  • major is replaced with the finger pointing up and minor is the finger pointing down.
  • The val short for value is replaced by a dog. I like dogs.

To whoever has to maintain this in the future, good luck. I’m rooting for you.

Piotr Gajos, Chief Innovation Officer

Piotr is Sourcebits Chief Innovation Officer. A 2006 Apple Design Award winner, Piotr draws much of his inspiration from film and music, and focuses on leading our Innovation Strategy Workshops, generating new ideas for Sourcebits, and consulting on projects.