The Core Data/ Firebase hybrid is working well for us, though there were some snags along the way. In particular, Core Data and the FRC behaved much nicer when we performed an all-at-once initial load from Firebase when the app starts, rather than just subscribing to the “child added” events (see http://stackoverflow.com/questions/27978078/how-to-separate-initial-data-load-from-incremental-children-with-firebase). I could see going away from it, but our “endless” scrolling TableView wired to the FRC works sooo nice.
A few things I like about Firebase:
- No having to write any web services
- Built-in offline support
- Built-in authentication, including a library that handles basically all of the client-side wiring
I find all three of those things annoying to write, especially on a free time project. In that sense, I’m inclined to go with Firebase even on projects where it may not be the ideal datastore. If you don’t need all of those three things, and don’t find the things from that list that you do need to be annoying to write, then Firebase may not be much of a value-add. Additionally, there is some extra work that goes into structuring a Firebase database correctly (see https://firebase.googleblog.com/2013/04/denormalizing-your-data-is-normal.html). There’s certain queries that are a breeze in SQL that aren’t in Firebase (like multiple filter criteria).
Doesn’t sound like the case for you, but another ideal use case for Firebase is chat apps or other things with message streaming. Once your app subscribes to a Firebase query, it keeps updating, so it’s perfect for easily processing incoming messages.