iPhone and BatchBook, Sitting in a Tree…

• Posted June 14th, 2007
• By Adam Darowski (bio)
• Filed under: Technology

With the launch of the Apple iPhone merely a few days away, Apple’s legion of loyal developers entered the week still anxiously awaiting word on how they are supposed to develop applications for the thing. The answer, most assumed, would come this week at the Worldwide Developer’s Conference (WWDC07) this week. The timing was frighteningly close to the iPhone’s launch, but better late than never.

Well, they got their answer. And many didn’t like it. As Michael Calore of Wired put it:

Suddenly, a sound that’s rarely ever heard in a Jobs keynote welled up in the giant conference hall. Crickets.

Apple’s self-proclaimed “sweet” solution is an interesting one. They essentially told the developers to “make web apps.” The iPhone runs a full version of Apple’s Safari web browser. (X)HTML, CSS, JavaScript, and Ajax are all fully supported, so essentially if a web app uses web standards, it will work on the iPhone.

For us, this is good news. BatchBook is a web app that is built with web standards. After a bit more massaging, it will run just fine in Safari. The fact that a user can run the very same version of our application whether on their desktop, notebook, or even their phone is just killer.

Developing for “the mobile web” up to this point has been an extremely frustrating exercise. Do you serve the same information to a mobile user? Do you use CSS to hide parts of the page the user doesn’t need? How do you balanace stripping out portions of the page against keeping one code base so that users don’t have to pay to download data they won’t even be viewing? How do you test for the hundreds of different mobile browsers? Do you just serve unstyled content for mobile users? What about these .mobi addresses? Is that forcing us to have a separate site for mobile users?

Sigh.

Then Apple comes along and (as usual) does something ridiculously simple that nobody had ever thought of doing. Just put the same browser on the phone. Then, users can just look at the same thing they look at on their computers. No different code bases. No features stripped out. No developers assuming they know what part of a web page mobile users want to see.

Nick Peters wrote a post a while back about how the iPhone can be a killer format for Microformats (standardized class names inserted into HTML to allow various functions to be performed on the data). It looks like instead the iPhone will have auto-detection of phone numbers (so you can call with one touch) and addresses (so you can map the location via Google Maps). Still, Microformats would add so much more since you would have more complex detection features such as events. With one touch, add it to your calendar, sync it back with your desktop. Perfect. For BatchBook, an application that relies heavily on contact information, the possibilities make me drool.

I see one disappointment in the “no SDK” annoucement, though. We’re investigating ways to deploy BatchBook as a desktop application as well, so users don’t need to be connected to the web to access their data. Having a native application on the iPhone would allow data to sync between the desktop app, the iPhone app, and the web app. So, when you need a customer’s number, you could just open your phone and get it.

The iPhone auto-detects a wifi signal, so if you are on your wireless network you can access your data right away. However, if you are not, you’ll need to go ahead and use your cellular data plan to get that number. This is more inconvenient than insurmountable, but it’s nice to have that freedom of building contact lists when you are on the subway, unable to get a signal.

I must say, I can’t wait to play with BatchBook on an iPhone. I’m also looking forward to seeing if Apple changes the third party development plans. While the announcement isn’t a big one from BatchBook’s perspective, a lot of other developers are bummed because they can’t do what they want via the web app route.