Tag Archives: Native Application

What killed the native smartphone app for MBSJ2012?

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

  1. 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.
  2. iPads with only WiFi connections would still be an issue unless we supported offline viewing.

Current thoughts

  1. 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.
  2. 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.
  3. 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.

Native conference applications are little more than eBooks

Since there are so many smartphone application developers now, the prices for a native conference application has gone down dramatically. You can get both an iOS and an Android version for about 1 million yen. However, the features that these applications provide are little more than eBooks. Moreover, preparing the data to be imported into these applications is left to the conference staff; the application developer will not do this.

My prediction is that the native conference applications will be replaced by eBooks in the near future. What is holding us back is the lack of pre-installed ePub readers, especially on the Android platform.

Below I will discuss this in more detail.

Search on native conference applications is very simple and comparable to ePub readers

The search capability on native conference applications is very limited. In fact, native applications (including those for PCs) often have very crude searching. Instead of indexing the text, these applications commonly do a simple scan through all the documents for each query. This makes searching slow and they usually lack effective scoring algorithms. As a result, searching inside native conference applications is not significantly better than similar capabilities on ePub readers. This partially due to the lack of good search libraries, but the largest limitation is the CPU power, memory and battery life on mobile devices. Without abundant resources, indexing simply is not realistic.

In contrast, searching on the server is very sophisticated, and there are amazingly powerful solutions that are available free of charge. You can use complex scoring algorithms so the most *relevant* results are shown on top. You can show *facets*. Speed is very fast because servers typically have enough RAM to store the whole index in memory.

ePub has powerful table-of-content features and links

ePub provides a flexible and easily accessible table-of-contents feature and also the capability to connect pages through links. Therefore dividing thousands of presentations into sessions, and grouping those sessions together by date and time is relatively straightforward. Furthermore, clicking on links provides makes it easy to navigate through an ePub.

Although the UI may be less appealing, it is possible to provide the same navigation as a native conference application.

Limitations of ePub

For MBSJ2012, we tested and created a prototype ePub and viewed it in iBooks on the iPad and iPhone. We observed the following limitations;

  1. Search was extremely slow (probably not an issue unless huge conference)
  2. Table-of-contents were generally OK

Other limitations were that there is no ePub reader installed by default on Android devices, and that the same can be said for PCs.


Although we think that ePubs and eBooks are very suited for relatively small conferences, the problem is support on Android. If Google starts bundling ePub readers on Android, then ePub will be a very attractive solution. If there is a good free application for Android, that might be sufficient.