Throughout the book, selectors are often listed without the trailing colon (e.g. drawRect instead of the correct drawRect:).

Throughout the book, the authors speak of “category classes” when they mean Objective-C categories. Drives me crazy.

Talking about Build Schemes in Xcode:

You can duplicate the profile scheme so that you have two schemes: one launching Leaks and the other launching Time Profiler.

It would be great if Xcode schemes worked that way but unfortunately they don't. It's not possible to create custom or duplicate existing actions (such as Profile) in a scheme; the only thing you can do is duplicate the entire scheme with all its actions, which is overkill and hard to manage if all you want is edit a parameter for one of the several actions.

Suffix instance variables (ivars) with an underscore or prefix them with m. I avoid prefixing with underscore because Apple reserves the leading underscore

No, Apple does not reserve the leading underscore for ivars. In fact, they recommend using it. Rob Napier acknowledges this error in the errata.

The discussion of Automatic Reference Counting is confusing in places. The authors say multiple times that, under ARC, you should not call retain, release or autorelease anymore, but fail to mention that doing so is explicitly forbidden. Readers will quickly notices because the compiler will throw an error but I think things like this should be noted in a book.

In the discussion of the singleton pattern, the authors do not distinguish between real singletons (classes of which only one instance can exist) and classes like NSNotificationCenter, which aren't singletons despite the fact that only one instance of these will exist in most apps (in this case, the +defaultCenter). Furthermore, the authors recommend a pattern for implementing a singleton that is no longer the recommended way. The better method is mentioned in the errata.

The protocols UITableViewDelegate and UITableViewDataSource are labeled “classes”.

In most cases, nib files do not lower the performance compared to an equivalently coded UI.

If there is any evidence for cases where NIB files cause significantly lower performance than a UI created in code, the authors fail to mention it. The example they give compares a table cell composed in Interface Builder (with multiple subviews) to a performance-optimized table cell that does its own drawing, which I don't consider equivalent.

The sample code to manually load a NIB file uses -[NSBundle loadNibNamed:owner:option:]. Using the UINib class (available since iOS 4) would be more appropriate and probably faster since UINib caches the NIB file.

once loaded, nibs are cached.

The authors provide no reference for this statement and I could not find any place where this is documented. My understanding is that the UINib class (which is not used in the book) was introduced for exactly that reason and that loadNibNamed:owner:options: does not provide any caching. If this is not the case, I do not see why UINib should even exist. From the documentation for UINib:

An UINib object caches the contents of a nib file in memory, ready for unarchiving and instantiation. When your application needs to instantiate the contents of the nib file it can do so without having to load the data from the nib file first, improving performance.

The authors confound the terms “superclass” and “owning object”:

But a good design practice is to let the table cell handle the delegate and notify its super class.

The cell should notify its owner or delegate. It rarely makes sense for an instance to notify its superclass about an event.

The authors make no distinction between drawing and compositing systems. UIKit and Core Animation (mostly compositing systems, except for some drawing functionality in UIKit) are lumped together with Core Graphics under the term “drawing systems”. I doubt this makes the responsibilities of each framework any clearer to the reader. Later, Core Graphics is named as the primary drawing system underlying UIKit. I see what they mean here, but I would object. The system underlying UIKit is Core Animation. Core Graphics is largely unrelated.

Also:

[UIKit] is the highest-level interface, and the only interface in Objective-C.

Wrong. Core Animation and Core Image also have object-oriented interfaces.

Sample drawing code steps down to the Core Graphics level to set various advanced line drawing options [line join and line width] not available with UIBezierPath when, in fact, UIBezierPath does support these attributes.

iOS does not perform partial view drawing, and setNeedsDisplayInRect: is the same as setNeedsDisplay. The entire view will be redrawn.

The documentation says the opposite. It's in the hand of the programmer whether the entire view will be redrawn or not. It's your responsibility to check the argument of drawRect: and decide what needs to be drawn. The authors seem to not have understood how setNeedsDisplayInRect: and drawRect: are related or they fail to mention it.

Again, UIKit is called the Objective-C descendant of Core Graphics. I imagine that this is confusing for readers who are not certain about the terminology themselves.

[UIView] is a pretty heavyweight object, so you need to be careful about how many of them you use.

The authors don't offer evidence for this assumption. In my experiments with hundreds of views and layers, the memory overhead of views is negligible and the animation performance of views and layers is identical. From the standpoint of the graphics system, views and layers are identical.

The authors call +[CATransaction disableActions] and +[CATransaction setDisableActions:] a property when, in fact, it is a set of class methods.

In the discussion of the anchorPoint property of CALayer, the book claims that the lower-right corner [of the layer] is (1.0, 1.0) (in terms of the anchorPoint) when, in fact, (1.0, 1.0) sets the anchor point in the upper-right corner. Core Animation's coordinate system has its origin in the lower left.

Sample code using ARC uses the __block specifier in order to avoid a retain cycles caused by a block. __block does no longer avoid the retaining of an object by the block under ARC, you have to use __weak instead. Acknowleged in the errata.

On NSXMLParser:

Because the parser uses delegation to return data, you need a subclass of NSXMLParser for every object you are handling.

On the contrary. Because it uses delegation, you don't have to subclass NSXMLParser, ever. The authors probably want to say that they recommend to create a new custom NSObject subclass to act as a delegate for each type of XML data you want to parse, which is good advice.

Under the headline Parsing XML on iOS, the book discusses both XML SAX and DOM parsers. As an example of the latter, the authors talk briefly about NSXMLDocument, despite the fact that it is only available on OS X.

Internally, every web server is coded using some object-oriented programming language.

This claim is obviously wrong and also beside the point. The book is not about web server API design.

Something from the WTF? department in a discussion about designing model objects that should interface with web services:

When the reconstructed objects on your iOS app match 100 percent with the objects on the server, the goal of data exchange is attained and your app will be error free.

I never knew it was so easy to make my app error free.

The authors claim NSURLConnection is part of the CFNetwork framework, which is not true. NSURLConnection is part of Foundation.

When adding a delegate attribute to a singleton class, the authors chose the unconventional way of defining class methods +delegate and +setDelegate: rather than instance methods (or a plain property declaration). For a singleton, the result is equivalent but the variant with class methods has the disadvantages of making the class harder to convert into a “pseudo singleton” (a class of which usually only one instance exists but that allows to create more instances if required) and of confusing the reader since all other methods on the class are declared as instance methods. I'd expect an explanation for such a choice, but none is given. Moreover, they then use an instance variable(!) as the backing store for the class's delegate.

In the book's downloadable sample code, this mess is not present; instead, the authors used a @property declaration, as it should be. The errata don't mention the change.

The sample code also does not specify the protocol the delegate should conform to in the method declaration (+ (id)delegate instead of + (id <RESTEngineDelegate>)delegate).

A custom setter method for a retain-property is wrong. In it, the authors first release the object that the backing ivar currently points to and then assign and retain the new object to the ivar. However, they don't check whether the old and new value for the property are one and the same. If they are, the object gets released before it gets retained again, which could lead to a premature deallocation.

In the same context, the reader learns that he has to include KVO notifications (willChangeValueForKey: and didChangeValueForKey:) in any custom accessor he writes, which is totally not true (the authors say it correctly on p. 295).

The Library/Caches directory is special because it isn't backed up but is preserved between application upgrades. This is where you should put most things you don't want copied to the desktop [i.e., the stuff you don't want to be visible to the user of the app].

This is very dangerous advice because the authors neglect to mention that the Caches directory is not guaranteed to remain intact. The OS is free to purge it at regular intervals or when storage space is limited. If an app puts data into the Caches directory that it cannot recreate, it will be irretrievably lost.

Apple modified the OS's cleaning behavior regarding the Caches directory in iOS 5. Given the book's timeframe, it was perhaps difficult to say anything concrete about the actual behavior of the OS, but the authors should definitely not have advised reader to put stuff into the Caches directory that is not meant for caching.

If you have information that you would rather the user not have access to, you can store it in the keychain or in Library/Caches because these are not backed up.

Again, this is a totally wrong way to use the Caches directory. If you don't want files to be readable in a device backup, use Apple's own Data Protection API, which seamlessly encrypts files on disk and has been available since iOS 4 (a topic the authors even discuss a few pages later).

In a code snippet, a view controller registers itself as a listener for a notification in the viewDidLoad method. The authors recommend placing the corresponding code to unregister from the notification in viewDidUnload, which is problematic since viewDidUnload is not guaranteed to be called.

The occasional plug for your own projects in your book is totally fine, especially if it is about stuff you're not making any money off. In fact, I'd expect it. I'd also expect that you disclose the fact that you are recommending your own stuff. In the chapter about in-app purchase, the authors recommend Mugunth Kumar's own MKStoreKit without mentioning this. The book devotes five pages to MKStoreKit alone and they sound like a commercial in places:

MKStoreKit … reduces [coding effort] to somewhere near zero. … With frameworks like MKStoreKit minimizing your coding efforts, why not give it a try?

Sample code that uses key-value coding to send regular messages to objects:

NSArray *array = [NSArray arrayWithObjects:@"foo", @"bar", @"baz", nil];
NSArray *capitalLength = [array valueForKeyPath:@"capitalizedString.length"];

While technically correct, this is horrible code! Please use a method like enumerateObjectsUsingBlock: to do something like this (or write your own -mapUsingBlock: method with it).

The authors implement a UIAlertView category that uses blocks instead of delegation. In the implementation, they use a static variable to store the completion block and therefore this category only works for one alert view at a time. I don't necessarily expect perfect sample code in a book. But an ackknowledgement of the limitations of your own code would be nice – especially when it helps learning. Since associative references were mentioned much earlier in the book, I'd rather have seen an implementation using that technique.

Any sqlite3 library … is almost always going to be slower than Core Data.

Again, a claim with no evidence. It goes on:

In addition, while sqlite3 is thread-safe, the binary bundled with iOS is not. So unless you ship a custom-built sqlite3 library (compiled with the thread-safe flag), it becomes your responsibility to ensure that data access to and from the sqlite3 database is thread-safe. Because Core Data has so much more to offer and is thread-safe, I suggest avoiding native SQLite as far as possible on iOS.

That sounds as if Core Data made multi-threaded access really easy. My experience is rather different.

In a discussion about -[CALayer renderInContext:]:

For web views larger than 1024×1024, you need to break them up into smaller pieces and render them individually.

I am not entirely certain, but I believe this advice is no longer correct. Views had a maximum size of 1024×1024 in the early days of iOS but this limit is long gone. If I remember correctly, I just recently used renderInContex: successfully on a web view that was larger than 1024 points in one dimension (though not in both).

Core Text was originally designed on the Mac, and it performs all calculations in Mac coordinates. The origin is in the lower-left corner

Really, Mac coordinates? As if Core Graphics used different coordinate systems on iOS and Mac.