Is the Future of Mobile the Web?

At the end of a recent post on the Future of Mobile event, I asked the question whether I am behind the times and the future of mobile really is the web browser. Should I be thinking about developing for the mobile web rather than native/Java applications?

The basic question is how will people gain access to additional functionality beyond that originally provided with the phone? Will it be an application download or accessed within a web browser?

Ever since Ajit Jaokar’s article on "Mobile web 2.0: AJAX for mobile devices – why mobile AJAX will replace both J2ME and XHTML as the preferred platform for mobile applications development" there has been a growing number of people who proclaim that the future of mobile is the web.

Some people see the success of the web-only iPhone as an indicator. Others say the fact that people want to hack in and write their own applications is a contra-indicator. Maybe Apple’s giving in and planning to provide an SDK is a measure of what developers really need.

I have also read comments on some articles on Android that people think Android’s emphasis on applications as opposed to the web is wrong and backward thinking. There’s also growing hype over Mobile Web 2.0 and even some actual work into looking into the challenges of using Javascript on mobile devices.

Why do people think applications will be within the browser? I think this is because…

  • Native/Java application development is currently difficult compared to Javascript
  • Downloads involve discovery, device type detection and installation that are barriers to use
  • Application development is fragmented due differing device capabilities
  • We are doing more and more in the PC browser and people think this will happen on the phone

[An observation – Nokia Widgets need to be downloaded and in some ways (discovery, download, install) are no better than applications – although they are simpler to write.]

So what do applications typically need to do? Here are some requirements from applications I have written for companies over the last few years. These aren’t trivial weather of clock widgets. These are real requirements from companies putting real money behind mobile applications. These are also requirements that come up again and again.

  • Use the file system
  • Use the camera to take photos and video
  • Use Bluetooth
  • Start at boot
  • Answer incoming call
  • Set future alerts
  • Access the phone contacts and calendar
  • Dial a number
  • Send an SMS or MMS
  • Act on an incoming SMS
  • Detect end of outgoing call
  • Write graphics primitives to the screen (line, square, circle etc)
  • Vibrate the phone
  • Long running background process
  • Manipulate video in real-time
  • Use/manipulate phone Internet access points

I could list many more. However, the idea is that the variety of what developers need to do means that you either need a very large common API accessible within all browsers or a way of accessing any API on the phone (think COM style publishing/consuming interface if you like).

Take the concept of a very large common API accessible within all browsers. This is very similar to the situation we have with Java ME. The problem is that each phone implements the API differently, behaves differently for a given API, and will have bugs, missing and extra features. While I believe we can improve on the situation with Java, I think we will always have implementation variation because these things are complex and we are only human. This leads to development fragmentation and would lead to different sections of Javascript code depending on the device type.

Take the concept of a COM style interface. Again, each phone would have different interfaces and behaviour and require different sections of Javascript code depending on the device type.

Hence, I think that once we try to write real applications within the browser we will be exposed to similar issues that make native and Java ME development difficult. We will need to vary use of device functionality based on the device type, Javascript will be necessarily more complex and application development will still be fragmented. Despite standards, variations in phone software implementation will always percolate up to whatever development platform is being used.

All this has ignored the fact that interpreted Javascript will never be able to be used for high performance/real time processing. I have also not covered the security implications of the browser being able to access phone features.

I believe the future of mobile isn’t the web. Downloadable applications and the web will coexist and be used for different types of application according to their strengths and weaknesses.