The history of applications on mobile phones is rather interesting. When smartphones first became a hit, their Web browsers were not very good, and few sites worked well (if at all) on the form factor and capabilities of the phones. As a result, if you wanted an application on a smartphone, you wrote a native application for it.

The game changed with the arrival of the iPhone — mobile Web browsers are now good enough that making a mobile version (or view) of your site is a viable option. In addition, in the last several years, we have seen a large expansion in our options for consuming Web services, which has made it much easier to tap into the power of a service from a phone. With all of these choices, how do you know which mobile development approach fits your needs? Let’s take a look at the possibilities.

Note: This post originally appeared in TechRepublic’s Software Engineer blog.

Native applications

Native applications can make the maximum use of the local resources, and have the potential to look really great. Also, your native application can appear in the application store for that phone OS, which can provide some benefits (such as making it easier for people to find your application).

There are two big drawbacks to writing native applications: Your existing skills and knowledge may not carry over, and whatever skill set you do learn and code you write will be specific to that OS. Your initial thought might be, “Who cares? I’ll just target iOS or Android.” Well, that’s great, except that no mobile OS has a dominant market share like Windows does in the desktop market. By going the native application route, you will not get maximum exposure for your application, unless you want to rewrite the application for each platform that you wish to target. If you are writing games, this is almost always your best bet, due to having access to the sensors and such.

Mobile Web applications

Mobile Web applications are at the opposite end of the spectrum. With mobile Web applications, you can use your existing Web development knowledge, and learn the techniques to make it work well on mobile devices. Even better, you can reuse your existing Web applications if you have them already, and you can reach 100% of the smartphone market with a single codebase.

The biggest drawback to writing mobile Web applications is that, right now, mobile users are very in tune with the application store paradigm, so their discovery of mobile Web sites is still an issue. On the other hand, you can immediately use any loyalty existing users have and marketing campaigns that you may already be running. Other than that, you have the issue of Web applications not being able to take advantage of the local capabilities and resources (like the file storage, GPS, camera, etc.).

Cross-platform development tools

There are a number of cross-platform development tools designed to help you bridge the gap (Appcelerator is one example); these tools let you develop for their model, and then they create native applications for you. This can be a great approach, although you may need to learn an entirely new set of skills to work with the tool, depending on which one you pick. These tools can also do a great job at making your app look and feel right on each platform it supports, and they will provide access to the lowest-common-denominator of native functionality.

Some of these tools can be pricey, and you are tied into a third-party tool in a rapidly evolving marketplace. You should also keep in mind that these tools are cross platform, not every platform.

Native front end, Web service backend

Many developers are pushing as much of the processing logic as possible into a Web service backend, and then writing a minimal native UI for the user to access. This is a good approach for many applications because it allows the UI to be tailored to the expectations of a platform’s users, and it takes advantage of the application’s capabilities, while tying as little of the application as possible to a given platform’s native development systems. You still, however, need to do the native development.

Not all applications are well suited for this approach. For example, applications that need to transfer a lot of data back and forth will not do well. Also, you will need to build in provisions for offline usage, such as data syncing and message queuing, which are not trivial concerns. In addition, you need to consider how much of your logic can be pushed onto the service to justify this approach.

Summary

Before picking a mobile development approach, you will want to carefully analyze your application’s needs. While native apps currently rule the day, I think that mobile Web applications are your best bet for long-term success. If you need native access, I believe that the cross-platform development tools are well worth looking into. Right now, pure native applications seem like a long-term loser unless one mobile platform achieves total market domination.

J.Ja