synchronization

The more consumers use the mobile apps of leading tech companies like Facebook and Google, the more they expect the same realtime synchronization and notification functionality out of every service they use. It’s no longer satisfying to “pull to refresh,” when we’ve seen the light of instant, and passive synchronization. The problem is, this is an incredibly challenging and resource intensive problem to solve. So much so, that it’s out of the realm of possibilities for most developers.

Today, Firebase hopes to change this with the launch of a mobile SDK bringing its scalable realtime backend platform to iOS. In other words, the company can offload the major engineering challenges to allow resource-constrained developers to build rich Web-like experiences for mobile, keeping users engaged and delivering updates as they occur. Firebase can also simplify the development process and in many cases can be used as a complete backend, meaning developers can skip the hassle and expense of running their own servers.

Based on the traction of its Javascript-based Web product, including with companies like Atlassian, BitTorrent, Pivotal Labs, and eToro, it’s fair to assume the new mobile product will be popular in the gaming, social, and communications categories. The iOS SDK is already in use by collaborative reading app Kindoma, alternative PC input platform GemPad, and silent disco synchronization platform DiscoSync.

In an effort to demonstrate its technology, Firebase did something so obvious, I’m surprised I haven’t seen it used before: It created a standalone sample app and open sourced the code. SF Live Bus is a Firebase-powered iOS app that displays a realtime view of the location of every bus in San Francisco. The team created the entire app with 30 lines of unique code, 12 lines of Firebase code, plus standard iOS boilerplate. The team also created a simple sample chat example.

The hope is that when other developers see the power of the app relative to the simplicity of the code, they’ll be dying to use the Firebase iOS SDK. And if someone were to duplicate the app for New York or London, co-founder James Tamplin would be almost as thrilled.

The company is still finalizing its pricing structure, although it will likely revolve around a fee per gigabyte of storage and per gigabyte of bandwidth – similar to that of Amazon Web Services (AWS).

“Pricing the service has been the second hardest thing behind actually building it,” Tamplin says.

The iOS product, which joins the company’s existing Javascript-based Web offering, is a precursor to more things to come, according to the founder. “Our goal is to provide access from anywhere, on any platform, in any language,” he says. Expect to see support for new platforms and new ways to access data soon.

“There is a macro trend taking place where people are utilizing multiple devices and they expect the same experience across them,” Tamplin says. “There’s nothing more frustrating than not receiving an important notification, or more jarring than having message read-unread status not sync across devices.”

Firebase launched in April 2012 after completing Y Combinator in 2011. The company has since raised $1.4 million from Greylock, NEA, Flybridge, and several angel investors, including Cloudera CTO Amr Awadallah. Interestingly, much of the company’s development has been funded by the cashflow of its predecessor, envolve.com, which powers “Facebooks-style chat” for over 100,000 websites and runs profitably on auto-pilot.

Current Firebase competitors include ShareJS, which requires a server, and the developer version of iCloud which leaves a lot to be desired. Early feedback from beta customers and those demoing the product at hackathons has Tamplin and his team confident that they’ve built the most powerful realtime synchronization API available today.

Until it’s in the hands of thousands of critical developers quick to vote with their wallets, talk like this can only get the company so far. But an early preview of the SF Live Bus app and other early adopters suggests that the company’s enthusiasm may be justified. If so, it’s not just developers, but consumers, that should be thanking them.