The New Firebase iOS SDK(firebase.com)
firebase.com
The New Firebase iOS SDK
https://www.firebase.com/blog/2013-03-20-new-firebase-ios-sdk.html
12 comments
How does FireBase compare with Touch DB?
http://touchdb.org/
http://touchdb.org/
Firebase is a hosted service designed specifically for building real-time, collaborative applications. As a hosted, API-driven service it's easy to get started with and it handles scaling automatically. We're especially focused on keeping the API clean and easy to use. You won't need to worry about the mechanics of connecting to servers, long-polling, websockets, etc. Just drop in the library and go.
Real-time is at the core of Firebase -- it's designed to sync data fast enough that it's suitable for a whole new class of applications: multiplayer games, collaborative whiteboards, location services, and messaging apps.
Firebase is also designed for use across platforms and devices. Our JavaScript library supports the full featureset of our iOS and server libraries, so you can build apps that can communicate easily in real-time between the web and native mobile.
Real-time is at the core of Firebase -- it's designed to sync data fast enough that it's suitable for a whole new class of applications: multiplayer games, collaborative whiteboards, location services, and messaging apps.
Firebase is also designed for use across platforms and devices. Our JavaScript library supports the full featureset of our iOS and server libraries, so you can build apps that can communicate easily in real-time between the web and native mobile.
I was just going to post a shameless plug when I saw your comment. Here it is as a reply :)
If you are interested in transparent data sharing across devices, with realtime magic and fully offline editing capabilities, you might want to look at Couchbase for Mobile, a synchronizing NoSQL database for iOS (with Android coming soon). It is still pre-alpha but has an active community and is 100% open source (by the team behind TouchDB), so you can run it on your own servers.
https://groups.google.com/forum/#!forum/mobile-couchbase
/end shameless plug. Hope it is on topic for the folks reading this thread.
If you are interested in transparent data sharing across devices, with realtime magic and fully offline editing capabilities, you might want to look at Couchbase for Mobile, a synchronizing NoSQL database for iOS (with Android coming soon). It is still pre-alpha but has an active community and is 100% open source (by the team behind TouchDB), so you can run it on your own servers.
https://groups.google.com/forum/#!forum/mobile-couchbase
/end shameless plug. Hope it is on topic for the folks reading this thread.
BTW download section on github has been deprecated https://github.com/blog/1302-goodbye-uploads.
The touchdb.org is pointing to download section for "Download Framework" link
The touchdb.org is pointing to download section for "Download Framework" link
We've used the iOS SDK to build our Kindoma Storytime iOS app, coming to the app store next week (http://kindoma.com). It's a great platform to support collaboration in mobile. The API is straightforward and clean.
We're really excited to be able to bring the ease-of-development and real time updates of Firebase to a new platform. Please let us know what you think!
Looks great! Couple of questions:
1. How does Firebase handle data conflicts? (e.g. I delete a to-do item on my iPad while offline, then edit it on my iPhone while online. What happens when the iPad comes back online?)
2. When do you plan to leave beta/can I use this for production apps yet?
1. How does Firebase handle data conflicts? (e.g. I delete a to-do item on my iPad while offline, then edit it on my iPhone while online. What happens when the iPad comes back online?)
2. When do you plan to leave beta/can I use this for production apps yet?
1. This is a complex topic, but basic ideas is that we clearly define the behavior of the API in conflict situations. Most writes are "set" operations, which is simply last-write-wins. Well-structured apps can use this for the vast majority of features. For cases where you need multiple clients to modify the same data, we provide a Transaction operation, which ensures the write happens atomically. See:
https://www.firebase.com/docs/transactions.html
2. The service is ready for production apps now, and we have many already (Twitch, Klout, TED, BitTorrent). We have a rigorous test suite, comprehensive, redundant monitoring, data replication, and backups in place. At this point the Beta label is largely there because we haven't built the infrastructure to handle payments yet. You can expect that label to come off in the next few months.
https://www.firebase.com/docs/transactions.html
2. The service is ready for production apps now, and we have many already (Twitch, Klout, TED, BitTorrent). We have a rigorous test suite, comprehensive, redundant monitoring, data replication, and backups in place. At this point the Beta label is largely there because we haven't built the infrastructure to handle payments yet. You can expect that label to come off in the next few months.
Thanks. Your new simplified pricing structure looks wonderful, by the way. Looking forward to using it.
I used the super secret iOS SDK to build out a side project. I think the simple concurrency support is a BFD and a first for iOS.
This really inspires a lot of possibilities (and seems even easier than setting up with Parse). You could make some killer mobile massively multiplayer games like this -- the next Spaceteam or MMO Pong.
Can't wait to try it out! Which apps are you guys most hoping to see built?
Can't wait to try it out! Which apps are you guys most hoping to see built?
It's a general-purpose tool, so we expect to see all kinds of things built.
I'm especially excited about location services -- our SF Live Bus example in the blog post is one example, but in general there are tons of applications for notifying others of the locations of things in real-time (Uber, Postmates, Lyft, etc). I'm also very excited about multiplayer gaming on mobile, which is still in it's infancy. Some of the more interesting ones use phones in new ways. Gempad (in the post) uses your phone as essentially another input device. There are a bunch of other cool things you could do here as well.
I'm especially excited about location services -- our SF Live Bus example in the blog post is one example, but in general there are tons of applications for notifying others of the locations of things in real-time (Uber, Postmates, Lyft, etc). I'm also very excited about multiplayer gaming on mobile, which is still in it's infancy. Some of the more interesting ones use phones in new ways. Gempad (in the post) uses your phone as essentially another input device. There are a bunch of other cool things you could do here as well.
I used Firebase for a real-time collaborative screenwriting app (www.WriterDuet.com). I'd say that real-time collaboration was one of the simplest components, thanks to Firebase. I can't imagine having implemented this app without Firebase.
"Firebase eliminates “Pull to Refresh”" - That's the elevator pitch I'd use...
To be fair, I think their actual elevation pitch is "Scalable real-time backend - Build apps fast without managing servers" as per their homepage and the pull-to-refresh quote may be more specific to the iOS SDK
Congrats Firebase! The new iOS API is a great improvement from the beta days!
I imagine you folks don't use HTTP (hanging GETs) to synchronize data, right?
On iOS we don't use long-polling. On the web we use Websockets when possible, but fall back to long-polling if necessary. We only use HTTPS though for security reasons.
Awesome. WebSockets is the perfect technology for this scenario. Do you find WebSockets traverses NATs and firewalls as the RFC promises or it has limitations?
With SSL it's quite reliable (without it's pretty bad). Fortunately we always use SSL...
Sounds great!
How does it handle battery power consumption?
How does it handle battery power consumption?
We're always looking for ways to keep this optimized; since Firebase intelligently and efficiently only sends deltas after the initial load, it should be minor. Give it a try with the any of the demo apps on GitHub-- we'd love to hear what people are seeing with different devices and carriers.
The support has also been top-notch - we're very, very concerned about data privacy and security issues, reliability and response times, and every question, concern, or problem we've had has been handled super quick. It's not always what we want to hear (see http://stackoverflow.com/questions/15306191/empty-arrays-dro...), but they're definitely quick and clear.