If you don't already have a mobile development strategy, you'll need one soon, and one of the first choices you'll need to make is which language to use for development.

Mobile development is the next great wave of development. Like it or not, mobile devices are becoming ubiquitous and your IT strategy is going to have to support them, both for B2C (Business to Consumer) and B2E (Business to Employee) architectures. And the really bad news is that if you're only just now figuring out your browser strategy, you're probably a couple of years and at least one development paradigm behind the curve. This article will try to bring you up to speed really quickly.

Where Are We and How Did We Get Here?

This isn't a tongue-in-cheek question. Taking a step back and looking at the bigger picture is the only way to get a productive sense for the subject, especially if you're currently immersed in the tail end of the last cycle. You need to see the forest instead of the trees. So, what are these cycles of which I speak? Well, they're the larger architectural currents that drive our somewhat more insulated world of business applications. Computer architecture moves in waves. Each wave is distinct, but the waves share similarities as well. For example, when we had this discussion 20 years ago (you remember that, don't you?), we were talking about which languages to use on PCs that would talk to our midrange applications. We argued about devices: IBM PCs or clones? We argued about platforms, Windows or OS/2, and whether to use Basic or C or C++ (or Pascal or Smalltalk). Ten years ago, the discussion was superficially very different because we were talking about browsers and the World Wide Web, but really was it all that unique? We were talking about devices (which browser), platforms (CGI or servlets or IIS) and languages (Java or Visual Basic or Perl or PHP).

It's 10 years later still, and now we're talking about Brand New Challenges (TM, patent pending)! We're talking about devices (desktops, phones, and tablets), platforms (Android and iOS and BlackBerry), and languages (Java or Objective-C or C#)! Which maybe isn't so new after all; in fact, maybe it's exactly what we've been talking about forever. The only difference is that the problem is getting larger, maybe even exponentially larger, as the number of moving pieces skyrockets.

A Quick Look at the Choices

So what are the choices these days? While this article will focus on language, decisions of device, platform, and language are as interconnected as they always have been. If, for example, you somehow manage to choose Objective-C as your primary programming language, you've pretty much narrowed your focus to nothing but Apple products and iOS. But let's see what the options are and where they take you.

Before I do that, though, we have to at least discuss the two basic underlying options for mobile development: native and Web-based. Nearly all devices that we care about in the modern business environment support two distinct modes of interaction with the user. The simpler of the two is the standard browser (or Web-based) interface. The word "standard" is a little tricky; these devices don't run Internet Explorer or Firefox, but they are in fact probably running a more standard browser. With the exception of the older BlackBerries, any device you can hold in your hand is probably running a browser built on top of the Webkit layout engine, which means that all these devices are remarkably consistent in how they display Web pages. This in turn means that Web-based application targeting that layout engine will run without much modification on all those devices. And since Webkit supports HTML5 and CSS3, you can build some awesome interfaces without having to go outside of HTML and JavaScript.

So then, we're done, right? HTML5, CSS3, JavaScript, and we can handle anything! Unfortunately, it's not that simple. That's because, while the browsers are indeed very consistently slick and powerful in how they render pages, they are also very consistent in their security—more specifically, they run in a sandbox as all good browsers should. And while a sandbox protects your precious mobile device like a firewall (or a hazmat suit), it also prevents Web-based applications from taking advantage of many of the most important features of the device—from the camera to the telephone. Browsers just aren't allowed to take pictures and send them to someone without your intervention (which, if you think about it, is probably a good thing).

And that's when you start delving into the world of native programming, and the language question quickly becomes murkier. Actually, it's not really all that hard to point you at the languages; it's just that there are no one-size-fits-all answers. But at least we can finally get down to the topic of this section and ultimately of the article itself. What are the programming language options for developing mobile application? It depends on the device, and here are your choices:

• Android devices—Pretty much all use Java as their native programming language.
• The Apply family of iThings—These require Objective-C.
• BlackBerries—Older ones use C++; newer ones support Java.
• Windows phones—This is the most quirky environment. Options range from VB.NET to C++ to C#. There's also the ongoing discussion about whether Windows 8 will completely change up the Windows development world as the new Metro UI can be implemented via pure HTML5, a .NET/XAML interface, or the more truly "native" XAML/C++ programming. It's all very confusing.

To Recap the Options

If you all you want is a simple sandboxed application, you don't have to learn anything other than HTML5 and JavaScript. If, on the other hand, you want to access the native capabilities of the phone, you're going to have to learn at least some programming in a native language for each of the platforms you're targeting. Since Android and iOS are the two primary device families (sorry, Microsoft, but the whole mobile thing just blew past you like Jacoby Jones against the Denver Broncos secondary), you're probably going to have to learn both Java and Objective-C. And unfortunately, the two languages don't have much in common except that they both came from the standard C syntax, which can be said about almost any popular programming language. OK, maybe not PHP. Or RPG. But you know what I mean.

One other issue with native applications: they cannot be delivered via the browser. Native applications generally need to be installed on the device, usually after being downloaded from some sort of store. While Android is developer-friendly in how it handles distribution, Apple really makes you jump through hoops. But however you look at it, when you go native, you'll need a way to deliver your software.

The third option is the hybrid application. A hybrid application helps you avoid the minefield of platform-specific UI choices. For example, the UI definition for Android is a bunch of platform-specific XML. Well, I guess the exact same thing could be said about Windows devices, just that it's a completely different XML dialect. With a hybrid application, you actually design your application as a standard Web-based application, but you deploy it within a native wrapper that in turn provides JavaScript APIs that let you access the native features of the phone. So, your UI is consistent because you design to the standard browser UI, but all the underlying messiness of native access is hidden from you. You trade the complexity of multiple development environments for the limitations of the browser interface, and because the application is fundamentally native, you still have to deal with the various delivery mechanisms (including all the misery that Apple puts you through).

Sorry About That Whole PHP Thing

And for those who have sidetracked down the PHP road, I'm sorry but basically that's a whole lot of wasted time in the mobile world. Any of the server-side scripting languages are next to useless when it comes to mobile devices. Whether it's one of the three Ps (PHP or Perl or Python), or the Microsoft bastion of ASP.NET, or my particular favorite scripting mechanism, JavaServer Pages (JSP), none of these makes sense any more in the brave new world of hybrid applications. Instead, you're going to be designing UIs that live on the mobile device and populate themselves via JSON calls to services on the host. Yes, you can probably write those services in PHP or JSP, but frankly, if you've got the same skill set I do, you're probably better off just doing it in RPG-CGI using something like CGIDEV2 or just writing your own RPG wrappers. Rather than designing and modifying UI scripts on the host, you're just going to parse JSON requests and send JSON data back. You might in rarer circumstances use XML or even SOAP as your transport protocol, but the point is that generating HTML on the server is a thing of the past, so all the scripting languages that support it are also headed out to pasture.

A Road Less Traveled (at Least for Now)

To close, let's not forget that there is and always has been a different route for addressing programming problems. The enablers of this alternate path have many names; sometimes we call them code generators or 4GLs or very high-level programming languages. Visual programming environments or "code by wire" or model-based generators, they all attempt the same basic concept: let developers work at a higher level and then generate all the fussy bits in between. These programming tools have existed for specific environments (like LANSA or AS/SET for the IBM midrange) but their real promise is in allowing the design of platform-independent applications that can then be targeted for specific platforms. IBM's Enterprise Generation Language (EGL) is one such development environment, but IBM has what may be an even more powerful tool in its arsenal for mobile development. If you have the time and inclination to do some research on an application-generation environment, I highly recommend that you look at IBM's new Worklight tool. Recently acquired from an Israeli firm, the Worklight tool allows the developer to visually design mobile applications, simulate them as they would appear in various mobile devices, and then generate the code to actually deploy the application. Worklight provides its own multi-platform native interface and common JavaScript APIs. You write your application in HTML5 and JavaScript and then tell Worklight which platforms to target. Worklight generates the platform-specific code and even packages your application for delivery (well, unless you're targeting the iThings, at which point you have to push the application over to a licensed Macintosh device for another expensive step that adds no value to anyone but Apple, but I digress). It's definitely an option that you should take a look at.

So hopefully I've provided you with a quick look at the landscape. There is no silver bullet; the language is entirely dictated by the device. If you need native access to the device, you need to learn to program it, unless you decide to embrace the hybrid model. Whatever you decide, mobile development is definitely not just an extension of your existing Web applications, even Web 2.0, so you probably want to take some time to assess your strategy before your end users start making your decisions for you.