Speed Matters, but Dev Speed or App Speed?

In running, speed matters. But how the speed matters is very important, and what type of running is your forte’ should determine what you are involved in. As a teen, I was never a very good sprinter. Just didn’t get up to speed fast enough, and was consistently overcome by more nimble opponents. But growing up on a beach was perfect conditioning for cross country track. Running five miles in beach sand that gave way underfoot and drained your energy much faster than it allowed you to move forward was solid practice for running through the woods mile after mile. And I wasn’t a bad runner – not a world champion to be sure – but I won more often than I lost when the “track” was ten or fifteen miles through the woods.

The same is true of mobile apps, though most organizations don’t seem to realize it yet. There are two types of mobile apps – those that are developed for sprinting, by getting them to market rapidly, and those that are developed for the long haul, by implementing solutions based around the platform in question. By “platform” in this case, I mean the core notions of “mobile” apps – wireless, limited resources, touch interfaces, and generally different use cases than a laptop or desktop machine.

It is certainly a more rapid go-to-market plan to have an outsourcer of some kind dump your existing HTML into an “app” or develop a little HTML5 and wrap it in an “app”, but I would argue that the goals of such an endeavor are short term. Much like sprinting, you’ll get there quickly, but then the race is over. How the judges (customers in this case) gauge the result is much more important. There are three basic bits to judging in mobile apps – ease of use, which is usually pretty good in a wrapped HTML or “hybrid” app; security, which is usually pretty horrendous in a hybrid app; and performance, which is usually pretty horrendous in a hybrid app. The security bit could be fixed with some serious security folks looking over the resultant application, but the performance issue is not so simple.

You see, performance of a hybrid application is a simple equation… Speed of original web content + overhead of a cell phone + overhead of the app wrapper around the HTML. Sure, you’ll get faster development time wrapping HTML pages in an app, but you’ll get worse long-term performance. Kind of the same issue you get when a sprinter tries to run cross country. They rock for the first while, but burn out before the cross country racers are up to speed.

You can use tools like our Application Delivery Optimization (ADO) engine to make the wrapped app perform better, but that’s not a panacea. Longer term it will be necessary to develop a more targeted, comprehensive solution. Because when you need a little bit of data and could wrap display functionality around it on the client side, transferring that display functionality and then trying to make it work in a client is pure overhead. Overhead that must be transmitted on a slower network over what is increasingly a pay-as-you-go bandwidth model. Even if the application somehow performs adequately, apps that are bandwidth hogs are not going to be repaid with joy as increasing numbers of carriers drop unlimited bandwidth plans.

So before you shell out the money for an intermediate step, stop and consider your needs. Enterprises are being beaten about the head and shoulders with claims that if you don’t have a mobile app, you’re doomed. Think really carefully before you take the chicken-little mentality to heart. Are your customers demanding an app? If so are they demanding it right this instant? if so, perhaps a hybrid app is a good option, if you’re willing to spend whatever it costs to get it developed only to rewrite the app native in six or ten months. Take a look at the Play store or the Apple store, and you’ll see that just throwing an app out there is not enough. You need to develop a method to let your customers know it’s available, and it has to offer them… Something. If you can’t clearly define both of those requirements, then you can’t clearly define what you need, and should take a deep breath while considering your options.

Let’s say you have a web-based calculator for mortgage interest rates. It is calling web services to do the interest rate calculations. For not much more development time, it is possible to build a very sweet version of the same calculator in native mode for either iPhones or Android (depending upon your platform priorities, could be either), with a larger up-front investment but less long-term investment by re-using those web services calls from within the mobile app. A little more money now, and no need to rewrite for better performance or targeting Mobile in the future? Take the little extra hit now and do it right. There are plenty of apps out there, and unless you can prove you’re losing money every day over lack of a mobile app, no one will notice that your application came out a month or two later – but they will notice how cool it is.

While we’re on the topic, I hate to burst any bubbles, but every single website doesn’t need a dedicated app. We have to get over the hype bit and get to reality. Most people do not want 50 reader apps on their phone, each one just a simple hybrid shell to allow easier reading of a single website. They just don’t. So consider whether you even need an app. Seriously. If the purpose of your app is to present your website in a different format, well news flash, all mobile devices have this nifty little tool called a web browser that’s pretty good at presenting your website.

Of course, when you do deploy apps, or even before you do, consider F5’s ADO and security products. They do a lot with mobile that is specific to the mobile world.

App development is no simple task, and good app development, like all good development, will cost you money. Make the right choices, drive the best app you can out to your customers, because they’re not very forgiving of slow or buggy apps, and they’re completely unforgiving about apps that mess up their mobile devices.

And maybe one day soon, if we’re lucky, we’ll have a development toolkit that works well and delivers something like this: