Q:

What is the purpose of returnsObjectsAsFaults

I do not really understand the usage of "returnsObjectsAsFaults".
The documentation says:

A Boolean value that indicates whether the objects resulting from a fetch using the receiver are faults.
YES if the objects resulting from a fetch using the receiver are faults, otherwise NO. The default value is YES. This setting is not used if the result type (see resultType) is NSManagedObjectIDResultType, as object IDs do not have property values. You can set returnsObjectsAsFaults to NO to gain a performance benefit if you know you will need to access the property values from the returned objects.
By default, when you execute a fetch returnsObjectsAsFaults is YES; Core Data fetches the object data for the matching records, fills the row cache with the information, and returns managed object as faults. These faults are managed objects, but all of their property data resides in the row cache until the fault is fired. When the fault is fired, Core Data retrieves the data from the row cache. Although the overhead for this operation is small, for large datasets it may become non-trivial. If you need to access the property values from the returned objects (for example, if you iterate over all the objects to calculate the average value of a particular attribute), then it is more efficient to set returnsObjectsAsFaults to NO to avoid the additional overhead.

What does it mean that by returning managed object as faults?
So if it is set to true, the objects will be stored in a cache and be inaccessible?
On the other hand false will make it accessable?
Please help me clarity this as I am very confused by the documentation's explanation.
let request = NSFetchRequest(entityName: "BlogItems")
request.returnsObjectsAsFaults = false

A:

I also stumbled across this problem today.
We have some iPad and iPhone applications, but today, rebuilding them was returning the correct number of records, but each of them was empty.
The cause, of cause, was that ridiculous flag:
request.returnsObjectsAsFaults = false

What annoys me about this is:

this field never used to "get in the way".  Has the default changed since previous versions of iOS or something ?
the name of this property is ridiculous.  You would expect to be able to set the "includesPropertyValues" to TRUE and this would be enough to, errrm, include the property values.
even Apple's own CoreData sample code doesn't mention this (essential) setting, so even beginners are going to wonder why their code, based on Apple's examples, isn't working.

Apple: Fetching objects from CoreData

Apple's documentation claims that "Fault handling is transparent—you do not have to execute a fetch to realize a fault. If at some stage a persistent property of a fault object is accessed, then Core Data automatically retrieves the data for the object and initializes the object."   What a load of rubbish.  This simply isn't true.

Apple: Faulting and Uniquing
I seriously loathe Xcode, and each release seems to give you even more reasons to hate it.  At the time of writing, the App Store average rating of Xcode is just 2-stars, and Apple seems to ignore user's complaints of how bad it is.  
Anyway, rant over.  Here's a link to a StackOverflow article which describes the differences between returnsObjectsAsFaults and includesPropertyValues and a second link giving you details of how to survive iOS programming.
Btw, does anyone know if Apple's recruiting at the moment ?  This article would look good on my resume...

A:

It looks like you answered your own question. More from documentation:

A managed object fault is an instance of the appropriate class, but
  its persistent variables are not yet initialized

Read Faulting and Uniquing section of Core Data Programming Guide.

