Enterprise Native Mobile Application Development

Question

I tend to believe that developing mobile applications in an enterprise environment is best suited by developing intranet web applications. That said I have been asked to think about whether there are specific enterprise applications that could only be accomplished or would be more successful as native applications. I am curious as to what the Stack Overflow community thinks.

Note: As an organization we primarily use BlackBerry devices but are other platform curious.

Answer 1

While there may be some specific enterprise applications that are best as a native app I can't think of any concrete examples.

However while I agree with you about intranet web apps are typically better, I think that all depends on who its better for. Obviously intranet web apps are better for development, and better since they can be cross playform, however I think that virtually all apps are better native for the end user. Don't agree? Look at the number of successful iPhone and Android apps that are out on the market that are just native portals for some site's data. Users far prefer the way a native app works over a mobile browser.

Also another thing I would take into consideration is if the app already has an intranet web app in use designed for desktop systems. If there is one, I would go the native app route since the users on the other mobile platforms can still access the desktop version. However if there is no universal portal I would consider doing that vs native.

Answer 2

The ideal would be to do both.

Have something like a secure restful interface that feeds json or xml to a native mobile application. The restful interface would be easier to start with, easier to test, easier to prototype, and easier to change. It would also make life infinitely easier when the data needs to be synchronized, backed up, cloned, or when the phone gets lost/broken/stolen/upgraded.

And then, having a native application built in addition to the restful interface would also allow for the use of the Native UI environment. It could allow the app to work offline. It could use its own notification-system, without going through SMS/push-mail. And if some of the relevant data was indeed mirrored offline, the application would become also more responsive, and much easier to use with other apps (where it comes App-functionality sharing, I'm only speaking for the Android SDKs here, and mostly the future version of the iPhone SDK, not the Blackberry yet). The end result would probably a much cleaner and much more pleasurable application to work with, assuming it could also be done as a Native Application.

Answer 3

A few of domains seem better suited to native apps off the top of my head:

• Applications with disconnected data sets. Mobile apps cannot always count on having an Internet connection. Native apps handle that case well. This is especially true for data entry tools. If you receive a call in the browser while entering data, the work may be lost if the page reloads after relaunching Safari.
• Apps that need the user to upload media like photos, videos, and sound recordings. Currently, there is no way to upload local iPhone media via MobileSafari. Native apps handle this case. Insurance and real estate might be good markets to target with this.
• Advanced processing apps. For example, if you wanted an inventory management app that could read barcodes using an iPhone's camera, a native app can process imaging data much faster. Any augmented reality app would run best as a native app.
• High memory apps. When other apps run, Safari still chugs along in the background. If those apps need more memory, Safari will release the RAM allocated to a "tab's" page contents. That page then reloads the next time a user opens Safari. If your app needs lots of RAM, then making it a native app gives you higher priority than remaining a web app.
• Needs to run in the background as a service. Starting with 4.0, of course, you can build IT asset tracking services, GPS logging, corporate messaging (think Microsoft Office Communicator for iPhone, etc.), regulatory compliance monitoring, order notifications, custom SIP/H.323 endpoint for a VoIP switch, etc.
• Large datasets. I believe Safari limits SQLite databases to 50 MiB max. For a native app, the available space will be constrained primarily by the available space on "disk."

Actually, just looking through the API. Any API not available via a webapp would be a good place to start. I'm being coy, here, regarding 4.0 API's that are currently under NDA. :)

That said, SproutCore Touch provides a good web platform that is specific to touch interfaces.

Answer 4

I would recommend that the decision regarding whether to create a web application, native client, or both, should be made after understanding the problems you intend to solve and examining the needs of the end users of the application. It would be impossible to suggest that you can answer the technology question without understanding the user problem.

In Chapter 8 of "About Face 2.0: The Essentials of Interaction Design", Alan Cooper talks about software postures. One of these postures is called the "Sovereign Posture." This posture represents an application that is typically used full screen and for long periods of time, and represents the primary application for a given user. Visual Studio and Eclipse are good examples of sovereign applications for developers. If the interface in question is a sovereign application for a user, that strongly favors a native client.

In a specific enterprise example, a service desk application is a sovereign application for technicians, but it is a transient application for users. I would suggest that an ideal factoring of such an application would be a rich native application for both desktop and mobile devices for technicians, and a self service web interface for users. For the technician, the advantages of a native application outweigh the costs of deployment, given that there are generally fewer technicians. Also, the technician may be working on a network problem, and the offline reliable nature of a native client allows the technician to continue using the application even when the network is unavailable.

If the user spends more than a few hours a day interacting with the application, then strongly consider the advantages of a well designed native client. If there are multiple users, consider how each role uses the application, and perhaps you end up with a hybrid model. Your UI strategy should always be based on examining use cases over following gospel from either camp, and should be focused on the user experience, not developer convenience.

Answer 5

The pros of native app development are primarily around getting access to hardware features that aren't accessible through web APIs, obtaining native performance benefits (such as in action gaming), instant access to paying customers through a platform store (such as iTunes), and security situations where you don't trust the browser or how it's handled.

The cons of native app development are that you lock yourself into a potentially proprietary code platform, write a bunch of device-specific code, and you're vendor locked. Code is harder to write, much harder to deploy, and you stand the chance of having the rug pulled out from under you. (Yes I'm looking at Apple, but could happen to any proprietary platform.)

Web apps by contrast are based on technologies that are widely known and easy to deal with - HTML5, CSS3, JavaScript, and excellent libraries such as JQTouch are available to help. Well-designed web apps for the most part will not care if you're on a Blackberry, Android, or iPhone, and will work on many of the older and less capable models as well as the newer ones and devices we haven't even encountered yet, without having to recompile or refactor (or at least without having to do a great deal of recompiling or refactoring...) And there are some hardware features accessible, such as GPS through the geolocation API.

But on the other hand web apps may not perform well with large data sets or high computational requirements. If you're building a commercial app with financial transactions, you very likely will have to roll your own payment system. And you have to trust the browser security as well.

All in all, most apps are going to make the best sense as web apps. However, many web apps can be made to function to be almost indistinguishable from client apps. With some HTML5 offline storage, CSS3 and JS functionality for transitions and behaviors, many business apps can be made to be indistinguishable from native clients.

In iPhone's case we can take it further: Adding a 57x57px icon apple-touch-icon.png to your web app’s root directory will provide iPhones with a nice custom icon when users add an app to their home screens (iPhone will take care of the rounded corners and glossy visual effect) and you can make an iPhone app go full screen when clicked from it’s home screen icon by adding . At this point, the app has it's own icon and runs full screen - the user doesn't know it's web based.

And if you do want to go native but don't want to abandon web standards, most native APIs provide the ability to develop native clients based on HTML/CSS/JS using a simple wrapper, such as the UIWebView in Objective-C. PhoneGap is an excellent cross-platform framework enabling standards-based web development practices to be deployed on iPhone, Android, and Blackberry.

Answer 6

I'm with Stephan, use a native app and feed it XML to get the best of both worlds. That's what our company does, so I know it works. We install a native client app for each platform that manages our local storage, data connectivity, software updates, authentication, etc. Then we create XML-based custom business forms for our customers that contain end user UI, business logic, and specific data connections to the customer's Web services and SharePoint sites. We use InfoPath to create these business forms, so it's pretty easy. We currently have clients for Android, Windows Mobile, and just announced iPhone is coming soon.

One XML-based form works across all platforms, so you get the same primary advantage as a Web app. But the native client gives you robust offline capabilities too. And yes, I'm here to tell you it's for sale if you want to use it for your company, and we have a partner-based distribution model if you want to offer it to your customers. It's also a unique architecture that I hope this community will find interesting as an alternative to the Web-or-Native conundrum so many are facing these days. Check it out, and let me know if you have questions:

Formotus mobile business application platform

-Glen