In the extract (no page numbers, so I entered "1"), under:
6.1 Introducing the UIManagedDocument, Manually Saving a UIManagedDocument,
I find:

[[self managedDocument] saveToURL:fileURL
forSaveOperation: UIDocumentSaveForCreating
completionHandler:^(BOOL success) {
//Handle failure
}];

UIDocumentSaveForCreating should be UIDocumentSaveForOverwriting, I'm pretty sure...
--Don Briggs

Sec 1.4 The interface property for "serves" should be a NSUInteger type instead of an NSString. This would be consistent with the CD model presented in Figure 2 in Sec 1.1.--Bruce Payan

NSManagedObjectContext ... Therefor, we hand off the reference to it to our AppDelegate so the the rest of the application can access it.

This is great but in the examples you don't do this.

//
// PPRAppDelegate.h
// PPRecipes
//
// Created by Marcus Zarra on 4/3/12.
// Copyright (c) 2012 The Pragmatic Programmer. All rights reserved.
//

@interface PPRAppDelegate : UIResponder <UIApplicationDelegate>

@property (strong, nonatomic) UIWindow *window;

- (void)saveContext;

@end

--- and part of the .m file

#import "PPRAppDelegate.h"

#import "PPRMasterViewController.h"
#import "PPRImportOperation.h"

@interface PPRAppDelegate()

@property (nonatomic, strong) NSManagedObjectContext *managedObjectContext;

@property (nonatomic, strong) NSURL *fileToOpenURL;

- (void)initializeCoreDataStack;
- (void)contextInitialized;

- (void)consumeIncomingFileURL:(NSURL*)url;

@end

@implementation PPRAppDelegate

@synthesize window;
@synthesize managedObjectContext;
@synthesize fileToOpenURL;

I'm use MVCS and the store needs access to the moc I recommend something like this: in the .h

#define ApplicationDelegate ((AppDelegate *)[UIApplication sharedApplication].delegate)

@interface AppDelegate : UIResponder <UIApplicationDelegate>

@property (strong, nonatomic) UIWindow *window;

// Notice how this is called mainManagedObjectContext all the local instances are called
// ManagedObjectContext this is because core data is not thread safe and each access into it needs to be on the thread that calls it.
@property (strong, nonatomic) NSManagedObjectContext *mainManagedObjectContext;

//This is new it is thread safe
- (void)saveContext;

and in .m change to:

@interface AppDelegate()

//Place the private methods in this category
- (void)initializeCoreDataStack;
- (void)contextInitialized;

@end

#pragma mark - Core Data stack

- (void)initializeCoreDataStack
{
NSURL *modelURL = [[NSBundle mainBundle] URLForResource:@"GAIGAgent"
withExtension:@"momd"];
ZAssert(modelURL, @"Failed to find model URL");

NSManagedObjectModel *mom = nil;
mom = [[NSManagedObjectModel alloc] initWithContentsOfURL:modelURL];
ZAssert(mom, @"Failed to initialize model");

NSPersistentStoreCoordinator *psc = nil;
psc = [[NSPersistentStoreCoordinator alloc] initWithManagedObjectModel:mom];
ZAssert(psc, @"Failed to initialize persistent store coordinator");

NSManagedObjectContext *moc = nil;
NSManagedObjectContextConcurrencyType ccType = NSMainQueueConcurrencyType;
moc = [[NSManagedObjectContext alloc] initWithConcurrencyType:ccType];
[moc setPersistentStoreCoordinator:psc];
//[self setManagedObjectContext:moc];
self.mainManagedObjectContext = moc;

...

so basically make the mainManagedObjectContext accessible so the rest of the app can use it.

The way you have it does work when you set the mod up in the didFinishLaunchingWithOptions but this is not usable when using the MVCS pattern were all the data goes thru the store and thus the store needs access to the "main" moc

--Dave Koz

I've been unable to run the sample code because of the lack of initialization of the data base. I could not find a section of the book or notes in the code explaining what had to be done to set things up. I did see some shell scripts, but no context in how to run them. A Readme file in the sample code is essential.
pdj--Paul Jensen

Under the section on StoreFetchedRequests, the code snippet includes an example of using NSSortDescriptors, which are not covered until the next section. This isn't a huge problem, but it's a little confusing for a new user who's following the code particularly - especially since the accompanying text basically ignores the presence of the sort descriptors (rather than using them as a segue into the following section, which would probably be the most natural way of using the code snippet).

As a newcomer to Core Data myself, I found this section confusing for several minutes as I was trying to make a connection between the two separate concepts I saw in the code - when in fact the "second" topic was waiting for me on the following page.

IMO, these last two lines should either be omitted or (ideally) used as a natural segue into the following section.

---

RecipesV1/PPRecipes/PPRSelectIngredientTypeViewController.m
NSManagedObjectContext *moc = [self managedObjectContext]; NSPersistentStoreCoordinator *psc = [moc persistentStoreCoordinator]; NSManagedObjectModel *model = [psc managedObjectModel];
NSFetchRequest *request = [model fetchRequestTemplateForName:@"allIngredients"];

/*BEGIN*/

NSMutableArray *sortArray = [NSMutableArray array];
[sortArray addObject:[[NSSortDescriptor alloc] initWithKey:@"name"
ascending:YES]];
[request setSortDescriptors:sortArray];

/*END*/--Zachary Klein

In the section on wiring up the UITableView ("Wiring the NSFetchedResultsController to a UITableView"), the data source protocol is referred to as UITableViewDatasource, when the protocol is actually called UITableViewDataSource.--J. MacMillan

In Chapter 1. Under the Hood of Core Data, subsection Property Accessors there is a wrong reference in the following text:

---

Relationships can use properties, just like the attributes discussed earlier.
In the code in Mutable Access of To-Many Relationships, on page 13, if we want to add a property to retrieve the relationship, we declare the following property:

@property (strong) NSSet *recipeIngredients;

---

Instead of "Mutable Access of To-Many Relationships, on page 13" the reference should be to "Accessing a To-Many Relationship, on page 13". The property recipeIngredients is NOT mutable.--Marian Cerny

These two lines are not correct:

NSArray *newArray = [NSArray arrayWithObject:newIndexPath];
NSArray *oldArray = [NSArray arrayWithObject:indexPath];

arrayWithObject raises an error if its argument is nil, which both of these can be depending upon the mutation type.
--Pete Hopkins

[REF: Pete Hopkins B4 Note]

Within the first printing the tech. error noted by Pete Hopkins in B4 still remains.

NSArray *newArray = [NSArray arrayWithObject:newIndexPath];
NSArray *oldArray = [NSArray arrayWithObject:indexPath];

arrayWithObject raises an error if its argument is nil, which both of these can be depending upon the mutation type.

-Nathan Berendt--Nathan Berendt

finalPredicate never declared either in the class or within the local method scope. You might want to check the code being posted on media.pragprog.com too.--Anson Chen

In the code snippet you define NSPredicate *final;
but then go on and use an undefined predicate called finalPredicate.

- (void)addEntityToWatch:(NSEntityDescription*)description withPredicate:(NSPredicate*)predicate;
{
NSPredicate *entityPredicate = nil;
NSPredicate *final = nil;
NSArray *array = nil;
entityPredicate = [NSPredicate predicateWithFormat:@"entity.name == %@",
[description name]];
array = [NSArray arrayWithObjects:entityPredicate, predicate, nil];
final = [NSCompoundPredicate andPredicateWithSubpredicates:array];
if (![self masterPredicate]) {
[self setMasterPredicate:finalPredicate]; return;
}
array = [NSArray arrayWithObjects:[self masterPredicate], final, nil];
finalPredicate = [NSCompoundPredicate orPredicateWithSubpredicates:array];
[self setMasterPredicate:finalPredicate];
}--Duncan Tate

(Or a suggestion)
1) The results mDictionary is local to -contextUpdated and never assigned/passed so how does it "...pass the newly created NSDictionary to our delegate."? (p. 36)
2) Also the book code version has action in the class extension (changed in the one on GitHub) and it's never set in the existing code.

Were these meant to just be starter code that has to be amended to be functional? The book presentation suggests otherwise but certainly could have misinterpreted that.--Randy Scovil

The creation of the UIAlertView is done within the dispatch_async block on the global queue, which causes an error. It should be done on a block that's run on the main UI queue.--Pete Hopkins

Figure 13 is named "Turn on the external record flag," which suggests the Spotlight flag. Combined with the previously-noted fact that the figure shows the "Store in External Record File" checkbox on, but "Allows External Storage" off, this is very confusing!--Randy Saldinger

5th Paragraph. Text mentions to "turn on external binary storage," however the corresponding image referenced (figure 13, pg. 64) shows the "external record flag" checkbox selected. Since that is a setting for Spotlight, it would make more sense to show the "Allows External Storage" checkbox selected in this image.

In the book on page 67/336 in the code for ZSContextWatcher.m, the sample shows,

NSPredicate *final = nil;

Where in the Github copy of ZSContextWatcher.m on line 54 it is,

NSPredicate *finalPredicate = ...

Further, the subsequent sample code in the book assumes the the object is "finalPredicate", not "final",

if (![self masterPredicate]) {​​
 
​​ [self setMasterPredicate:finalPredicate];

--James Hillhouse

Since this is all about getting the export off the main thread, adding the export operation to the mainQueue makes no sense. (The import code has the same problem.)--Randy Saldinger

In the first code example on the page, this line is incorrect:
[dict addEntriesFromDictionary:[self moToDictionary:childMO]];

It should read:
[dict setValue:[self moToDictionary:childMO] forKey:key];

Otherwise, the resulting NSDictionary will be a combination of keys and values from multiple entities, which is incorrect.--Kyle Oba

Book describes

5.5 Parent-Child NSManagedObjectContext Instances
With the release of iOS 6.0 and Mac OS X 10.8 Mountain Lion, a number of new features have been added to Core Data.

I believe these features were introduced with iOS 5.0 / Mac OS X 10.7. Certainly is seems -performBlock: and -performBlockAndWait: are available in iOS 5.0. I can't provide a link to docs as your form prevents it.--Ian Kershaw

[self setValue:childSet forKey:key];

This line of code is VERY likely not what's wanted here (it's broken). Calling setValue on "self" refers to the PPRImportOperation.

My change to the code was :

[mo setValue:childSet forKey:key];

This calls the setValue method on the Managed object.

--Charles Hart

Last line in the page begins with "The seques of this UIViewController."

It should be "The segues of this UIViewController." (i.e. segues instead of seques).--Eric Trepanier

Reading ePub version, so page number won't work. Chapter 3.5, last paragraph: “Is it of vital importance…"

I think it should be: "It is of vital importance…"--Scott McAlister

I'm using Xcode 4.6.2. I'm having problems with your nifty Macros. Note: I have actually manually typed in the Macros (you provide in Appendix 2) into the <ProjectName>-Prefix.pch file after the Cut & Paste method raised some Compile Type Errors. But I'm receiving the same Compile Time Errors regardless of how I try to incorporate them into the .pch file. The errors are associated with (and localized within) the ALog() and ZAssert() macros. If I don't try to compile the manually entered content I don't receive any hints of any problem. Once I BUILD the source the same 5 Errors appear that I had before. Everything "looks" good, but the compiler is telling me otherwise. I'm kind of stumped. I can email the offending 5 lines of source code if that helps. --Mark Mendenhall