mrc's Cup of Joe Blog

Join us in exploring the world of modern development, evolving technologies, and the art of future-proof software

Have businesses fallen for Apple’s marketing?

Education“There’s an app for that.”

Who hasn’t heard that line by now? When Apple opened their app store back in 2008, they centered the ad campaign around that little phrase. From a marketing perspective, they were brilliant ads. They positioned the iPhone as much more than a phone. It was a device that could address most any need you were facing. Have a problem? There’s an app for that. Don’t have any problems? There’s probably an app for that too.

To put it lightly, the campaign (and the app store) was a great success. The app store now contains hundreds of thousands of apps. It recently passed its 10 billionth download. Other companies have opened their own app stores, hoping to cash in on the app trend. In short, consumers are crazy for apps.

The problem is, Apple’s marketing may have worked a little too well.

Business leaders have noticed the app craze, and many are rushing to jump on board. But, that’s not the problem. Mobile apps are a great idea for many businesses. They let business reach new customers and have a more productive workforce. Who doesn’t want that?

The problem is, some of these business leaders are blinded by the success of native apps among consumers. As a result, they choose the native app approach for their internal business apps, without realizing that they’re often impractical (and even harmful) for business.

Why? Let’s think about it. Suppose your business wanted to build a mobile app that let executives access reports from their phones. You can build it as a mobile web app, a native app, or a hybrid app. (If you’re unclear about the differences between these three options, here’s a handy comparison chart.) While each approach would work, you may not realize that the native approach causes a few problems, such as:

  • Limited options: If you build one native app for one platform, every user must use the same platform. If you ever want to switch to another platform, you’ll need new apps.
  • Costly expansion: If you want to expand your initial app to reach all platforms, you must build a separate app for each platform. As each platform requires a different programming language, this usually means that you’ll need multiple developers.
  • Lack of control: Are you comfortable with your apps being controlled by Apple, Google, or Microsoft? If you place an app in their app store, they control it. If they decide your app shouldn’t be in their store, you’re out of luck.
  • Uncertain future: The mobile landscape is changing rapidly. Just 5 short years ago, RIM and Palm were the big players. What will the mobile landscape look like in 5 more years? More importantly, what happens if the platform you choose doesn’t exist in 5 years? If so, any app you built for that platform is worthless.

As you see, blindly choosing native apps because they’re the “trend of the day” could create some problems for your company. On the flip side, if you decided to build that app as a mobile web app, you could avoid all of those problems. Mobile web apps let businesses instantly reach all platforms, and don’t depend on any other company. That’s not all. As this article explains, mobile web apps are usually the best option for business.

Now, am I saying that native apps are always a bad idea for business? No. But, if your company is planning on building native mobile apps, ask yourself this question: Is this approach the best choice for our business? Do we need to incur the extra time and expense necessary to build native apps? To help you understand whether or not your company needs native apps, ask yourself these four questions:

  • Does this app need to reach a large consumer audience?
  • Do you need to sell your app?
  • Do you require game-like graphics?
  • Does your app need access to all of the phone’s hardware sensors? One note on this topic: Many people are unaware that mobile web apps can access most hardware sensors, like the GPS, gyroscope, accelerometer, and more. This article covers the topic in greater detail.

Did you answer “Yes” to any of those questions? If so, the native approach might very well be the best approach for your business. If not, you’re better off with a mobile web or hybrid approach.


Don’t let your business get suckered into the native app craze. While currently popular with consumers, native apps aren’t often the right choice for business. Before you decide which direction to take, make sure you understand the pros and cons of each method.

9 thoughts on “Have businesses fallen for Apple’s marketing?”

  1. You missed at least one other reason to go native:

    Do you need to store a lot of data locally on the device? I know HTML 5 gives you access to some amount of local storage but if you need to use a large number of SQLite tables or a few tables with a lot of data you wish to cache instead of loading each time then web based might be a bad idea.

    Going mobile raises some other issues too. You will have a different set of potential bugs on each device. It is very similar to writing web apps for PC, Mac, Linux on IE, Chrome, Firefox, Safari, Opera etc.

    Mobile processors are not as fast as desktop processors and the mobile browsers might not be as optimized.

    Any time you don’t go native you tend to get lowest common denominator abilities. If people want it to look and act just like an iPhone app or just like an Android app they are going to get close but not be exact.

    If you can reach your end goals using web based only then it really is the way to go. You can update as often as you like without going through the various markets and stores. You can have a bug fix out in a matter of minutes of needed. You can have a team of HTML5/CSS experts instead of an Android person, an iOS person, a Windows person and a BlackBerry person you are busy trying to retrain.

    If the app starts to grow and you hit the limitations of the browsers you may end up needed to convert to native. Really try to plan your app at the start of the process to make sure mobile can handle it through various releases otherwise you will end up throwing away a lot of code and programming effort.

  2. Joe Stangarone

    Thanks Kevin, that’s a great point! HTML5 does have a limit for offline storage. From what I’ve seen, there’s a limit of 5MB for web storage and 25MB for web SQL database storage. So, if you need to build an app that stores lots of data on the device, native is the way to go.

    Though, storing data on employee smartphones can create a some pretty big security issues, depending on the data. I sure wouldn’t feel comfortable with an app that stores confidential data on 50 employee smartphones. What happens if/when one of them gets lost? I realize that some companies absolutely have to store data on the device, but that’s not ideal from a security standpoint.

    I think we agree on the main point: If a mobile web app accomplishes your goals, it’s the best option. The (growing) problem that I was trying to address is this: Many companies that can and should take the mobile web app approach are trying to go native because their CEO has decided native is the only option. These companies are actually doing themselves a disservice by not stopping to analyze their needs and options. In some cases, native might be the best option. In other cases, the mobile web might be best. But, they’ll never know if they don’t understand the pros and cons of each method, and actually take the time to make a plan.

  3. I’d suggest considering these questions as well, when evaluating native vs. HTML:

    – Would your app benefit from the more streamlined and integrated user experience a native toolkit can provide?

    – Does your app need to run in the absence of a network connection?

    I agree that, in many cases, it will be more cost-effective to use a cross-platform technology like HTML to build an application’s user interface, but not always. The nature and complexity of an application have a large impact on determining the “right” tool for the job.

  4. Just a follow-up thought – you seem to be making an assumption in this piece as well as in the comparison chart that developing a web application is “easier” than building a native app, and thus can be done faster and more cost-effectively. Again, I think that in many cases, this is true, but certainly not all. Because native development tools and APIs tend to be more robust, a qualified iOS or Android developer may actually be able to crank out a fairly sophisticated application much more quickly than a comparable HTML developer.

    So I’d suggest that another important consideration is the skills of your available resources, or the cost of acquiring and maintaining those skills.

    1. Thanks for the comments, Greg. Those are great points! I agree–in some cases, native apps are the best choice for business. It all depends on the company and the application requirements. Though, from what I’ve seen, the majority of companies looking for mobile apps are better off taking the mobile web app approach.

      Also, I wouldn’t say that developing a single mobile web app is easier than developing a single native app. However, it’s far easier to reach all platforms using the mobile web app approach. That’s the main point–when a company builds a mobile web app, it works on every platform, both now and in the future.

  5. The data we happen to be storing on the device is not personal data but large tables such as diagnosis codes, facility names, CPT and ASA codes. They are look up tables used as the provider is filling out medical forms.

    I also store images from the camera of medical paperwork but these are compressed and encrypted and stored as blobs. Can’t leave them hanging out in the main device gallery.

    You have to log into the app and without a jail broken phone others can’t just randomly open the database and tables on the device.

    Working off line was an excellent point by Greg. Not all operating rooms or other hospital facilities have the best cell network connectivity. People don’t want to stop working just because they don’t have a solid connection. A native app allows you to continue to work off-line if properly coded.

  6. While I agree with your points about the native apps, I think you missed the most important thing about native apps – they are much smoother than other types of apps.

    True, companies need to build an app for every platform, but from what I’ve seen is that only companies who know can afford it are building apps. Yes they mobile landscape is changing rapidly, but that’s a curse we’ve all suffered from since the day the computer has been invented. (Remember DOS applications, and then they had to be ported to Windows, etc…)

    1. Thanks for the comment, Fadi! I don’t deny that native apps are smoother than mobile web apps, though not by all that much. However, the bigger question is this: Is that worth the extra time and effort to build native apps?

      For instance, if a company wants to build mobile apps for all platforms, native apps require far more time and effort than mobile web apps. Going forward, maintaining multiple native apps will be much more difficult than maintaining one mobile web app. Also, what if a new platform emerges in the next few years? Now they’ll have to build yet another app.

      It all comes down to the company needs and requirements. Is a smoother interface important enough to justify the difficulty of building native apps?

  7. Pingback: » Have businesses fallen for Apple's marketing? | mrc's Cup of Joe Blog

Comments are closed.