Comer Randy - Programming iOS 8: dive deep into views, view controllers, and frameworks

Aut lego vel scribo; doceo scrutorve sophian.

On June 2, 2014, Apples WWDC keynote address ended with a shocking announcement: We have a new programming language. This was surprising in several ways:

Having picked themselves up off the floor, developers immediately began to examine this new language Swift studying it, critiquing it, and deciding whether to adopt it. My own first move was to translate all my existing iOS apps into Swift; this was enough to convince me that, for all its faults, Swift deserved to be adopted by new students of iOS programming, and that my books, therefore, should henceforth assume that readers are using Swift.

Therefore, Swift is the programming language used throughout this book. Nevertheless, the reader will also need some awareness of Objective-C (including C). There are two chief reasons for this:

Because Swift is new, I have had to settle on my own conventions for presenting and describing code. The most important question has been how to state the name of a method. My solution is to give the methods Objective-C name . As an example, what is the name of the method that you call when you set a value using keyvalue coding? The actual call, in Swift, would be something like this:

But when I give the name of the method being called here, that name is setValue:forKey:. This choice has several advantages:

Similarly, I will speak of the setValue: parameter, even though, in an actual Swift method call, the name of that parameter appears before the parentheses, with no colon.

The grand exception to this rule is my treatment of initializers. Here, the difference between Objective-C and Swift is greater than a simple shorthand can readily encompass, so I give the initializers name as you would implement it . For example, in Objective-C, the default initializer for a UIView is initWithFrame:. In this book, I will call that initializer init(frame:). The same thing applies to what in Objective-C would be class factory methods with a corresponding initializer: when I want to mention what in Objective-C would be the UIImage class factory method imageNamed:, Ill call it init(named:).

This treatment of initializer names has the great virtue that the name clarifies instantly that such a method is an initializer. Swift effectively abolishes class factory methods and brings such methods into the fold of formal initializers; my treatment of their names is a way of supporting and adopting that innovation.

Again, this convention requires some mental translation on the readers part, because in Swift the way you would name an initializer when you implement it is not the same as the way you would name it when you call it. If you were to override this method in a UIView subclass, youd override init(frame:); but if you were to call it to create a new UIView, youd say UIView(frame:). This mental translation, however, is hardly objectionable, as it is a practical fact to which every Swift user is already habituated.

So much for Swift. A new language is big news, but Swift is not the only big news connected with iOS 8. Nor is it the only welcome news. Ive been arguing for years that Apple needs to check the rampant growth and evolution of the basic Cocoa Touch APIs and concentrate, for one release at least, on rationalizing the changes that have accumulated, often seemingly by random accretion, over the years. iOS 8 appears to do exactly that. To give just a couple of obvious examples:

Such rationalization permeates iOS 8, and I have eagerly adopted it, even where the prior approach is not yet deprecated. You could still create popovers and alerts the way we created them in iOS 7 and before; and obviously if you wanted your code to run on iOS 7 as well as iOS 8, youd have to. But in this edition I behave, in effect, as if the old way didnt exist. Its the business of this edition to teach iOS 8, not to help you write backwards-compatible code; if you want to know how to deal with popovers (or anything else) in iOS 7 or before, consult an earlier edition of the book.