I've used CoreData with FF, but took a different approach. It is a little bit more "client" side setup, but IMHO keeps your model clean.
* As an aside, using the approach that Gary outlined (LocalStorage) keeps your data layer homogenous and don't inject another, though useful, technology like CoreData into the mix.
The most common approach for using CoreData is to have a 1:1 representation of your server model in your application. That _usually_ works well for most setups, but is almost impossible to do with FF. The reason being is due how FF handles "related data". BackReferences, Grabbags, References, etc. Trying to replicate that in CoreData is a fools errand, but the good news is you don't have to IF you use CoreData to only persist your necessary objects.
In one of the apps that I'm working on I have the following Object:
CREATE OBJECTTYPE Event (name STRING, attendCode STRING, location REFERENCE /Venues, attendees REFERENCE /FFUserGroup, startTime DATE, endTime DATE, playlist GRABBAG /Tracks, currentlyPlaying REFERENCE /Tracks, isPrivate BOOLEAN, photos GRABBAG /UserPhotos, ownerProfile REFERENCE /UserProfiles)
As you can see I've got references, grabbags and standard objecttypes. Trying to replicate this object graph with CoreData would be nightmare, especially given that I just wanted to persist the latest events. As a general rule my objects conform to NSSecureCoding so that I can persist them to anything I want. My solution that I came up with is to have an additional model for those objects that I wanted to persist to CoreData.
For example:
Event.h/m
- name
- attendCode
- startTime
- endTime
- ....
Venues.h/m
.
.
.
CDEvent.h/m
- created
- event
- ffguid
- isPublic
- updated
- isCurrent
All of the properties for the CDEvent object are the properties that I would want to display or query on thus why they are explicitly defined. The event property is the serialized instance itself. CoreData will automagically apply an NSValueTransform on the object (You do have to set the attribute type to Transformable, but you don't have to explicitly set the type of transform).
I see a few benefits of taking this approach.
1) My underlying data model remains "clean". I'm still dealing with straight NSObject's and don't have to jump through any hoops or hurdles going back/forth with FF.
2) If I decide that I don't want to deal with CoreData anymore I don't have to rewrite my model and I can move to another persistance mechanism (sqlite, plist, seralized data on disk, memory, etc.)
3) Allows me to mix and match persistance mechanisms. CoreData isn't a silver bullet for offline and sometimes it feels like using an atom bomb to light a grill.