Smartphones are more powerful, but does it really matter?

081414_mp

A few days ago I wrote about mobile technology, and specifically some points around mobile web and native applications. Since people often send me questions on what I wrote, I realized that there was a fast follow necessary to further describe my vision for what we’re going to see over the next few years. Also, I need to clarify that I’m specifically not talking about so-called “hybrid” apps.

 

The hybrid app is a mix of native code and HTML5/mobile web pages. This approach has been used in several places to mixed success. The mixed success isn’t a flaw in the approach, but rather a failure to understand the basic constraints of the technologies being applied. Facebook learned (to their extremely public failure) that wrapped HTML5 by itself could never completely replicate a native app experience, and that they devices they were running on treated the mobile browser environment vastly different from the native app environment.

 

To use an analogy, a steel hammer and a rubber mallet are both very valuable tools… but you would only want to pound in a nail with one of them. Granted, if you work at it you could use the mallet to pound in a nail, but it certainly wouldn’t be pleasant or efficient.

 

In the software space it’s interesting that despite architects and deep technical thinkers being very precise about technology decisions and evaluations… they often make the mistake of ignoring the differences between a hammer and a mallet. Part of it is basic wish fulfillment; they wish the world was simpler to the point that anything hammer-shaped would have the same end result. Part of it is their peers and management, who pales at a complicated answer and really just wants a straightforward one. In fairness, the designer of a house really doesn’t want or need to understand the differences in the tools… they just want to trust that the people using them know what the hell they are doing.

 

Earlier I mentioned a native app wrapper. For those of you who are new to this term I can explain quickly; it’s a basic container written in a native device language which then launches a WebView that displays HTML5 code. The app you are looking it is actually a Mobile Web page, “wrapped” or contained within a basic native shell. This packaging is not a new concept by any stretch of the imagination, and is often recommended when you’re trying to achieve cheap portability, since it’s much more cost effective to write once in HTML5 and then build a number of thin wrappers natively. The downside is that if you’re trying to pretend to be a native application without spending the money and effort people will notice. Worse, Apple and Google are largely motivated to help your customers notice by evolving the capabilities of their native app platform while largely keeping the browser format locked in place.

 

Hybrid solutions can still work of course; you just need to be thoughtful of how you’re using them. Building a completely HTML5 solution within a basic app container has generally been proven to be a failure… if you’re trying to replicate a full native app. If you’re making a game where HTML5 is a perfectly acceptable end-user experience, then the hybrid wrapper approach works just fine. Basic information apps can take this approach as well, but high-touch experience products fall apart quickly. Then there’s also the problem of what happens if your solution is popular.

 

One massive mistake being made in mobile technology right now is a huge misunderstanding of the power of the end-device. Perhaps it’s the marketing of the Smartphone, or the fact that the device makers choose to differentiate themselves based on hardware specs. The smartphone you’re carrying around in your pocket these days is arguably faster and more powerful than the PC you owned five years ago. This is because the hardware has continued to innovate, shrink and become cheaper to produce. That’s a good thing because the smartphone has largely replaced the traditional camera and the processing power and demands for the camera is quickly approaching SLR territory. It’s also a good thing because the smartphone is also replacing the handheld game market and the processing power required to provide on-par gaming experiences is significant.

 

But just because the device has this power doesn’t mean it should be immediately tapped and used to its full extent. There are two extremely important factors that many architects are ignoring in their rush to push the heavy lifting to the phone:

 

1. The network is still the network; largely uncontrollable and unpredictable. If the day ever comes when the entire planet is blanketed by free, powerful WiFi (and that day is not even remotely close) there are still problems with network congestion and capacity and outage spots. You can see this in action by simply going to a stadium for a packed concert and then trying to use your phone. Even if it claims you have full bars and a strong signal, the capacity is so constrained that your experience is going to be poor. So pushing a ton of data to the device and letting it do all the work is going to fall apart pretty quickly.

 

2. The other problem is the battery. Even though smartphones have lots of processing power and capability, those capabilities are rarely in use. If you look at the diagnostics of your phone you will discover that maybe 5% of the power is being used much of the time. When you fire up the camera that number raises, and if you’re playing a game then it spikes even further. Play Minecraft and you will notice your phone heating up… that’s a physical reminder that you’re now using much more of it’s internal power and you pay the price in your battery life. So there again, if you’re going to cram processing logic to the phone you’re going to accelerate the device using up its battery.

 

I suppose in some ways there is also a third problem; the variance of mobile devices (and throw tablets and TVs in there for fun) means that relying upon on-device processing power is a dubious proposition at best.

 

So here comes the major philosophical disagreement: do the heavy lifting on the server and deliver the most highly optimized data you can, or do the heavy lifting on the device and run thin server logic.

 

If you’ve been reading up to this point you understand my perspective. From my standpoint the server is arguably the most important player in the ecosystem, because in a rapidly changing world of devices and platforms. Managing this on the device is a dangerous proposition at best, and in the end will get you to a lowest-common denominator solution.

 

Let me repeat, because the argument sounds counter intuitive: managing on the device gets you to a lowest-common denominator solution. Why is because it becomes impossible to manage through the different variants and profiles of devices, so you wind up picking the one that works the best on the lowest-end and spreading it across. With the solution pushed to the server you don’t need to do this… you can manage the different profiles remotely in a smarter, more intelligent way.

 

So to recap:

 

1. Hybrid apps are still relevant and useful, but can’t pretend to be something they aren’t (namely, pure native).

 

2. While smartphones have gotten progressively more powerful, the added strength doesn’t translate to being sloppy and careless about how you’re using the device.

 

3. Your strategy should be to do all of the heavy lifting on the server -even though powerful smartphones can in theory do it- because you have more control over your environment.

 

4. Your users may have bought an expensive, super-powered phone… but they still care most about the battery lasting through the day and signal strength.

 

Code safely out there.

 

%d bloggers like this: