How your company approaches mobile app development can spell the difference between success and failure.

Mobile apps extend the boundaries of computing to on-the-go users and workers. They release value to our organizations by enhancing collaboration. Wouldn't it be great if deploying a mobile app were as simple as writing some code and distributing it? Unfortunately, it's not.

Consider the tech meltdown experienced by the Romney Campaign during the 2012 Presidential election: They'd developed a GOTV (Get Out The Vote) system called Orca that was supposed to help them coordinate their volunteers. But, as volunteer John Ekdahl reported in his blog Ace of Spades HQ…

For starters, this was billed as an "app" when it was actually a mobile-optimized website (or "web app"). For days I saw people on Twitter saying they couldn't find the app on the Android Market or iTunes and couldn't download it. Well, that's because it didn't exist. It was a website.

Bottom line? Instead of enhancing the campaign's collaboration, Orca's technology and management failure turned a promising mobile project into a massive collaborative collapse.

How can you avoid this kind of project collapse? The answer is to understand the platforms, develop a mobile strategy, and then choose the appropriate mode of development.

Mobile Computing: A Platform of Fragments

Choosing a platform for mobile collaboration can be a nightmare. There are as few as three and as many as ten different mobile device–specific operating systems that might be used by your potential users. These include the two most popular OSes—Apple iOS and Android—as well as the recently released Microsoft Windows 8 RT and Windows 8 Pro operating systems. But don't forget older operating systems, such as RIM's BlackBerry OS, Nokia's Symbian, and many more.

These operating systems—with the exception of Android—are all proprietary, they are not standardized across all devices, and they each require their own SDKs for your company to begin development.

App Development Strategies

Because of the variety and fragmentation of mobile platforms, your organization will need to establish a real mobile-computing strategy and then build standards for devices and operating systems that your organization can support. There are other important realities that need recognition as well.

• Rapid Evolution: Both the devices and the OSes are evolving at an incredibly rapid rate. For instance, Android follows an update schedule of every six to nine months; Apple iOS, every year; and Microsoft is moving to a six-month schedule. This can make a technical mockery of any standard OS enforcement your support team might be considering.
• Compatibility: As the functionality of devices accelerates, OS upgrades are not necessarily backward/forward-compatible. This means that an app that you create for one OS version may not work on devices from a previous or future generation of hardware.
• Supportability: Consider the trends that companies are facing with mobile devices. One is the Bring Your Own Device (BYOD) trend that encourages organizations to permit employees to use their personal mobile devices to access company data resources. It's a potential nightmare for IT support, so identifying the limits of your support will be crucial before you begin development of apps.

Modes of Development

So what are the ways your company might build mobile apps? How will your technical strategy be formulated? Let's look at the app development options.

Build Native Apps

The first option is to build OS-native apps using the OS-specific SDK in the languages that are supported. On the Apple platform, that means writing in Objective-C. On the Android package, that means writing in Java. For Windows 8 RT, it's C++/CX.

Native apps are fast, provide better user experience and interface, and have access to all device features for which they're built. On the down side, a native app can be used only for its specific platform, restricting which devices your users can use. For example, an Android app can't be run on an iPhone and vice versa. If you want to cover a larger audience across all platforms, you'll need to have separate native apps for them. Moreover, if one user creates data using an app on one OS and wants to collaborate with another on a different device, the apps that you write must handle the appropriate data format transformations.

Consequently, the native app strategy requires firm device standards and probably a separate developmental learning curve and crew. Unless your company has the resources and the commitment from management, you can anticipate a low Return on Investment (ROI) and a high Total Cost of Ownership (TCO).

Build Web Apps

The second strategy is to build Web apps that reside on your server and are sent to the device's Web browser. Web apps provide more-centralized control over a broader array of platforms, but they restrict the apps' potential functionality. In essence, your users are accessing specifically designed Web pages in HTML5 and CSS3.

Web apps can give you the highest ROI and the lowest TCO, but they're ultimately no better than your best Web site implementation: they require a connection to the Internet to function and are restricted to the speed of that connection. Moreover, Web apps are not accepted in any of the native app stores, cutting off an important distribution channel for your company. Also, Web apps cannot access or use the native APIs or device-specific hardware features.

Build Hybrid Apps

The third strategy is to build hybrid apps. A hybrid application is built using Web technology and then wrapped in a platform-specific shell (Objective-C for iOS, Java for Android, etc.) The native shell not only makes the app look like a native app and makes it eligible to enter the app stores, but also, developers can build in some of the native functionalities into it, to access some of the native APIs and use device-specific hardware features to some extent. A hybrid app is basically an app developed in combination with HTML5 and native technology. For cross-platform reach, developers would need to code the native part separately for each platform, but they can use the same HTML5 part across all of them.

From a management perspective, hybrid apps promise a better ROI and lower TCO than native apps and a higher potential functionality and transparency for users than Web apps. But they can also be difficult to coordinate through the development process.

Build with App Generators

The fourth strategy is to build apps using some form of cross-platform mobile app generator. The goal is to build one mobile app in one language and then spawn device-specific mobile apps from that source. This concept aims to increase the ROI and lower the TCO of developing an app across the entire spectrum of mobile devices, while still permitting distribution through an OS's app store and retaining the highest level of device-specific functionality.

App generators are typically sold by third parties and promise great benefits, but they have their own set of limitations. To date, according to many device OS developers and analysts, the resulting apps are often buggy and often end up being resource-intensive on the users' devices. But the economic arguments in their favor may be overwhelming to your management, and they appeal to many because of the reduced development cycle.

But note: If your IT department decides to move in the direction of using an app generator, it's important to realize that many of the companies that are selling these development tools have limited track records, marginal support profiles, and questionable business strategies. So choose wisely based not only on the capabilities of the tools to build apps for your particular set of devices, but also the reputation and longevity of the vendor. Because the technologies of app building are constantly changing, it's important to recognize that you're making an investment in your vendor's commitment to supply you with the best service over the long haul.

Mobile Apps for Collaboration

Mobile apps definitely offer some great opportunities for your company's productivity. But the paths you choose to create and maintain those apps should be based on a strong foundation of strategy that recognizes both the potential and the limitations of the fragmented technologies that are flooding the marketplace of devices. You can get there, but the paths can twist unexpectedly, and unless you choose wisely, you can easily end up at a dead end. Like the now-infamous Orca project of 2012, you want to avoid the pitfalls of this developing mobile technology arena. Your best strategy will always be to communicate openly with management, set realistic expectations, design toward the vision that your management has identified, and then test rigorously to ensure that your users realize the productivity that your management requires.