Take Charge Of Your Mobile App Strategy

InformationWeek Green - Sept. 26, 2011

InformationWeek Green

Take Charge Of Your Mobile Apps

But building and deploying a quality app can be daunting. Most companies don't have deep mobile app dev skills in-house. There are multiple operating systems to develop for, and hundreds of OS-device combinations. As companies consider their mobile app development strategy, one critical decision is what type of app you'll deploy. A second critical decision is how you'll deploy those apps--link your development strategy with mobile device management.

There are three main ways to develop mobile apps:

>> Develop a native application for each platform--Android, iOS, BlackBerry, etc.

>> Buy and use a cross-platform development framework, leveraging its APIs to write code once but have your app run on multiple platforms.

>> Use a mobile enterprise application platform, which provides prebuilt, enterprise-ready apps that integrate with your existing business systems via a vendor's framework, enabling rapid deployment of apps without much development.

Let's start by looking at each development approach, as each has notable pros and cons.

Native Apps

The main reason to develop a native smartphone application is because the app needs access to specific functionality provided by the device, such as an accelerometer, camera, or GPS, and needs the benefits of integration with other native apps and local processing. How many times have you downloaded an app on your phone and the drop-down boxes or check boxes aren't working like they do with the built-in applications on the device?

While it's easy to understand the pros of a native app, there can be many more cons if you don't have on-staff developers with considerable knowledge of the mobile platforms--and what IT organization has a lot of those skills?

While the pool of developers with experience writing for smartphones and tablets is growing, most IT organizations will turn to outsiders to develop native apps. Keep in mind these factors specific to today's mobile environments.

First, make sure the vendor has experience with developing the specific type of app you want, not just experience with the operating system platform. So if you're converting a CRM application for iPads, don't work with a company that has no experience with multiple input forms and database-driven applications. The risk is that it will develop a clumsy interface.

Second, make sure the vendor shows you the user interface before it builds the app and during development, using tools such as storyboards. Once it builds the full app, make sure that its quality assurance team is using handset-simulator software to test the native app on many different mobile devices. Different screen sizes, processors, and RAM can change the way an application functions.

Third, make sure you have a service-level agreement governing how quickly the vendor will fix problems. Unless you've standardized on one device for your app, the large number of mobile platforms and devices makes the likelihood of finding an incompatibility high. App users will want a patch immediately, but your vendor might take 30 or 45 days to turn one around. Android alone supports more than 200 devices and operating system configurations, and even Apple's closely controlled iOS has many versions that need testing.

The other major con for developing native apps is security. While secure software development practices have been around for years, most mobile development groups simply aren't following processes such as the Secure Software Development Life Cycle. It isn't just small companies that can run into mobile app security problems. In the past year, Citibank, Wells Fargo, and MasterCard have each released mobile applications that stored data, including PINs and credit card numbers, insecurely on mobile devices. This type of vulnerability is well-documented within the Common Weakness Enumeration database--as CWE-312. Yet mobile development groups seem to forget that mobile apps are going to be attacked frequently, just like any other app.

Compounding the security risk is the fact that native applications are custom to their various operating systems, such as iOS and Android, which makes analyzing their security more difficult because many tools that scan for vulnerabilities don't support these new platforms.

To read the rest of the article,
Download the Sept. 26, 2011 issue of InformationWeek