The case for native apps

hsoi blog, talk Leave a Comment

No question the world moves towards mobile. Desktop computers, big servers, they won’t go away. But mobile is growing and I’m pretty sure it’s going to be the standard for most people’s way of interacting with the world.

I’ve been at this long enough and I know what many companies care about is how to deliver something as widely and as cheaply as possible.

That tends to leave out “good”.

I prefer to not skimp on “good”, and make the tradeoffs on “fast” and “cheap”. It’s always put me at odds with employers. *sigh*

Of course, even within our geeky ranks we tend to be fractioned and have our religious wars, always claiming our way is The One True Way to program. Alas, that’s not the case. There is no One Way, only one way that might be the right solution for the particular and specific problem.

One road PHB‘s like to go down is “write once, run everywhere”. They believe that writing an app one time so it can run on Mac and Windows and Linux and iOS and Android and as a web app and whatever… that’s the way to do it. So they decide what they want, pick some toolset that claims it will get them there, ignore the experience and advising of their developers, and forge ahead… only to discover after some time that this was a failed effort and they should have done things differently (and the programmers sigh in an “I told you so” sort of way).

The way you have to look at things is to approach the problem you’re trying to solve. Granted, one should take business realities into account (something many programmers don’t do, as they are stuck in their Ivory Tower) because that is a part of the problem to be solved. But never forget the end user must be the one satisfied. You need to make your decisions always with the end-user in mind. They may not praise your app if it’s great — and frankly that’s a measure of it being good because it should be so remarkable that it is unremarkable and “just works”. But if your app sucks? Believe me, you’ll hear it and your reputation will too.

That said, sometimes “write once, run everywhere” is the right decision. Sometimes it is not. Sometimes using a compiled language is right, sometimes an interpreted language is better. It really all depends what the particular problem is — right now (because requirements will always change).

Everyone thought mobile web apps would be the way to go. Even Apple did that when the iPhone first came out. Alas, we knew that wouldn’t work. I still see some apps that claim to be native apps but in the end are little more than a glorified shell around webviews. For some things sure, it can work. It doesn’t have the best user experience, but… I guess if your goal is merely to say “we have an app”, then I guess that checkbox is now filled.

So why not a mobile web app?

Drew Crawford writes a very detailed and thorough examination of why mobile web apps are so slow.

It’s full of geeky goodness, you may not grok it all. But for someone like me, this is gold.

In fact, it enlightened me to a few things about iOS which makes me more aware of performance and memory issues. In day-to-day work, you may not think of these things. But reading what Drew wrote, no question I’ve got more in my head to think about on a day-to-day basis.  It’s nothing my employers or users will likely ever notice or appreciate, but then that means I’m doing good. 🙂

If you are a developer and working in the mobile space in any way, give Drew’s article a read and be enlightened.

I’m sure that Drew’s assertions and data will be refuted, and I’m sure in a few years what he wrote may no longer apply. I think the bigger take-home is we, as programmers and people that wish to use software to solve our problems (so that means you too, CEO’s and such), we must be careful to assess and know our problem as a whole. We cannot ignore our users. We cannot ignore the user experience. We cannot ignore our hardware, our software, our networks. We cannot ignore our tools. We cannot ignore the realities, the limits, and constraints. We cannot allow what we know to guide us, because sometimes the right solution may require doing something new, learning a new language, learning new tools. And accept that no matter what we choose, we’re going to get some things wrong, and we’re going to face lots of challenges along the way. Just do your best, and stay open.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.