Cloud

Analysis of mobile development approaches

Which mobile development approach fits your needs? If you don't know, read this overview about the possibilities. Also find out which approach Justin James thinks is mobile developers' best bet for long-term success.

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

About

Justin James is the Lead Architect for Conigent.

14 comments
peterrogers
peterrogers

All this time using my Smartphone and I had no idea this was the case with the Applications. Thanks for sharing with me.

insuranceman1
insuranceman1

What's the financial factor for any of these options? I would think the price would be cheaper on app development because the market is super-saturated with app programmers, making it cheaper than mobile, etc.

bradleyj
bradleyj

Use the skills you have, build Mobile Web Apps with HTML, CSS and javascript. Package you mobile web apps into Native apps to have a app store presence while maintaining a single code base without any dependency on third party tools. Use HTML5 to store data for offline work, combine that with CSS3 to add a native look and feel. Better still use HTML5 and javascript libraries to add native style animations. I am planning to use CSS to modify my existing web apps to reconfigure themselves for screen resolution. This will enable me to use a single code base for all my deployments, mobile or standard browser.

pkesel
pkesel

I think your question is too simple. Your question seems to suggest that mobile is going to become the primary solution platform for business. That's certainly not the case now and I believe it won't be soon. That suggests to me that we should anticipate some significant tech and style breakthroughs on mobile. In that case, to speculate based on today's development technology is premature. If you're asking with respect to the current state of things, your question is still too simple. Is mobile my primary solution platform or does it augment my real business being carried out elsewhere? If the former, I may invest myself in multiple technologies to make my solution more sophisticated on more platforms. I'll write a iPad app and an Android app and a Blackberry app, and I'll do it with whatever is the best implementation technology on each. If the latter, I'll go with a common-ground technology because it's a secondary platform and I'm investing more heavily on my primary. I'll use a mobile web app and operate through a browser, relying on Dojo or other helpful mobile web libraries.

simon.scurfield
simon.scurfield

If Mobile Web applications are the future of development, what are the recommended development platforms? (i.e. ASP, Silverlight, Java, flash etc)

ajwecker
ajwecker

Google Web Toolkit An interesting option, which can make some great apps

Ralphi P.
Ralphi P.

You don't address costs - a majot factor - in this article. For example I was looking to create a mobile presence for my Restaurant and people kept telling me to go with apps. I did some research and found that an app would cost more that 15K! Instead I went with a mobile site for under $100 per year (http://Kishkee.com) and I can edit it when I need without having to pay a programmer ($75-150/hr). Big win for me!

Justin James
Justin James

... which of these approaches are you taking? J.Ja

Justin James
Justin James

Well, what phones support it? For WP7, there is native Silverlight which in the phone profile is very similar to .NET CF. Windows Mobile 6.5 is obsolete, that was the big .NET CF user. You can use MonoTouch for other platforms, but the future of Mono seems a little up in the air now that Novell has divested itself of that project. J.Ja

jck
jck

I hope you were getting a mobile HR interface for your management, timekeeping reporting for supervisors, and remote ordering for your kitchen staff. 100-200 hours of app development time is a lot for a "mobile presence", unless you expect to get a full suite of tools for your employees to use inside and outside the establishment. I'm glad you found a COTS solution to fulfill your needs.

gpapadopoulos
gpapadopoulos

Thanks J.Ja. But what about the Windows Compact Embedded 7? Doesn't this support the .NET CF? Or is it that it doesn't have support from device manufacturers yet? WP7(I own one actually) is for consumers or for business execs. What about apps in the retail market; for example, warehouse apps that use a device (that supports .NET CF, let's say WM6.5) equipped with a barcode scanner and such? Wouldn't a Windows Compact Embedded 7 device be the 'natural' upgrade path? I have been a .NET CF developer for years and I feel a bit alienated with the cutoff of WP7 backwards compatibility, although it seems that internaly WP7 still runs a version of .NET CF, v3.7 in particular.

Justin James
Justin James

When I use the phrase "mobile development" it specifically means smartphones and tablet devices such as the iPad. Specialized devices running an OS like Windows Embedded are another ball of wax entirely. Regarding the switch on WP7 to be Silverlight only, I agree. A lot of developers were pretty upset by it, especially since .NET CF supported things that Silverlight's Phone Profile doesn't. It's a lot harder to write internal, enterprise apps with SL than it was with CF directly. J.Ja

Editor's Picks