The Good and the Bad in Apple’s new programming language Swift

Apple recently announced many changes and updates for the upcoming period. Most of these announcements are in domains of design and leisure and, as such, are targeting end users. However, the announcement of Swift, Apple’s new programming language, has made a splash among developers as well.

As details about Swift are still scarce, developers’ opinions and first impressions still range from positive to negative. The same applies to our own team. That is why we have gathered their first thoughts, impressions and expectations about Swift and sorted them by sentiment.

The Good

Change should be good and a number of good things is exactly what our team sees. They’re ecstatic about the potential overall better performance, fool-proof syntax that assures sustainable code writing and collections that can contain primitive variables (unlike just objects in ObjC). This means less code compared to ObjC, better type safety and no C pointers.

This is what Ivan Blagajić and Mijo Gračanin, our iOS developers, see as the most positive things we can expect from Swift. Danijel Lombarović goes further by calling the code and syntax expressive and elegant. Luka Gabrić, also an iOS developer on the ShoutEm team, adds that a better memory management, which can be quite handy, is also rumored.

Saša Branković, Development Lead at ShoutEm, sums it up nicely:

“It just looks simple and clear and has the fun stuff that you’ll find in Ruby, Javascript and C#. I really dig REPL, being able to just dive into the running app and tinker with code. Also, not having to write semi-colons.”

But there is always some bad that comes with the good. Our team has some convincing thoughts about this as well.

The Bad

As the biggest potential problem with Swift, Luka sees the inevitable transition period in which some new projects will use Swift while others will continue to use Objective-C, creating a dual standard in the market.

Optional brackets, one of the presented novelties, can prove to be a problem if not used in more complex functions. Along with this, Ivan sees public default setting of all functions and class properties as a big con for Swift.

Mijo is a fan of totalitarian system when it comes to programming languages so he doesn’t look at numerous code-writing options as an advantage because it can lead to a mix of different styles in one code. As another drawback, he points out the remaining possibility of creating retain cycles.

Tomislav Grbin is worried that it will probably remain a closed Apple only language and that he won’t be able to use some good language features like optionals and strongly typed collections as much as he’d like, because of dependencies with underlying Cocoa framework and existing objC code.

Development Lead, Saša, concludes with a somewhat grim prediction: It isn’t open-source and it doesn’t run on anything other than Apple runtimes. I sense something of a C# fate there – great language tied to a single platform.

Final Thoughts

But it is maybe unfair to strictly divide these expectations into just “good” and “bad” categories. So Srđan Rašić puts it in perspective nicely:

“When I started with Objective-C I had to say goodbye to my language of choice, C++. I had to say goodbye to the comfort of strong statically typed environment, to the power of generics and to the convenience of operator overloading. I did however get to express an equal number of welcomes; to the runtime reflection one could only dream of doing in C++, to handy and simple lambda expressions (blocks), to code simplicity and descriptiveness, to fast enumeration, to vast framework backing and, most notably, to the ultimate memory management solution – ARC. It was a fair compromise: flexibility of dynamic features over speed and type checking of static features.

But Apple doesn’t compromise. If it’s possible to have best of both worlds, we’ll have it. We’ll have best of many worlds multiplied by 42. We’ll have power of generics combined with flexibility of reflection, safety of statically typed environment augmented by flexibility of dynamically typed languages, low-level bit manipulations with no compromises to extensibility, beautiful syntax of scripting languages and all of its syntactic sugars without overhead of interpreter. We’ll have brake-less switches, first-class type closures, handled overflows, nested functions, optional bindings and, of course, dog-cow. After years of dull stagnation of compiled languages, we’ve got Swift, the syntactic sugar in itself.

Learning Objective-C was fun. Learning Swift will be more fun, even without access control mechanisms – yet.”

What are your thoughts on Swift?