Choosing a mobile development strategy for your agency

As everyone knows by now, mobile computing via smart phones, tablet PCs and whatever new handheld gadget comes along next is only going to get bigger and more essential to the way people take care of business — at work and in their personal lives. A growing number of CIOs are already planning for that eventuality and are starting to develop a mobile strategy for their agencies.

In one of the boldest statements of intention to date, the Environmental Protection Agency, under its new “mobile first” policy, will make mobile websites and applications a priority over traditional platforms when developing new applications for interacting with the public and EPA employees.

“We are primarily thinking toward mobile-oriented, website-based applications, but certainly part of our strategy is to look at definitive operating systems like Android, Microsoft, Apple's iOS and others,” said Malcolm Jackson, CIO and assistant administrator of EPA's Office of Environmental Information.

Beyond EPA, nearly two-thirds of agencies are using or assessing the use of mobile applications, according to a MeriTalk survey of 152 federal CIOs and IT managers in December 2011.

Despite associations with consumer culture and game apps, mobility expenditures represent serious business for IT budgets. Enterprises are spending 21 percent of their IT and communications budgets on mobility, and they expect that to increase to 37 percent in the next three years, according to an InfoTrends survey of almost 500 IT executives.

Does all that interest and increased spending mean every government app is heading to the small screen? Of course not. Not all workers are roving around the office or out on the road, and certain computing tasks will always work best with a full-scale screen and processing horsepower.

However, many functions will not just get by but will excel in the mobile environment, boosting convenience and unleashing greater productivity. To start building that mobile future, government CIOs need a mobile application development strategy. And one of the key questions they must ask is whether to create mobile websites or native mobile apps.

The case for native apps

Most of the attachment people have to their smart phones and tablet computers revolves around the apps they download. Apple’s iOS and Google’s Android are the two operating systems that underpin the market-leading mobile ecosystems, with Microsoft Windows Phone and Research in Motion’s BlackBerry OS trailing, though they are perfectly legitimate alternatives.

So-called native apps are built for a particular platform or mobile operating system. Therefore, when they are written well, they integrate seamlessly with a device’s basic software and hardware features, down to their menu buttons and support for multi-touch gestures such as finger swiping and pinching. They also include all the hardware goodies, such as Global Positioning System location tracking, camera functions, data storage, advanced graphics and an accelerometer for movement detection.

That tight integration enables a rich user interface, top-notch functionality and responsiveness, which is why native apps are a developer’s first choice when an excellent user experience matters most.

That’s what National Security Agency recruiters were after with their NSA CryptoChallenge game app, so they chose to go with a native iOS app. If it was delivered via a mobile website, the app would have had greater latency and thus an inferior user experience, “so it might have been detrimental to the younger group of people the NSA is trying to recruit,” said Larry Littleton, global mobility solutions manager at CACI, which built the app for NSA.

Likewise, NASA developed native iOS and BlackBerry versions of its WebTADS Mobile, a labor code and time-recording app for the agency’s civil servant employees. “We wanted to provide the user the most responsive and rich user experience possible,” said Jane Maples, manager of NASA’s Center for Internal Mobile Applications.

Platform-specific development has also been the choice when apps need to be able to operate even when a mobile device is not connected to a network. The Transportation Security Administration built an iOS version of its My TSA app for travelers in addition to a mobile Web version. However, in the iOS version, the feature that provides travelers with airport security guidelines called “Can I Bring?” can still work off-line.

“Since Wi-Fi or cellular service can be intermittent, allowing components of an application to function off-line can make a lot of sense for the user,” said Neil Bonner, a program manager at TSA’s Office of Information Technology.

There are two primary drawbacks to the native approach. The first is the difficulty agencies face in hiring and retaining software programmers experienced with iOS, Android and other mobile platforms, several agency leaders said.

For example, Mississippi officials could not hang on to mobile developers because they were lured away by higher-paying opportunities in the private sector, where their skills are also in great demand, said Craig Orgeron, the state’s CIO, during a presentation at last month’s FOSE Conference in Washington, D.C. Officials are now exploring options for developing mobile apps with help from industry.

The other drawback is the need to write and maintain software code for every device platform you want to support. Unless you have programmers who know multiple platforms, you will need separate developers for each platform you want to reach. The quick pace at which Apple and Android’s many market players introduce new devices and update software further complicates and raises the cost of a multi-device strategy.

However, those kinds of costs can be overstated, especially if the mobile apps will integrate tightly with back-office enterprise systems, said Tim Hoechst, chief technology officer at Agilex, an IT services firm that has helped numerous agencies develop mobile solutions. Ninety percent of those apps’ functionality should reside on the agency network in a common service-oriented architecture in the form of application logic, security controls, and data access and validation processes.

“If this is true and you do it well, then writing two copies of the same native app is not that big a deal,” Hoechst said.

The case for Web-based mobile apps

When you think about how mobile applications will work in a Web-based paradigm, don’t picture the little text-based Web pages stripped of graphics and optimized for the small screen of a mobile device and slow wireless networks. That style of mobile website is a dinosaur heading for extinction.

In its place will be Web apps built using the new HTML5. Although not yet complete and officially ratified, HTML5 has plenty of support in Web browsers, and development tools are already available. In terms of overall user experience and functionality, mobile Web apps still lag behind native apps, but that gap is steadily closing as HTML5 matures.

The mobile Web approach with HTML5 has numerous benefits. The one most often cited is also the most obvious: Agencies only need to write one version of an app and it can be used on any smart phone or mobile device with a Web browser and Internet access.

That efficiency has strong appeal for the Energy Department’s National Nuclear Security Administration, which will focus its still-formulating enterprise mobile strategy on Web-based rather than native apps, said Travis Howerton, NNSA’s CTO.

“The mobile OS space is very fractured,” Howerton said. “I really can’t afford to maintain three separate code bases. I think we can meet a lot of our needs with HTML5 with dramatically reduced costs.”

There are also more developers available — often already on staff — who know HTML and other common Web languages such as Java, which makes hiring easier and keeps labor costs in check compared to needing specialists for each platform in a native scenario, Howerton and others said.

Howerton foresees developing mobile apps at NNSA for internal employee use, so the feature and capability advantage that native apps currently enjoy over Web apps is not as important to him. And in any case, that edge is shrinking all the time.

For example, with the latest Web standard for Cascading Style Sheets, HTML5 enables slick usability features and better graphics, similar to native apps. HTML5 also supports audio and video tags, so users don’t need to install plug-in software to handle multimedia.

HTML5 support for local device, or client-side, storage means that when a Web app is designed accordingly and with adequate security, it can run even when the device is not connected to a network. Developers can also place an icon shortcut to that Web app on the mobile device’s main screen, so from the user’s perspective, it can be launched just like a native app.

Tight integration between HTML5 apps and a device’s hardware capabilities, such as GPS for location-aware features or the camera for geotagging pictures, is still maturing. Although not ideal for every situation, there are numerous products available that provide a proprietary integration between HTML5 apps and device hardware capabilities.

Another benefit of mobile websites is that agency officials can track usage with already familiar Web analytics tools, Bonner said at a mobile app webinar hosted by the General Services Administration last December.

Mobile Web apps are attractive because of their device-agnostic nature and the low barrier of entry to develop and field them, but agencies need to look at the whole picture, Littleton said. Mobile Web apps still require all the same life cycle software development steps that native apps do, such as requirements analysis, quality assurance, security controls and documentation, so there are no shortcuts with HTML5, he said.

Moreover, different Web browsers vary in capability and support for HTML5, as do different versions of the same browser. That could prompt developers to default to a safer, less feature-rich app design to ensure compatibility.

“It is probably a bit more complicated to write one app that works well across platforms,” Hoechst said.

The verdict? It depends.

What is true today about the relative strengths and weaknesses of the two approaches to mobile app development will not likely be the same two years from now. Accordingly, most of the government and industry IT managers and experts interviewed for this story expect a much greater role for HTML5 apps in the next few years.

But for now, there are plenty of situations in which native apps are preferred or even required, depending on the objective and user requirements.

Next steps: Exploring other mobile opportunities

While you’re busy turning enterprise IT upside down to accommodate mobile technology, you might as well look into these other areas. They are not all strictly focused on mobile, but they are cost savers and productivity enhancers that mesh well with the mobile way of thinking.

1. Start an app store.

The Defense Department, the General Services Administration and NASA are all building online app stores where users can find and download mobile apps. Besides the convenience they offer, the stores might also open the door to new models for how agencies acquire software, such as paying commercial developers a fee every time users download their apps as opposed to making an upfront payment for the whole project, said Tom Suder, president of Mobilegov, an IT services firm.

2. Use mobile as an entrée to agile software development.

CIOs eager to try agile development but skittish about plunging into unfamiliar territory for a multimillion-dollar, mission-critical application might find more courage to test it on a simple mobile app that costs only tens of thousands of dollars to create. A mobile app’s narrow functional scope, quick delivery timetable and small development team make it ideal for agile techniques, said Tim Hoechst, chief technology officer at Agilex.

3. Don’t overlook other mobile options.

Devising a mobile application strategy is not as binary a choice as Web-based vs. native. Agencies could use a virtual desktop infrastructure solution to deliver a server-based software image of users’ applications to their mobile devices, Hoechst and others said. Mobile enterprise application platforms are another option. Those products could help agencies centralize their mobile efforts with a proprietary toolset that allows them to write an app once but deploy it on multiple mobile operating systems and devices.