Building iOS Applications with Swift: A Q&A with BJ Miller
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Trina: Do you think Apple’s development of the Swift programming language makes it easier for first-time iOS developers to build an application? The general consensus seems to be yes, but why do you think that is?
BJ: From a language perspective, yes, I think it makes it easier for first-time iOS developers to build an application. iOS and Mac apps, until Swift’s debut in June 2014, were predominantly written in C and Objective-C, outside of some frameworks and needs that required other languages like C++ and Objective-C++, but those were few. Objective-C has a long history, and because of that, is not as modern as some languages. Objective-C recently made several advances to add highly requested features (such as blocks, auto-synthesizing properties, literal values, and more), but it still had the structure of a very old language.
Swift introduces many modern concepts such as higher-order functions, closures, generics, type inference, and more, as well as brief and concise syntax. Apple took many hints from other languages such as Haskell, Rust, C#, and more, to create a powerful language that is not just object-oriented, but also includes functional programming paradigms, makes wide use of closures, and has a more modern feel.
With that said, the language is certainly easier in some respects to learn than Objectives-C, as Swift abstracts away some of the older language cruft. Swift also is starting from a clean slate, and has many more consistencies and uniform design decisions built in to make for a more consistent learning experience. For instance, in Objective-C, the absence of a value could be represented as nil, NULL, NSNull, NSNotFound, zero (0), or many other sentinel values. In Swift there is only one, which is nil, and it is used uniformly throughout the language and Cocoa/Cocoa Touch frameworks. Swift was built with these simple, consistent patterns in mind.
Trina: Traditionally iOS applications have been built with Objective-C and the Cocoa Touch frameworks, which have been built with Objective-C in mind. Given that, how much Objective-C does a new iOS developer have to know before getting started?
BJ: A new iOS developer does not need to know much Objective-C to get started with writing iOS apps, but it certainly doesn’t hurt to learn it either. Many familiar patterns that are in Objective-C are in Swift also, such as named parameters in function definitions. They really help an Objective-C programmer become more comfortable with Swift, but also help a new person understand what each function is doing. I remember learning Objective-C and loving that design, as it illustrated clearly what a function was to do, rather than having three or four unnamed parameters and then having to read the function’s code to find out what each one was for. Other design paradigms and usages are shared between the two languages also, such as protocols and extensions (called categories in Objective-C).
Entire apps can be built solely using Swift. In fact, I’m in the process of writing one that uses only Swift. The language has a lot of functionality that can solve most needs for apps. It has been developed and built for the last 4 years with not only paradigms from other languages, but also interoperability with the Cocoa and Cocoa Touch frameworks, as well as Objective-C. While a new iOS developer may not need to know any Objective-C, they may doubtlessly encounter it if they are working on an existing code base, such as for a large corporation or taking over an app built pre-Swift. In that event, a solid base knowledge of Objective-C will be immensely beneficial. And because the two languages share some behaviors and paradigms, once they understand Swift, Objective-C shouldn’t be that hard to learn.
Trina: Should beginning developers learn Objective-C first, then Swift – or vice versa?
BJ: This is a great question, and I get asked this a lot. I don't believe there is anything that should stop someone from jumping into Swift head-first, as there are already a lot of books, web sites, educational videos, and so on for learning Swift. Most of these are coming from experienced Objective-C developers, too. But as mentioned before, the likelihood that you will encounter Objective-C if you are going to be a full-time Swift developer, or even just developing an app on your own, is pretty high.
Swift is a great language to learn first for iOS app development. Once you are familiar with Swift, and the Cocoa and Cocoa Touch frameworks, I think that learning some Objective-C may be necessary, if not at least very beneficial. The best programmers are the ones who continually learn, not just one language but from many, and exercise that knowledge regularly.
Trina: You have been working with Swift fairly extensively since it was made available in June. What have been the top two or three most exciting features or innovations introduced in Swift that make iOS app development better?
BJ: Learning something new about Swift every single day for months has been an extremely gratifying experience. Coming from an Objective-C background, there are many features in Swift that were simply not available in Objective-C, and others that were improved upon.
One of my favorite new innovations in Swift is the ability to use functional programming features, such as map, filter, and reduce, and being able to treat functions as first-class objects. This means you can pass functions to or return them from other functions, as well as assign functions to variables. While Objective-C had a feature called blocks, the syntax was extremely difficult to understand, which made them not a practical solution for many new developers.
Another feature I really like about Swift is its succinctness. In a concise line or two of code, I can reproduce in Swift what may have taken me five to ten lines of code in Objective-C some times. Often languages that have succinct syntax come at the expense of a lack of clarity, but Swift manages to remain clear in intent while maintaining brevity. One example of this is Swift’s type inference system, as often times it is not required to enter a type for your variables or constants at all since Swift can infer the type from context. Another example is the map function, which iterates through a collection of items, performing the tasks inside a given closure on each item. This is a huge savings over constantly typing lengthy for and for-in loops.
The third feature I like about Swift is the use of optional values. An optional value is like a box, of a particular type (such as Int, String, and so on), and the box may contain a value (such as 5 or “hello”), or it may not contain a value (such as nil). This provides safety from accidentally accessing a nil value. It can also indicate failure when calling a method or assigning a value, which can be very beneficial as when you check an optional value for nil, you can know if the call or assignment succeeded or failed. This is different than Objective-C where you could message nil and interact with it just as if it any other object. When sending a message to nil, Objective-C would just stifle the message. This was helpful in its own way, but if lent itself to a lot of code to check for the existence of nil before doing anything. Swift introduced two powerful constructs for handling optional values: optional chaining and the nil coalescing operator (signified by ??). Optional chaining can quickly call a method or assign a value, or fail gracefully if nil is encountered along the way, and provide you with the optional type of what failed for further examination. The nil coalescing operator is extremely useful and easy to use; simply place an optional value that could have a value on the left, then two question marks, then a default value to assign on the right should the optional value be nil. That one line of code often took five or more in a standard if-else statement in Objective-C.
Trina: In closing, with Apple continuing to innovate and expand the Swift language at a fairly rapid pace, and given the likelihood that at next year’s World Wide Developer’s Conference more exciting developments will be announced, what changes or improvements would you like to see made to the Swift language in the coming year?
BJ: The first improvement I would like to see is more Swift-like interoperability with the Cocoa and Cocoa Touch frameworks. These frameworks were built, as mentioned earlier, with Objective-C in mind many years ago. To integrate them in Swift requires the use of a lot of optional values, because Objective-C could use and pass nil in ways that Swift cannot.
I would also like to see better support in playgrounds for testing memory management as well as asynchronous programming. While you can test these decently well in the Swift REPL (Read-Eval-Print-Loop) from the command line, playgrounds are more convenient to jump to for testing since we’re already writing our code inside Xcode, plus you can take advantage of auto-complete in Xcode unlike the REPL. And speaking of Xcode, while I love the innovations that have gone into Xcode, I really would like a more stable development environment. You’re right that Apple has continued to innovate and expand at a rapid pace, but truth be told, some things have suffered because of this. I would like to see some evolution versus revolution this year from Apple.
No language is without bugs, and since Swift only recently became a 1.0 language, there may be more in Swift than other languages have, but I would urge people not to keep you away from the language. Swift will become a better language by people using it, finding bugs, and submitting those bugs to Apple. Every little bit helps.
Be sure to check out BJ's book, Sams Teach Yourself Swift in 24 Hours, published by Addison-Wesley Professional.