Programming iOS 5

Errata for Programming iOS 5

Submit your own errata for this product.

The errata list is a list of errors and their corrections that were found after the product was released. If the error was corrected in a later version or reprint the date of the correction will be displayed in the column titled "Date Corrected".

The following errata were submitted by our customers and approved as valid errors by the author or editor.

Color key: Serious technical mistake Minor technical mistake Language or formatting error Typo Question Note Update

Version Location Description Submitted By Date submitted Date corrected
Printed, PDF
Page xxiv
1st paragraph

It should be "stated" instead of "state" (or some other change) in:

"but, outside that chapter, all code examples, unless specifically state otherwise, are supposed to be running under ARC."

Note from the Author or Editor:
Thanks - fixed in my copy

Peter Olsen  Jul 31, 2012  Dec 14, 2012
Other Digital Version
chapter 12, paragraph preceeding Code Example 12.10

This error report is NOT for ver 5.0 but rather for Matt's new iOS 6 book which I believe is only available on-line. I couldn't find a report form for that edition.

So, below is the paragraph that precedes Code Example 12.10, and I believe Matt means to say " the top of the implementation (.m) file, before the implementation section." If I'm wrong about this then at the very least Matt means to say "...(.h) file"

Here's the current text:

To make a property declaration private, put it in a class extension (Chapter 10). Most commonly, the class extension will be at the top of the interface (.m) file, before the interface section. As a result, this class can use the property or call the accessors but other classes cannot (Example 12.10).

Note from the Author or Editor:
Excellent catch; now fixed.

john kiehl  Feb 03, 2013 
Other Digital Version
Chapter 12, Property Accessor Synthesis, 1st paragraph

This is an error report NOT for ver 5.0 but rather Matt's new ver 6.0 which is currently only available on-line -- and there are no page numbers.

In Chapter 12, in the section labeled Property Accessor Synthesis is this paragraph:

Starting in the Xcode 4.2 application templates, Apple begin following a convention where a synthesized accessor would take advantage of the propertyName=ivarName syntax to give the instance variable a name different from that of the property in that the former was prefixed with an underscore. For example, the AppDelegate class’s implementation section contained this line:

1) there's a grammatical error which should be corrected to read: "...Apple began..."
2) traditionally the underscore was associated with the ivarName not the propertyName, so I believe the text should read " that the later was prefixed with an underscore..."

Note from the Author or Editor:
You are right about begin -> began. Now fixed. Thanks!

You're wrong about which is former and which is latter. The sentence says "the instance variable ... different from ... the property ... the former was prefixed with an underscore". "Former" means the first of the two things I just mentioned, which is the instance variable - which is correct; that's the one prefixed with an underscore.

john kiehl  Feb 03, 2013 
Other Digital Version

In the penultimate paragraph of the iOS 6 draft:

"...A method declaration can go only into an implementation section. But to put a method declaration into the implementation section in this class’s header file is annoying-...."

implementation section ---> interface section (two occurences)

I believe this was a typo.

Note from the Author or Editor:
Now fixed. I really have trouble with these! Thanks for catching it.

Nusret Balci  Feb 20, 2013 
Printed, PDF
Page 10
6th text block

Should be "pointer" instead of "point" in:

"Never mind how we know there really is going to be an integer at the address designated by this point;"

Note from the Author or Editor:
Good catch. Fixed in my copy.

Peter Olsen  Aug 01, 2012  Dec 14, 2012
Page 24
5th paragraph

" A C function is technically a kind of named variable, so you can even create a pointer to a function!"

Actually, as with arrays, it is not necessary to use the address operator with function names: K&R, 2nd Edition, 5.11 "Pointers To Functions", page119

Note from the Author or Editor:
This criticism is correct, and I need to modify the p. 172 code that illustrates (and look for any other place where I needlessly take a function's address - it does no harm, but it isn't necessary either). See on SDK-based development, which makes the same comment. This change is *not* going to happen for this edition of the book, but I have already modified the downloadable code examples at GitHub to eliminate unnecessary (but harmless) ampersand before the name of a function.

Richard Albury  May 14, 2012 
Page 28
2nd to last paragraph

Correct word order from

"all I have to do change is the #define line"


"all I have to do is change the #define line"

Note from the Author or Editor:
Actually what's needed is to delete "do". Thanks!

Peter Olsen  Mar 03, 2012  Mar 22, 2012
Printed, PDF
Page 29
Last two code examples

You use, but don't explain, both const NSString* and NSString *const. Since a const NSString* doesn't make much sense, you could use:

const CGFloat MIDSPACE = 3.0;

instead. Maybe in the next edition (I'm hoping there will be one, of course!), you can talk about the difference between pointer to const and const pointer.

Note from the Author or Editor:
This is really just a mistake on my part. It should have been NSString* const throughout. In the book, I don't want to go any further into the details,which are well covered by Mike Ash,

Peter Olsen  Aug 08, 2012 
Page 63
Warning block on CFTypeRef

Extraneous backslash in

"unless you also typecast to an id, along with a \__bridge qualifier if you're using ARC."

Note from the Author or Editor:
Already corrected in my copy, thanks!

Peter Olsen  Mar 03, 2012  Mar 22, 2012
Page 74
Class Methods > Factory Methods

The Font class method fontWithName:size: is printed with the 's' in size capitalized. A nit, admittedly.

Note from the Author or Editor:
Good catch; now fixed in my copy!

Anonymous  Feb 10, 2012  Mar 22, 2012
Page 94
3rd paragraph

The statement:

"Remember, though, that you can do this only if the class you're talking to has declared a property corresponding to the accessor methods in question."

isn't correct. It may be good form to use property syntax only for declared properties, but you can use property syntax anytime.

Similarly, on page 95, the statement:

"That's how I knew I could use property syntax as a way of calling a setter method"

also implies property syntax is limited to properties. Any setter method can be called with property syntax. In fact, any method without arguments can be called with property syntax:

NSString *s = @"Hello";
NSLog(@"Bad form, but works: %@", s.uppercaseString);

Note from the Author or Editor:
Yes, I've thought about this and whether it should go into the book, and it seems to me that it should not. It is true that you can say s.uppercaseString and I've done it myself, but the fact that this is possible is effectively a linguistic bug. Let's leave this note here as a reminder, but I'm not going to take any action for this edition.

Peter Olsen  Mar 03, 2012  Mar 22, 2012
Page 123
InfoPlist.strings paragraph

extra parenthesis in "(strings files are discussed in ) Chapter 9)."

Note from the Author or Editor:
Good one - deleted extra right paren.

Peter Olsen  Mar 04, 2012  Mar 22, 2012
Page 144
Steps to create nib and class

When creating a new class, the name of the class happens in step 3 (along with the name of the superclass), not step 4.

Also, at least in Xcode 4.3, step 4 for both the nib and the class should be "Click Create" instead of "Click Save".

Note from the Author or Editor:
Very nice catch; these instructions must have been describing an earlier dialog sequence (in Xcode 4.0, perhaps). We now read:

3. Name the file _MyClass_. The dialog also offers you a chance to specify what superclass the new class should be a subclass of. Make sure this is NSObject. Click Next.

4. Make sure you're saving into the Empty Window project folder, that the group is Empty Window, and that the target is Empty Window (and checked). Click Create.

Peter Olsen  Mar 04, 2012  Mar 22, 2012
Page 155
Numbered steps 2 and 3

"Call it MyLabel" comes one step too late (this dialog sequence must have changed when Xcode 4.2 came along). So, cut that from step 3, and now step 2 should start: "Call the new class MyLabel. Make it a subclass of UILabel."

Thanks to David Turetsky for wrangling this one.

Matt Neuburg
Matt Neuburg
Jun 25, 2012  Dec 14, 2012
Printed, PDF
Page 164
2nd paragraph in "Quick Help"

Missing word "be" in "A slightly reduced version of the same Quick Help documentation can (be) displayed as a small floating window..."

Peter Olsen  Sep 04, 2012  Dec 14, 2012
Page 180

View -> Show Debug Area should be View -> Debug Area -> Show Debug Area. This same mistake also happens the only other time I mention this menu, on p. 106. Perhaps this is something that was once correct but changed when Xcode itself changed. Anyway, this is fixed in my copy now.

Matt Neuburg
Matt Neuburg
Jul 21, 2012  Dec 14, 2012
Page 188
Watchpoint block

At least with Xcode 4.3, the default debugger is LLDB, and it seems that watchpoints are still not available, so you can only set watchpoints if you change the debugger to GDB.

The note about GDB versus LLDB on the next page says LLDB cannot see instance variables declared in a class's implementation section, however it appears that it now can (this, however, was tested in 4.3.1, not 4.3).

Note from the Author or Editor:
Thanks for alerting me to this. I've changed the text accordingly. In my opinion LLDB remains unreliable, but it is the default for new projects and readers to need to be aware of that fact, so I've done that.

Peter Olsen  Mar 07, 2012  Mar 22, 2012
Page 189
last line

Missing "to" in "so as not to have keep switching between the Simulator and Xcode."

Note from the Author or Editor:
Thanks - inserted "to" in my copy, but this won't go into the March 2012 printing.

Peter Olsen  Mar 09, 2012  Mar 22, 2012
Page 220-221
Code sample and description of categories

I love the book but couldn't get categories to run as the author describes, so after looking for advice online I imported the header file of my category into the appName-Prefix.pch file (in the supporting files group). Having done this everything works, but is this the correct thing to do? Is it good coding?

Note from the Author or Editor:
See the online project version of the code at (the one you want is "ch10p220category"). Any class that wants to *use* this category must import the header. Importing the header into the pch file, thus effectively importing it into *all* your classes, is perfectly legitimate!

Although posed as a question, this is also a good erratum because it implicitly points out that I failed to mention in the text the need for such importing. I'll see what I can do about that. Thanks!

antlev  Mar 30, 2012  May 18, 2012
4th para

Even your app does use ARC...

should be

Even IF your app does use ARC...

Note from the Author or Editor:
Good catch. Inserted "if".

Peter Baum  Mar 01, 2012  Mar 22, 2012
end of 5th para

and has no effect the variable’s persistence or its global nature.

should be

and has no effect ON the variable’s persistence or its global nature.

Note from the Author or Editor:
Good, thanks. Inserted "on".

Peter Baum  Mar 01, 2012  Mar 22, 2012
Page 317

Formatting and extra character issues (actually the same thing) between readonly and readwrite. Fixed in the manuscript (whole thing caused by a single wrong character, an underline that should have been a plus) but presumably won't make it into the print run in March.

Matt Neuburg
Matt Neuburg
Mar 10, 2012  Mar 22, 2012
Page 336
last line

Should be "certainly" in "It is improbable that you would want to subclass UIWindow and substitute an instance of your subclass as the app’s main window, but you can certain do so."

Note from the Author or Editor:

Peter Olsen  Apr 09, 2012  May 18, 2012
Page 930
first code example

line 5 of the code example reads:

- ( void ) panning: ( UIPanGestureRecognizer * ) p {
CGPoint delta = [ p translationInView: v.superview ];

This should be:

CGPoint delta = [ p translationInView: vv.superview ];

Note from the Author or Editor:
p. 482 in my copy. Good catch. This mistake happened for a complicated reason: in my testing copy, there was also an ivar "v", pointing to the same view as "vv", so the code still compiled and worked, more or less accidentally.

Joshua Davies  Apr 20, 2012  May 18, 2012
Page 1103
first code example

The second line of the first code example on the page reads:

float width = sc.bounds.width;

This should read:

float width = sc.bounds.size.width;

Note from the Author or Editor:
Page 572 in my copy. You're right, of course, and the reason this mistake happened is that in fact in my Zotz app I no longer use that code; I use the code on the next page! This mistake should be fixed in the next printing.

Joshua Davies  Apr 27, 2012  May 18, 2012