As of April, 2012, the plan was to create a native application (with “Like” capability) to support smartphones, and to support PCs and feature phones through the website. The website would also provide an API so that the smartphone application could sync “like” information. This decision was changed in July, 2012. Native applications were ditched and the decision was to support all devices through the website.
Below, I describe our perspective as to why a native application was not (and still probably isn’t) suitable.
Smartphone native applications don’t require “native” functionality
Conference program applications are quite simple. They are basically a hierarchical listing of the presentations with a simple search function and a bookmark function. They hardly require any graphics capabilities. Since they are basically viewing-only, complicated editing and gestures are not necessary.
As such, there is very little need for these applications to be written as native applications. A basic web page can easily provide the same set of functions.
The only benefit of a smartphone native application is working offline
Although both Apple and Android smartphones use WebKit for their browsers and are HTML5 capable, storing data offline is still a sore point. The most widely supported API for offline storage is webStorage, but it is limited to 5MB on most browsers. This limits us to a few hundred presentations. By using webSQL and indexed DB, we should be able to use more than 50MB, which will enable us to include thousands of presentations. As such, storing the whole conference program on the browser for offline viewing is still confusing and difficult to program. Furthermore, developing offline web applications is an area technique which is not yet common, and mature libraries have yet to emerge.
Native applications are much easier. Native applications can directly use sqlite3 or keep all the data in the filesystem. The App Stores do not limit the size of applications, so the number of presentations that can be stored is virtually limitless.
The native app developer considered using UIWebView for the poster map
When we were discussing native application development with the software house in May 2012, they brought up the idea of using a UIWebView for displaying the poster map. This is basically the equivalent of providing a link. All the programing for the poster map will be done on the website, and the native application will simply act as a browser to view the page.
I was stunned. The poster map is the only feature where nice graphics would really make a difference, and the only place where I would consider native applications to have a fundamental advantage. Despite that, the developer was saying that they wanted to use web technologies to do that. They were throwing out the opportunity to show that native apps are awesome. It also meant that the only real advantage of a smartphone application, offline viewing, would not be possible for the poster map. This was unacceptable since the room where WiFi would be most fragile was expected to be the poster hall.
I pressed hard on the developer, basically interrogating them on what they really meant, whether they really thought that the UIWebView solution would be appropriate, and whether they would be able to make it work offline. This discussion was rather confusing, and I began to worry about whether they were really going to create something that met up to our expectations.
This is when I started work on a smartphone version of Ponzu to see if a smartphone version might be a better solution than a native application.
Conclusions from the smartphone version
- If the smartphone application used Ajax technologies to keep network access to a minimum, 3G networks were sufficient for smartphone clients. We tested in congested areas in Tokyo such as Shibuya station, and found no performance issues.
- iPads with only WiFi connections would still be an issue unless we supported offline viewing.
- If we can fully support offline viewing on the mobile website using HTML5 storage, then we can almost completely neutralize the advantages of a native application.
- Having two different parties developing for different devices is dangerous. Communication is difficult and the result is almost sure to be inconsistent features and user interfaces.
- An outside developer that isn’t committed to excellence will slow down innovation. An outside developer is OK only when innovation is stalled, and you can show them what they need to copy.