Constant Contact Labs Developer Blog
-
Mobile Apps - Native or Web? Posted Friday, March 5, 2010 4 Comments
There’s been a lot of debate on the web and in the blogs over mobile apps and which are better: native device-driven apps, or its counterpart, mobile web apps. I’ve always thought this to be a totally fair question, because they both offer real benefits to the user and sometimes serious drawbacks for developers. The truth is, although I believe they both have their own measurable benefits, I don’t believe there could ever truly be a real winner in this debate. The question is too subjective for a user, and for a developer, it ends up being completely requirements driven.
In this post I step away from a user’s perspective and focus on some of the decisions developers will have to make when determining which is right for their project. For developers, this decision should be driven by requirements, but for those occasions when you’re just not sure which is right, feel free to refer to the following analysis.
Technology
Most of us are already familiar with many of the web-based programming technologies. To be fair, HTML and JavaScript were never really envisioned for mobile devices. That is why it’s sometimes difficult to build engaging web apps for the latest smartphone device through a purely web-based experience. If you think about what can be accomplished with some of the newest smartphones i.e. iPhone and Android, you’d be hard pressed to achieve this functionality through a mobile web browser.
One bright note for the future of web-based apps is the introduction of HTML5. HTML5 tackles head-on some of the old limitations in building rich, powerful web apps. Some of the biggest limitations of rich media, such as video, audio, online advertising are largely addressed with HTML 5. Web forms are also addressed with HTML5, making for an exciting new version of the HTML markup language.
Unfortunately, this is just a drop in the bucket compared to some of the best features found in the latest iPhone and Android devices. For example, one of the newest breakthroughs in device-driven apps is Augmented Reality. Take Wikitude for example. This app calculates a users’ current position via GPS, uses the compass and accelerometer to determine which direction and position the user is facing, and through the device’s camera and Wikitudes’ large data set, draws details about the current landscape. Try doing that through a web app.
These device-specific native services cannot be reproduced in any web-browser. Well, at least not yet. So right now you might be thinking, “Well, there’s your winner right there! Native apps are the bomb!” Let’s not get too far ahead of ourselves. Some of the aforementioned technologies are highly OS-specific and run differently across the multitude of mobile devices. Furthermore, if your intention is to jump right in and develop a native app, remember that Android apps are Java-based (even still they require Google-specific libraries), whereas iPhone apps are developed in Objective-C. For the app to work across multiple devices, additional effort is required in numerous programming languages and development environments. This is not the case with web apps. Done right, one size can very well fit all.Portability
Programming language differences aside, there are also many UI quirks that run differently across devices. For example, Blackberry revolutionized the scrolling ball, but Android and iPhone both contain touch screens. The iPhone does not have a built in menu system, but Android, Blackberry, and the upcoming iPad all require some application-based menu options.
These minor differences may seem meaningless with respect to portability, but how will you port the functionality of your iPhone app (which doesn’t contain system menu options) to Android OS (which requires them)? Mobile web apps are starting to look a little bit more attractive right about now, aren’t they?
Well, not to add insult to injury, but this takes us back to the topic of programming languages. I’ve already explained how a Java-based Android app won’t work on an iPhone. In fact, Android apps won’t necessarily work on similar phones running Java at all because Android relies heavily on Google-developed Java libraries to control the Android device.
Functionality
You may now be on the other end of the spectrum, thinking to yourself, “What the heck is the benefit of a native app?” Well, all that sweet functionality for one. A native app has access to all of the cool features of some of the newest smartphones: GPS, device animations, local media, wireless networking APIs, cameras, compasses, offline access, accelerometers, super quick startup, and arguably the coolest of them all, multi-touch (pinch to zoom), just to name a few!
To be honest, with the exception of Augmented Reality, many apps really don’t have a need for all of these native services, but some of this stuff is really, really cool. These new device features have birthed some of the most creative and awesome apps that I could have ever imagined, and some of them admittedly couldn’t have been conceived through a web-browser experience.
Before you run off to take advantage of all this cool stuff, though, make sure to ask yourself if it’s really necessary for your app. Your requirements should always drive your decisions, not your excitement about the latest device features. To put this into perspective, if your app is a simple news feed, or an app to check on new signups to your newsletter, you really don’t need any of this sleek functionality afforded by native services — build a simple web app and move on. Remember, keep it simple, stupid.
Resources
6 months from now. when your iPhone app is hugely successful and you want to port it over to Android, Symbian and Blackberry, will you have the resources to do so? If your success depends on your app existing on multiple devices, you need to ask yourself if you have the resources to port it without hurting your existing successful app. Also consider that once your app is on multiple devices, you will have to maintain them all. Given the source code is native to the device, do you have the time and resources to fix bugs arising from multiple devices at once? This should be a serious consideration and one not to be taken lightly.
Content
Is the content dynamic? How does the content need to perform and behave? A lot of mobile devices still don’t have access to flash through the browser. HTML5 is making great strides to improve access to rich media, but it’s not quite there yet. Another landmine to be aware of is Blackberry’s lack of support for JavaScript out-of-the-box. It needs to be enabled. A typical user won’t know how to do this. There’s no way around this, for a solid rich media experience, native apps win hands down. Let’s see if this changes in the future.
Requirements
Sometimes you get lucky and your requirements make all of these decisions for you. Your requirements may be that the app needs to tap into some native services such as the camera, or your current GPS location. If that is the case, you have no choice in which direction to take.
The one thing to avoid is building a native app when the requirements don’t warrant it. This is a mistake that will come around to bite you later on. Stick to the KISS principle and your project will be better off for it.
Accessibility
Some familiar questions will be, “Does this app need to work offline” Face it: a web app will not work offline. Sure, HTML5 has introduced AppCache, which provides a great way to cache files on the users device, but true offline functionality can only be met with a native app. There might be a lot of disagreements with this assumption, AppCache is really close, but I don’t believe it’s there yet.
Another familiar one is, “Will my app work on this device?” As I mentioned before, the technology from device to device varies quite a bit, but so do some of the native services. This means if you want to port your iPhone app to Blackberry, and your app requires the compass to work, you might be out of luck. You won’t run into some of these issues with a web based app. Web apps have the added benefit that web browsers come pre-packaged into almost all of today’s best smartphones.
Side-by-Side
Below is a side-by-side comparison of the pros and cons of developing either a native or a web-based app. I’m sure you may have your own arguments as to which way to go, but feel free to use this as a starting point when thinking about what’s most important for your app.
Native Web Technology + Latest technologies allowing for advanced features - Requires advanced knowledge in many of the newest technologies + Familiar programming language - short learning curve - Limitations in the functionality that can be achieved Portability - Programming language and development environments vary widely across each device - many UI differences across devices + One size fits all - Form factor may not always be the same, requiring creative layout solutions Functionality + Native services pave the way for a new generation of mobile apps + All that sweet functionality + Data driven apps can be developed and deployed quickly - Lack of sweet functionality Resources - Need a lot more resources to develop apps for multiple devices - Tracking and fixing bugs on multiple devices will require a larger effort + Apps can be developed and deployed with minimal resources + Can track and fix bugs easily across multiple devices Content + Device can handle rich media + Native services support almost any dynamic functionality you can think of - Access to flash is limited, making it more difficult to build rich media apps - Lack of out-of-the-box JavaScript support on many devices Requirements n/a n/a Accessibility + Offline functionality works great - Some apps can’t be ported because the functionality isn’t supported on the desired device - Offline functionality is not quite there yet, although it is on the way! + Most devices come bundled with a web browser I suspect this debate will rage on for quite some time, and you may very well disagree with some of my assumptions. Feel free to challenge them and keep the debate going through the comments section below.
The opinions expressed here represent those of the author and not those of Constant Contact, Inc. Read Blog Terms
Comments
(4)
+comment on this post
Add your comment below
* Please be aware that all comments are moderated.
Popular blog posts
Recent comments
Join our mailing list
Kevin O'Brien | 11:33 AM March 8, 2010
Interesting post. One thing that I did not see mentioned however is access to commercialize the product. In today’s world of native apps, (and specifically the iPhone), the developers are beholden to Apple for marketing support, accessibility to customers, and future product support. In the web apps model, this concern goes away as Apple would produce the functions in their browser and a true marketplace for products can exist.
I hope we get to the point where mobile web apps are much more competitive with native apps.
Reneldy Senat | 2:30 PM March 8, 2010
Kevin, that’s a great point and although this is very much an iPhone specific constraint it’s yet another consideration that should be made when developing native apps. The iPhone does control nearly 20% of the smartphone market.
Google on the other hand takes a completely different approach and lets you host your Android Apps wherever you’d like - including their market place.
Reneldy Senat | 2:33 PM March 19, 2010
Just a quick thank you to Jerry Gulla and Jim Garretson for the following resources:
jQTouch — A jQuery plugin with native animations, automatic navigation, and themes for mobile WebKit browsers such as iPhone, Android, and webOS.
WebApp.Net — A UI framework based on JavaScript and CSS technologies. Helps you design seamlessly integrated web applications for mobile WebKit browsers such as iPhone, Android, and webOS.
These tools will help developers build Web apps that not only look but behave in much the same way as native device-driven mobile applications. This will go a long way in helping mobile web apps become a competitive solution for devices running Webkit engine.
Jim Ancona | 12:00 PM March 26, 2010
Another trade off is integration possibilities. For sites that don’t have good API support, integration in the browser may be the only option. And if part of your app has to be in the browser, putting all of it there is more attractive.