Programming iOS 6, 3rd Edition

Notes on the Second Edition

In order to describe the relationship of the second edition of this book with the first edition, it will help if I first recap the recent history of iOS and Xcode versions.

At the time I started writing the first edition this book, system versions 3.1.3 (on the iPhone) and 3.2 (on the iPad) were current. As I was working on the book, iOS 4 and the iPhone 4 came into being, but iOS 4 didn’t yet run on the iPad. Subsequently iOS 4.2 emerged; this was the first system able to run on both the iPhone and the iPad. At the same time, Xcode was improved up to 3.2.5. iOS 4 was the first version of the system to support multitasking, which necessitated much scurrying about on the part of developers, to adapt their apps to the new world order.

Just in time for my final revisions of the first edition, Xcode 3.2.6 and iOS 4.3 were released, along with the first public version of the long-awaited Xcode 4. Xcode 4 was a thorough overhaul of the IDE: menus, windows, and preferences are quite different from Xcode 3.2.x. Both Xcode 4 and Xcode 3.2.x can coexist on the same machine (up through Snow Leopard) and can be used to work on the same project; moreover, Xcode 3.2.x has some specialized capabilities that Xcode 4 lacks, so some long-standing developers may well continue to use it. This situation presents a dilemma for an author describing the development process. However, for iOS programming, I recommend adoption of Xcode 4, and the first edition of this book assumed that the reader had adopted it.

Such was the situation in May 2011, when the first edition was formally released, describing how to program iOS 4.

Less than five months later, in October 2011, Apple released iOS 5. Some of the features that are new in iOS 5 are dramatic and pervasive, and it is this fact which has necessitated a full revision of this book. At the same time, Apple also released Xcode 4.2, and this book assumes that you are using that version of Xcode (or later), since it is the earliest version of Xcode on which iOS 5 development is officially possible. (It may be that, by deep trickery, one can develop for iOS 5 using an earlier version of Xcode, but that would constitute unsupported behavior.) The first edition had a few mentions of menu commands and other interface in Xcode 3.2.x, but they have been excised from this edition. Xcode 4.2 comes in two flavors, depending whether you’re running Snow Leopard (Mac OS X 10.6) or Lion (Mac OS X 10.7) on your development machine; they are supposed to behave more or less identically, but in fact each has its own bugs, so feel free to try both.

As I was finishing the second edition, in February 2012, Xcode 4.3 was released (for Lion only). Its chief innovation has to do with the organization of files on disk: instead of arriving as an installer that creates a top-level Developer folder to hold its many ancillary files and folders, Xcode 4.3 contains the Developer folder inside its file package (you can see it with the Finder’s Show Package Contents command). So when I speak of the Developer folder in this book, you would need to understand that I mean something like /Applications/Xcode.app/Contents/Developer. I have not found any other major differences between Xcode 4.2 and Xcode 4.3, and in this book I will sometimes say “Xcode 4.2” to mean Xcode 4.2 or later.

The chief purpose of this new edition, then, is to bring the book up to date for iOS 5. You, the reader, might be coming to iOS programming for the first time, so this edition assumes no prior knowledge of iOS 4 or any previous version. On the other hand, you, like me, could be making the transition from iOS 4 to iOS 5, so this edition lays some special emphasis on features that are new in iOS 5. This emphasis could also be useful to new iOS programmers who are thinking of writing apps that can also run under iOS 4. My goal, however, is not to burden the reader with outdated information. The vast majority of devices that could run iOS 4 have probably been updated to iOS 5, and you will probably be right in assuming that there will plenty of iOS 5 users out there, without your having to bother to target earlier systems. And from a pedagogical point of view, it seems counterproductive to describe how things used to be — especially as, if you’re really interested, you can always consult the previous edition of this book! For this reason, some references to the state of things before iOS 4.2 have been excised from this edition.

Here is a case in point, showing my attitude and pedagogical approach with regard to new iOS 5 features in this edition. iOS 5 introduces ARC (automatic reference counting), which changes the way in which Objective-C programmers manage object memory so profoundly as to render Objective-C a different language. Use of ARC is optional in programming iOS, but it is extraordinarily helpful to have it turned on, and in this book I therefore assume throughout that you do have it turned on. In Chapter 12, where I discuss memory management, I still describe what life is like without ARC, as I did in the previous edition; but, outside that chapter, all code examples, unless specifically stated otherwise, are supposed to be running under ARC. If you start a new Xcode project with File → New Project and pick any iOS application template, then if “Use Automatic Reference Counting” is checked in the second screen, you’re using ARC.

iOS 5 also introduces storyboards. A storyboard file is similar to a nib file: it’s a place where Xcode lets you “draw” parts of the interface. The main difference is that a single storyboard file can do the work of multiple nib files. Nib files and storyboard files are not identical, nor are they used identically, but because of their similarity, when I speak of a nib file generically, in this book, I mean a nib or storyboard file, indifferently. I’ll try to indicate this at the time, but the reader will forgive me if I don’t keep saying “nib or storyboard” all the time.

In closing, I should like to say a few words to the people who have, in my opinion, gratuitously criticized the previous edition of this book on one or more of the following grounds:

1. It isn’t a “cookbook” (a book full of step-by-step instructions for creating full working applications).
2. It devotes hundreds of pages to fundamentals.
3. It doesn’t get the reader started early on with hands-on programming; there isn’t even a “Hello, World” tutorial.

All of that is perfectly true. It is also quite deliberate. As both the table of contents and this preface are at pains to make clear, this is not that type of book. To paraphrase Butler’s Law, this book is the type of book it is, and not some other type. That’s why I wrote this book in the first place. The books of the type that these critics seem to want this book to be exist by the score; books of the type that this book is, however, seemed to me not to exist at all. As with all my other books, so with this one: when I couldn’t find the book I wanted, I wrote it myself. I expect this book to be useful to those who need this type of book. People who prefer some other type of book should get some other type of book, and not mar my book’s web page by criticizing it for not being what it was never intended to be.

The purpose of this book is to proceed by focusing on the underlying knowledge needed for an actual understanding of iOS programming. That is precisely the opposite of a cookbook. This book has no simple recipes ready for you to drop into your own code and come up with an app. I don’t give you some fish; I teach you what a fish is and what you need to know to obtain one. The number of books out there that skip blithely past the fundamentals, leaving the reader to pick up Objective-C somehow independently, is painfully huge. The result is that numerous learners are encouraged to try their hand at programming when, to judge from the nature of the questions they ask and the confusion they exhibit, they don’t understand what they are doing.

This book acts as a corrective, which in turn requires that space be devoted to fundamentals. The book does not hold a gun to your head and force you to read all about all of those fundamentals; if you already know everything there is to know about C, about Objective-C, about Xcode, about Cocoa, about views and drawing or whatever (but do you? do you really?), then by all means, skip those opening chapters. But don’t begrudge to the people who need them the explanations that this book contains, as those are the people at whom they are aimed.

That explains why there’s no attempt, in this book, to rush the reader into hands-on programming. My book does not pander to a desire for the false, cheap gratification of making believe that one is a programmer merely because one can parrot some instructions. My book is about knowledge — hard-won, rigorously gained knowledge. It’s about gaining an understanding of what you are doing when you program iOS 5. It calls for a substantial investment of time and thought, and many pages elapse before any practical programming is demonstrated.

Perhaps part of the misunderstanding here is that the critic has not noticed, or has not understood, the sentence earlier in this Preface stating that my book is written in “a pedagogically helpful and instructive yet ruthlessly Euclidean and logical order.” Some people may not know or appreciate what “Euclidean” means. It means “in the manner of Euclid.” Euclid wrote our first surviving mathematical textbook, and it is distinguished by the following remarkable characteristic, among others: if concept or assertion B depends upon concept or assertion A, A comes first. Nothing is postponed; Euclid never says, “I’ll explain/prove/discuss this point later, but for now, just take my word for it.” I have attempted to copy Euclid’s model. So, to take an obvious example, all real iOS apps use view controllers. It’s true, then, that the reader isn’t told what’s involved in constructing a real iOS app until Chapter 19 is reached and view controllers are discussed. But to understand view controllers, you need to know what’s being controlled, namely, a view; hence Chapter 14 and the rest of Part IV. And to grasp the relationship between a view controller and its view, you need to know about Cocoa’s architectural patterns, such as lifetime events and the responder chain; hence Chapter 11 and the rest of Part III. Moreover, a view controller’s view is often loaded from a nib; hence Chapter 7. And all of that requires a knowledge of the programming language you’ll be using, Objective-C; hence Chapter 3. But Objective-C is C; hence Chapter 1. So to reach view controllers any sooner would have been impossible. I rest my case.

Anyway, the complaint that the reader of my book doesn’t get to run any code is factually false. The book is crammed full of substantial code examples — all of which are available for download from my GitHub site (https://github.com/mattneub), so you can obtain them, run them in Xcode, and play with them to your heart’s content. So you can and should, in fact, be running code right from the outset. Nevertheless, the purpose of the code in this book is not for the fun of running it. All of my code is to support your understanding of whatever concepts I’m explaining at that point in the book.

In any case, perfectly good hands-on “Hello, World” tutorials are a dime a dozen; they’re plastered all over the Internet, including at Apple’s own site (http://developer.apple.com/library/ios/#documentation/iPhone/Conceptual/iPhone101/Articles/). You don’t need me to show you that the process of writing a trivial iPhone application is fun and easy.

Still, for those who feel strongly that I haven’t done my job unless I supply a “Hello, World” example, here is one, complete with step-by-step instructions:

1. Install Xcode, and launch the Xcode application.
2. Choose File → New → Project.
3. In the “Choose a template” dialog, under “iOS” on the left (not “Mac OS X”), click Application. On the right, click Empty Application. Click Next.
4. For Product Name, type Hello. Enter a company identifier if there isn’t one already, such as com.yourLastName.yourFirstName. Choose Device Family: iPhone. Uncheck all three checkboxes. Click Next.
5. Navigate to the Desktop. Uncheck “Create local git repository.” Click Create.
6. The project window opens. Press Command-1. At the left, click AppDelegate.m.

7. Work in the editor in the middle of the window. Look for the words “Override point for customization after application launch.” Place the cursor to the right of those words and hit Return a few times, to make some white space. Click in that white space and type these lines of code:

   UILabel* label = [[UILabel alloc] init];
   label.text = @"Hello, world!";
   [label sizeToFit];
   CGRect f = label.frame;
   f.origin = CGPointMake(100,100);
   label.frame = f;
   [self.window addSubview:label];

8. Press Command-R. If you see a dialog asking whether you want to save, accept.
9. After a while, the iOS Simulator application appears, containing a white window with “Hello, world!” in it.

Congratulations. You’ve made a “Hello, world” example. Wasn’t that easy? Wasn’t it boring? Wasn’t it pointless? And are you any the wiser as to what, in fact, you just did? To find out — and, even more important, to know enough to be able to progress further on your own — read this book.