Less than a year ago, Apple introduced Swift to the developer community. While Objective-C is a very powerful and mature language, Apple obviously wanted to freshen up its development eco-system with a new language borrowing concepts from modern, functional and script-like languages.
Swift Essentials, written by Alex Blewitt is a jump-start into iOS programming with Swift. Even though it might be helpful to already have some iOS-programming background, it's absolutely not a must-have and every iOS-beginner will also find her or his way into Swift programming because the book also covers the very basics of this new language and the reader is invited to use the Xcode IDE on every page.
The book starts with explaining important types and concepts and also how to use Swift on the command-line. String and numeric literals are introduced as well as the concepts behind variables and constants. Furthermore, the reader will learn about control structures and how to use the new "Playground" in the Xcode which has been part of Xcode since Swift was introduced.
After providing the reader the basics of the new language and the development environment, the author continues with showing how to develop iOS applications with Swift. The reader will learn how to create simple, programmatic user interfaces and how to use Xcode's built-in Storyboard feature to define more sophisticated UIs. For completeness, there is also a section about developing custom user interface elements that can be used within Storyboard just like Apple's built-in widgets.
Another important aspect of iOS applications is connecting to servers to exchange data. In the section "Parsing Networked Data" the author shows how to connect to servers and how to deal with the received data. Whereas JSON might be the dominant data format for mobile applications, the reader also learns how to handle XML structures.
In the last section, all of the above will be put together to implement a GitHub repository browser for iOS - thus, the reader will have a fully working sample application in his IDE by the end of the book, which is a great starting point for collecting further experience with Swift.
Besides providing all the information stated above, the author also put a lot of additional background information into the book. So in many cases, the reader will not only find the pure description of the Swift concepts but also learn about the context of those concepts. The reader will also find information on more sophisticated concepts like asynchronous programming and on how to create command-line scripts to support day-by-day jobs in the shell.
Recently, InfoQ caught up with the author Alex Blewitt about the book.
InfoQ: Last summer at WWDC, Apple took off the covers of Swift and I think it was a real surprise for developers. New programming paradigms being implanted into an existing ecosystem of operating systems and development tools - and nobody could be sure if Swift would really take off. Nonetheless, you had your book about Swift finished not very much more than 15 weeks after that, so you obviously had confidence that Swift won't be dead on arrival. Could you tell us, what made you feel it's worth to do that kind of a deep dive?
Alex: Objective-C was my first true programming language, and my heart has been with the various Frameworks that made up Apple OS X since before Apple bought them from NeXT. However, having been developed a long time ago (pre-Java, for example!) a lot of what would now be considered best practice simply wasn't available, such as modules or namespacing, or the ability to avoid some of C's legacy problems such as pointers and buffer overruns. Swift is really built upon the foundations (and compatibility with) Objective-C frameworks, whilst creating a source syntax that is much more modern and based upon functional programming techniques as well as object-oriented ones.
It's also clear that although the power of Objective-C's dynamic nature allowed evolution of both frameworks and the applications that are built upon them, the flexibility wasn't required in almost all cases and simply added to the execution cost of each method call. Although CPUs have been fast enough for some time (I had an original NeXT station with a 68040 processor, running at 25MHz doing the same thing!) the focus is now on power consumption and minimising latency to main memory. With moving from a dynamic dispatch to a more static oriented dispatch, the compiler has better visibility to method calls and can perform in-lining in a way that modern runtimes (like Java) do to increase performance and in a way that Objective-C cannot. This is a win for Apple's customers, not only because code can execute faster, but importantly take less CPU instructions and with less random access memory lookups that can be cached on the processor's L1 and L2 caches. This in turn means less battery usage, which means that battery operated devices will last longer.
It's a bit too early to definitively claim that Swift is the future, but it's certainly been actively developed since its initial release and with Apple's recent release of ResearchKit under an open-source license at GitHub, the examples were 100% Swift, it's a safe bet to say that Swift will be with us for some time. If Swift is open-sourced and made available for Linux then its success is guaranteed.
InfoQ: What are the features that would make an experienced Objective-C programmer use Swift for future apps? What kind problems could be solved more elegant or easy with Swift, now?
Alex: It depends how experienced they are :-) Those that are used to method swizzling and dynamic introspection of selectors will likely be frustrated since these rely on the dynamic nature of Objective-C which Swift eschews. Having said that, it's possible to write a Swift class that uses the Objective-C runtime by using the @objc annotation - though this is largely a function of backwards compatibility requirements for interoperability with Objective-C frameworks.
However, the majority of Objective-C developers will find moving to Swift a relatively simple exercise. It's like migrating from C to JavaScript - the syntax is roughly the same, but you are less bothered with memory management and string operations, so a competent C developer will be able to pick up JavaScript fairly quickly. In that regard, Swift is similar - in fact, JavaScript developers may be able to pick up Swift quicker than they'd be able to pick up Objective-C.
The majority of frameworks available in Swift are in fact the existing Objective-C frameworks, which are exposed as a Swift module - so all the existing knowledge will translate. Some of the methods are confusing though, if only because the Objective-C method name was similarly confusing. For example, all of the UITableViewDelegate methods are called "tableView" in Swift, which doesn't really make sense unless you know the history.
I think once Swift has cracked the binary backwards compatibility guarantee (which they'll have to do at some point) we'll see Swift-only frameworks, which will probably evolve from the Objective-C frameworks with more sensible names.
To answer the elegance question - since Swift has generic collections, it's easier to deal with a List of String than it is in Objective-C. It also means the compiler can help more with the processing of functional data, such as the map/filter/reduce patterns that have come into play in other languages. There's also less verbose content - you only deal with a .swift file and not separate .h and .m files, for example, which can make compilation faster.
InfoQ: In the meantime, Swift 1.2 was already released. That's a very tight schedule and not easy for an author writing about Swift, is it? How would you describe the maturity of Swift right now?
Alex: When I started writing the book, Swift 1.0 was available - then just before it was published, Swift 1.1 came out and so I fixed up minor code comments and patterns to reflect the new version in the book. Swift 1.2 has added some new features - the ability to have multiple expressions in an if-let block is definitely a bonus - but there have been few source conventions that aren't backward compatible, and Xcode has support for converting Swift 1.1 code to 1.2 to fix up any remaining issues that are required.
I would put Swift on the early adopters curve right now; it may not be something that everyone wants to work with or deal with at present, but there are a number of heavily used applications on the AppStore (and not by Apple!) that are using Swift.
The advantage of Swift is that the binary is statically linked with its Swift dependencies, so once you've compiled and built the app, it will continue to run even if Swift itself evolves. It may mean that the source has to be updated if compiling with a newer version of the compiler, but the version that's installed on end users' phones shouldn't require any changes if Apple updates the OS. This can be used to migrate parts of an application to Swift whilst leaving the rest in Objective-C, but it's not going to be long before Objective-C and Swift trade places on the TIOBE charts.
I think Swift will continue to be released with minor changes for a couple of years - I doubt we'll see Swift 2.0 at WWDC this year, for example. But when Apple announces the binary backwards compatibility which will allow Swift frameworks to be created, that's when it can be considered mature.
InfoQ: What are the features that are still missing or the bugs that need to be addressed? Is there any showstopper that would prevent it being used in production environments?
Alex: I don't think there's anything missing in the language or libraries, but there's always going to be new features and enhancements that makes it better. For example, in Swift 1.1 you could use if-let statements to execute a block of code selectively depending on whether an Optional value had some data or not. Swift 1.2 made that better by allowing you to use multiple tests in one if-let block, but it doesn't change the fundamental functionality that existed before. There's also new API - for example, Set has been bridged into Swift from NSSet, which was missing previously. There's also no guarantee of backwards compatibility for compiled binaries, which means that frameworks in Swift are either open-source (and which are imported in as source into the app) or ones provided by Apple.
Probably the only point of concern with Swift is Xcode's stability, or more specifically, SourceKit, which is used to parse and process Swift source files. Earlier releases were notoriously unstable, with messages "SourceKitService crashed" appearing regularly in earlier releases. Although these have improved it's certainly a source of frustration at the development stage.
InfoQ: Swift is still a very young language and people might think it can't compete with Objective-C which is now optimized for decades. Is there a way to compare the performance of Swift to that of Objective-C? Does Swift already leverage every technique that leads to optimized performance?
Alex: There's been a lot of write-ups about comparing performance of Swift and Objective-C, with varying results. Since Swift can natively bridge into Objective-C, using an existing API that returns an NSArray will give a similar performance profile when called either from Swift or Objective-C. However, whilst NSArray objects are always passed by reference, in Swift arrays have a pass-by-value mechanism that performs a mutated copy on demand. So some operations, particularly ones that copy and mutate arrays, may be faster in Objective-C.
There have also been some bugs in the earlier releases of the Swift compiler, which introduced many unnecessary retain and release steps that were only removed when optimisations were enabled. Fortunately this has been corrected in the latest releases.
On the other hand, there's a lot more scope for Swift to become much faster than Objective-C in future. One of the most common optimisations in any compiled language is the ability to in-line method calls, which reduces both stack allocation and improves memory locality. This couldn't happen with Objective-C due to the dynamic nature of method dispatch, but Swift enables this kind of optimisation.
Swift also encourages more uses of structures and other pass by value techniques, which in turn can improve memory locality particularly when dealing with contiguous arrays of objects. In some cases this will enable C like (or C++ like) performance for general objects. For programs that are mainly immutable value types I suspect Swift will have a performance edge.
InfoQ: Most people only think about iOS apps when talking about Swift. But it can as well be used to write OS X applications and even sophisticated shell scripts. Will Swift be the one and only language for the Apple ecosystem sooner or later?
Alex: Swift can be used to write OSX applications, both command line applications as well as AppKit based GUI applications. I think it's unlikely we'll see Swift scripts in OSX for some time, but some of the applications could well be written in Swift in the future.
Apple has been the master of transitions in the past - Carbon to Cocoa, 32-bit to 64-bit, PowerPC to Intel - and it's always brought the new shiny out to run concurrently with the tried and trusted for some time. But as each of the older items was deprecated and then subsequently removed in future releases of the operating system, the path of where developers should be focusing has always been clear.
At WWDC I expect we'll see a new Swift-enabled combined UI for AppKit and UIKit, and plans to move towards supporting Swift as the preferred language by enabling blocks, structs and enums instead of Objective-C classes. If we see that it will be clear that at some point the future of frameworks will be Swift enabled, and from there it's just a matter of time before Apple moves its frameworks over.
InfoQ: Will you still use Objective-C in your future projects?
Alex: Objective-C will always have a special part in my coding heart, and I expect to see it from time to time in the future. But much like my Blueberry G3 iMac and my PowerPC G5 machines (which I still have), they'll be kept around for historical interest only. Swift is the future for Apple, and for my iOS/OSX projects as well.
About the Book Author
Dr Alex Blewitt was introduced to object-oriented programming with Objective-C on a NeXTstation over twenty years ago and has been using the platform ever since. With the release of Swift showing the future of the OSX platform, Alex has also authored the book Swift Essentials. In his spare time and if the weather is nice, he has been known to go flying from the local Cranfield airport.
