Developing mobile applications for the enterprise is considerably different than developing mobile apps for retail sale. If there is one thing that differentiates enterprise development from commercial development, it’s the budgeting process. While a commercial team may have a constrained budget and a time window (often identical, as in, “We have enough money for one year.”), it’s generally a constraint that defines the entire company.

In an enterprise setting, there are any number of other projects that might otherwise be funded. Mobile apps are still very risky in terms of return on investment (indeed, I’d be extremely skeptical about any ROI model that didn’t emphasize the unknowns), and thus, in an enterprise situation, are political lightning rods.

There are three major routes forward for a mobile application: Web-based, cross-platform and native. Developers will likely advocate for the native solution, which is most interesting and fun from a technical perspective. Of course, enterprises typically target heterogeneous users, and that means multiple native applications that can share little other than high-level architecture. Add in questions of deployment and maintenance, and the wise choice for most enterprises is to avoid native solutions.

Cross-platform development for mobile has become an absolutely viable route. Although Apple has held a firm line against interpreters and virtual machines in iOS, it has decided to allow (or at least not actively suppress) applications that compile to native code and link to the CocoaTouch libraries.

Of the possibilities, I am most familiar with MonoTouch. The Mono Project extends back more than a decade to the very first days of .NET, and was essentially a Linux version of the .NET Framework and C#. Mono’s been the property of three companies (Ximian, Novell and, as of last year, Xamarin), but has stayed under the guidance of its originator, Miguel de Icaza.

Mono has always maintained a very high-quality C# front end and, for mobile applications, MonoTouch (for iOS) and MonoDroid (for Android) use C# as the application language, but also bind to the native APIs, allowing for a good deal of cross-platform use. (This is assuming that your application has a decent separation of reusable model code and platform-specific view code.) I have not yet deployed a MonoDroid application, but I have found developing MonoTouch applications for iOS to be a pleasure (admittedly, 90% of iOS documentation is going to assume Objective-C as the programming language and, because working in iOS always involves XCode, there can be a certain amount of clutter in terms of open windows).

Having said that, I think that the wisest strategy for the majority of enterprises is to make their first mobile projects Web-based. Above all, it’s a matter of risk management. The productivity of your developers while they are learning a new platform is going to be low. Will they accelerate and get better? Yes of course, but at what point in the development cycle? What will their productivity be at the end of the first month or the second? Trying to build a budget or staffing profile based on such guesswork is very dangerous.

Web development, on the other hand, is a known factor. You know what the general structure will be (hypermedia), you know the UI technology, you know the frameworks. Since the handset browsers are modern, you’ll have access to newer APIs and freedom from compatibility fixes. You can tweak your CSS to perfection. Another less-obvious productivity gain arises from the speed of feedback with Web development: It is much faster to tweak CSS and see the change than to build and deploy a new native binary to a simulator.

With a Web-based solution, you may not be able to have all the features on your wish list and you may not be able to take advantage of the handset’s latest features. This is a good thing: Your initial mobile application will probably have significantly lower customer satisfaction than you expect, and focusing on core value and iterating your application is a much better strategy than spending excessive time chasing new platform features.

The downside of all this is that, yes, you are “building one to throw away.” All mobile solutions are likely to have a significantly shorter lifespan than is typical of enterprise applications. A Web-based solution may be under-featured, but at least it will run on handsets in the future. Other than that, no one really knows what the future holds. The iPhone just recently turned 5. Remember what mobile development was like before the iPhone? Me neither.

Larry O’Brien is a technology consultant, analyst and writer. Read his blog at www.knowing.net.