Monthly Archives: July 2012

Native Apps Beat Mobile Web

Mobile Web was a good thing on feature phones, but nowadays and in the near future Native Apps rock! Interested why? Stay with me.

No More the Phone

iPhone and Android are no more the phones, they are new personal computers, just smaller than PC 20 years ago. The irony is the recent issue with iPhone 4 antenna. When you close the metal circuit with your finger during the phone talk, then antenna could stop working properly, as result you are not able to to phone conversation – the phone does not work as the phone. It is ridiculous, but it clearly represents the trend: those devices are much more than phones, the “phone function” is not even #1 (as with iPhone 4 antenna). But besides “phone” those devices can many other things, such as taking pictures, play music, play videos, and run applications. Those apps seem more important than phone talks. It was an introduction, hope you got the point that devices are evolving towards non-phone ones.

Can Apps be SaaS?

Ordinary apps can be SaaS, best apps can’t be SaaS. Big difference between best apps and the rest is the efficient usage of the device hardware, its sensors. It is possible (historically) from OS API. There were always “silver bullets” that allowed “write once, run on many”, but all of them confirmed to be limited and restricted in comparison to the native apps. There is only one way to use new iPhone most efficiently, it’s via iOS programming, with direct access to entire API and underlying sensors. It is same as it was on desktop PC programming. You could use some library (e.g. from Adobe or Trolltech) and succeed with certain things, but get restricted or non-flexible with others. Situation with multiple platforms led to even more limitations. Ok, but what is that special thing that we want to have access to and control it with great flexibility? Sensors! New sensors. It’s obvious now that HTML-powered SaaS can’t leverage the power of new sensors, because it doesn’t know about them! Hybrids go with smaller handicap than pure HTML, but they are behind the schedule. Best apps are native apps and they make the pace.

New Sensors

You probably heard about Apple’s patent to infrared camera that could be used for DRM or substitute QR codes. Figure below is put to remind about it.

Infrared sensor is a beginning. Motorola Xoom has introduced barometer. Now it is available on Galaxy Nexus too. Barometer is relatively simple sensor, hence its support by HTML and different mobile middleware is not a problem, it’s just come with some delay in comparison to OS API. Another potential sensor could be humidity. Altimeter could come to iPhone soon too. All them will be supported by HTML with some delay to native support… But more advanced things like motion sensors and 3D GUI are obviously too tricky for HTML (see figure below). It is kind of Kinect embedded into iPhone. There are Apple patents forĀ  hover sensing, more details on 3D hovering here.

Another sample is about old good WiFi, measurement of WiFi signal strength is a problem for non-native apps. If smbd wonder why we may need such WiFi strenght measurement, then the answer is – for in-door positioning, where GPS doesn’t work. Going into advanced requires working directly at the OS level. Native apps! But now I’d like to switch to Healthcare and sensors that could be useful there. You will get even more arguments for native apps.

Health Sensors

Thermometer could be embedded into the phone, We saw simple electronic thermometer is the stores. Infrared touchless thermometer might be bigger, though as a sensor both are simple. What about UV exposure sensor? You expose your phone to the sun and it (phone app) tells you about UV level and suggests based on the result. UV sensor could be more sophisticated than thermometer, probably some calibrations will be required. This is argument that its use could be efficient from OS level. Next similar to UV could be radiation sensor. The questions is about miniaturisation, when it fits into the phone body. Non-trivial programming expected, hence no chance for HTML or hybrid at the beginning.

Sounds like Sci-Fi? Well, switching to human. Heart monitoring is pretty straightforward, that sensor could be quickly available for HTML and JavaScript. What about breath analyzer? There could be a sensor for alcohol in the phone. Similar sensor could be a smoke analyzer at home, embedded into the phone. What about perspiration sensor and analyzer? It is easy and safe to use outside of hospital. Perspiration sensor sounds advanced. Glucose measurement sensor could become small enough to be fit into the phone. It is possible to implement mood sensor, that measure excitement or frustration level, and it could fit into device you continue to call “the phone”.


Hardware is booming right now. It is obvious. Plenty of manufacturing is now takes place in the states, not in Asia. History taught us during PC era: there are no silver bullets and you need to be close to the hardware as possible if you need all its features and use them in flexible and reliable way. Are hybrids the solution, to wrap all new sensors and allow SaaS within? I doubt, because those man-in-the-middle always introduce limitations in comparison to what you have by using OS’es API directly. What to build best apps? Build native apps and you will not regret. For next several years guaranteed. Mobile web will catch the pace, when all sensors are designed, adopted, HTML standardised and so on. It will take several years.

Tagged , , , , , , ,