Jumping on the Mobile App Bandwagon: 6 Things You Should Know First

Dollars to donuts, someone’s bumped into you on an empty street lately because they were staring at their phone – evidence of the prevalence of mobile Internet usage. 63 percent of Americans use their smartphone for web access, according to a 2014 Pew study, and in six short years, experts predict, most people will be using their phones to buy things

Wait! Before you head to the Apple, Google, Microsoft, or Blackberry website to download the latest SDK or rush down the hall to your IT team with an ill-planned ultimatum a management directive, take a breath and head to your whiteboard. Mobile app development is like any other business initiative, requiring alignment with your strategic and tactical goals, financial projections, resource allocation, and assessment metrics. Don’t send your mobile app to development hell before the first keystroke. Plan, research, and plan some more, then implement, test and assess. To help you with that first step, here are six things you need to know before jumping on the mobile app bandwagon.

You might not need one

Just because these days mobile apps are as fashionable as big hair in the Eighties doesn’t mean you need one. What are you trying to accomplish? If all you are doing is sharing text information, rather than trying to create a unique user experience, then a mobile website might be best. Save yourself the higher development and maintenance costs of a mobile app if all you are doing is giving folks another way to access the independently audited financial statements are now available online, and other terribly exciting news (no offense to all you CPAs out there).

Native vs. web vs. hybrid mobile apps

I bet you I can name one native app on your phone right now: Candy Crush Saga! Ok, you don’t have to admit it, but that’s an example of a native app – one developed with a programming language (Objective-C, Java, C#, etc.) in an SDK, downloadable from an App Store, and operating on your phone, rather than a web browser. Mobile web apps, as you might have guessed, are accessed through a web-browser, and are developed with a web programming language (HTML5, CSS, Javascript, etc.). Hybrid apps are downloaded and operate on a mobile device, but are developed with web programming languages. Native apps usually operate at the fastest speeds, but are the most expensive to develop and maintain across multiple models of mobile devices. Web browsers are cheaper and less expensive to develop, but lack access to mobile device specific features, such as movement sensors. Hence, the hybrid to the rescue: a native app capable of harnessing mobile device features.

But don’t just choose what appears easiest and cheapest. Examine how people are accessing your website and your social media assets. Review any available research on your target audience’s smartphone usage, and use this information to guide where you’ll focus your efforts. Next you’ll need to know…

The strengths of each platform

With all due respect to the once-venerated Blackberry (and even to the emerging Windows Phone), if you’re thinking about developing a mobile app, your starting point is likely either iOS or Android. You’ll need programming knowledge of Objective-C for the former and Java for the latter. And whether you are an Apple or Google devotee is pretty much insignificant compared to how many members of your audience are. Again, take a look at your data, and use this as another guidepost to determine where to focus your efforts. For the differences between each platform will have a tangible impact on your user experience, as well as your development timeframes. In general, Apple has been more restrictive in what it allows developers to do, for example, dictating the look and behavior of common application UI elements (versus Android merely recommending them). This leads to more uniformity among Apple apps, whereas Google’s openness can lead to more creative designs. Ideally, despite the initial platform you choose, you’ll want cross-platform capability, which requires an understanding of iOS Human Interface Guidelines (as they are standards, not recommendations), as well as underlying differences in navigation, search, data views, and contextual actions between the two operating systems. Don’t forget about differing iOS and Android smartphone (and tablet!) screen sizes and resolutions, either or risk filling your app users’ mobile screens full of fuzziness, without the accompanying warm feelings.

What makes users warm and fuzzy: great UX

What exactly will your users experience when they open your app? Assuming you have a clear, singular experience in mind for all curious users, don’t send them scurrying to uninstall, or to another page (any other page!), through poor user experience (UX). Wireframe and prototype your app beforehand to ensure an intuitive navigational structure. Establish graphic and content standards in advance that are consistent with your digital assets and apply them consistently in your mobile app. Test your UX beforehand with actual users and save yourself heartburn afterwards.

Of course, another part of your user’s experience is how easily they can access your mobile app in all of its (preplanned) glory. While you have no control over their network’s connection speed, don’t contribute to high latency by failing to minimize your mobile web apps use of memory, processing power and bandwidth on mobile devices. Remember, people pay for data, and therefore, access to your website. For mobile web apps, limit your image usage and compress them to the point where the quickest load time meets the highest quality level. Also, to limit download time, send requests, searches, and the like to the background. Add a caching layer, which, while the application is running, caches elements like search results and processes, in memory. And consider developing an optimal concurrent download scheme for the parallel downloading of large files, to further reduce operating speed.

Can you do it? Or is this a vendor’s job?

If either of the last two sentences in the preceding paragraph made your eyes glaze over, you need to think about your mobile development process. We haven’t even begun to cover security concerns, testing, and deployments. Assuming you have a budget in the black, ask yourself:

Does my team (or do I) have the time to invest (including learning what I do not know) in developing (including planning, programming, testing, launching, and assessing) this mobile app?

If the answer to any part of that question is “no,” (or even a shaky “yes”), consider outsourcing some or this entire project to a freelance web developer or mobile app development company. It’ll be a challenge. You’ve got to find somebody who understands your core business, with a solid portfolio highlighting both their software architecture and their UX experience. Ideally, you want to look for an individual with design, testing, programming, and marketing skills, as well as, preferably, industry experience. Don’t be afraid to spend a little extra on a team with access to these skill sets, because deficits in any of these areas could sink your whole mobile strategy. Don’t forget to check references. With free development tools online, anyone can be a mobile app developer. But not everyone is a mobile app developer.

Return on investment

Wait one more minute! Before you start Googling “web developers,” look at ROI. This isn’t a question of whether you do mobile. Given its increasing importance, it’s how you are going to mobile, and more importantly how you avoid the mad dash to prove, post-implementation, that your mobile app was a success. That’s a race more often lost than won; and no one makes it to the finish line without a case of agita. Determine well in advance what the purpose of your app is, and what metrics can be measured to gauge its effectiveness. Whether you are looking at users, revenue, leads, conversions, or other metrics, eschew the big data generated by your analytics software in favor of the right data (i.e. what your boss or investors want to see).

[Featured Image: Pixabay]

Share with your friends
To report this post you need to login first.


  1. Sarcgirl
    • Christopher Hundley
    • Christopher Hundley

Leave a Reply

Your email address will not be published. Required fields are marked *