I'm in the early stages of developing an application geared toward business use, but I'm unsure whether I should develop a web-based app or a native mobile app.

Developing a separate mobile app seems to mean more maintenance—any time a change goes through online, I'll have to make sure the update carries over to the app. But I know only native apps can utilize certain features such as GPS and digital rights management, and native apps don't require an Internet connection.

Top Answer: Go Native - Several Advantages (22 Votes)

Better control over the UI experience—the mobile web developer would either need to recreate or use frameworks that emulate native UI artifacts.

Access to platform APIs that might not be available to web apps—this is currently the biggest advantage for native apps.

Potentially lower network usage at runtime—the native app would only need to access the network for data, while the web app might need to completely load at run-time.

As you've noted, developers of native apps do have the disadvantage of building and maintaining apps for multiple platforms. This factor might not be a significant disadvantage if the developer is focused on only one platform.

Answer: Go Native - More Reasons (8 Votes)

Smartphones are different than PCs. Screen size and touchscreen make traditional webpages much more difficult to use on a smartphone. By creating an app for phones, a developer can can deliver a more user-friendly experience.

Native apps also allow for more thorough analytics on active users. This can help you better target advertising, if you choose to monetize in this way.

Trust is another benefit that comes along with developing a native app. Research shows people are extremely willing to download almost anything from an app store vs. downloading from the Internet.

If you have the resources, develop a native app.

Answer: Go Native - Go for Mind Share (4 Votes)

What almost every Internet company wants is for your mind to be tuned in to their product. And one way to build mind share is to make access to the content as easy as possible. How do the two delivery mechanisms compare? Let's use Facebook as an example:

Mobile Web Application:

User thinks: "I want to go to Facebook"

User clicks on "Internet"

User clicks address bar

User types "facebook.com"

Native App:

User looks at applications installed, and sees Facebook.

User clicks Facebook.

Not only is it easier for a user to use an app, but every time they look at their applications they will see Facebook just one click away. They don't even have to think "I want to go to Facebook."

That is how you build mind share.

Answer: Go Native - Make Money (3 Votes)

Many apps can be easily developed as websites, but it's harder to monetize that way. (To make sure your web-based app renders correctly in mobile, see here.)

A mobile app, on the other hand, can be sold through a trusted app store (Apple takes about 30%), or distributed for free loaded with a convenient mobile ad network such as iAds or AdWhirl (which, by the way, don't pay as much as web advertising).

I really like this feature, but am I the only one who finds it strange that the whole point is to highlight questions that are just barely (if at all) appropriate for Stack Exchange sites? http://stackoverflow.com/faq#dontask

(Assuming all stack exchange sites have a similar policy to stack overflow).

One of the biggest issues I have with web app development is that UI creation is essentially slight of hand. Devs have to use javascript and primitive HTML constructs to fake UI controls, UI effects and other interface elements that are basic components of a real OS API, and therefore enjoy highly predictable behavior and tight integration within that context. This means that there are thousands of additional, interesting ways in which basic functionality can "break" in a web app. An edge case as simple as a user clicking too rapidly on an HTML 5 "control" can unpredictably affect the timing and event handling functions in your web app, causing the whole interface to flop. Due to the variety of subtle differences in browser handling of scripts and HTML, there may very well be *no* general solution to a problem like this.

I really like this feature, but am I the only one who finds it strange that the whole point is to highlight questions that are just barely (if at all) appropriate for Stack Exchange sites? http://stackoverflow.com/faq#dontask

(Assuming all stack exchange sites have a similar policy to stack overflow).

A lot of the answers seem to mistake "web app" for "web site". A web app can take advantage of offline access, can become an icon on your screen and can be targeted at a device. The API and selling limitations seem the only relevant ones listed.

A wild thought from me is:A native app is (mostly) better since it's made for that specific OS... But a web one is (almost) always available for every OS and by that a larger user group... (at least if the app have different OS's users...)

I've seen some apps developed for one OS but not for another due to costs involved for what might be a to-small-to-be-profitable user base... So I would choose differently depending on what kind of app were talking about, what functionality is needed, how much money is available for development and how many (and what) users are targeted with said app. (A bunch of other reasons apply of course and I'm to lazy/dumb to list them since other more clever people already have)

For but for a business app I guess I would say native as a first hunch.

A lot of the answers seem to mistake "web app" for "web site". A web app can take advantage of offline access, can become an icon on your screen and can be targeted at a device. The API and selling limitations seem the only relevant ones listed.

It’s somewhat a throwback to before HTML5 was more widespread. Perpetuated because those other two categories of reasons loom LARGE, thus tend to convince most not to go there.

P.S. One reason to go with a web app (or at least provide a web app option) is if you are only going to interact very momentarily (and on few repeat occasions) with most users that comes your way. Seriously consider a web app for relatively low ratios of user interaction with your service/app compared to the of time to install a native app, fire it up, and find where you need to be for the reason you showed up to start with.

Or if your engineers just can’t quite figure out how to turn a web link to your site into instructions for your already installed native app, so when someone clicks on a link to your site the aren’t pestered to install your native app that they already have installed and then are unceremoniously left at that dead end with no way to figure out how to get to where the link was going. Not that these idiots in your employ are likely to do much of a job with a web app, either. *glares at Facebook*

How well does that work? Honestly curious. How robust/permanent is the local storage - I mean, is there any risk of it getting periodically cleaned out by the OS housekeeping, reboots, whatever?

Works great actually. We've implemented it. After being died in the wool MS VB/C++ developers our rewrite is JS/Jquery/JSON/PHP/HTML5/CSS3.

It's actually taking less time to develop also. We had taxes working in 5 lines of code. 5 lines. Think about it.

You want to see rapid UI and layout? Check out codecanvas.org. You want to see JS on the server check out node.js and meteor.org.

Web application programming is portable, it's extensible, it's more deployable, gives you easier maintenance, abstracts the desktop OS. As with anything there are requirements. We certainly aren't supporting IE. What is funny is our beta looks great in FF8/9/10/11, Chrome, Safari, and Opera 10 and 11. It's totally broken under IE8/9 and all we have done is write to standards. No tweaking to get it to work in the browsers that work.

The answers in this article reveal an appalling ignorance of the state of the art of mobile development using the web stack. Facebook, Linkedin and Twitter amongst others use web techs to develop their applications and they work just fine.

I work for Sencha and we have tons of examples of apps that run just fine packaged as native apps but built from scratch in HTML5+CSS3+JS. Check out Xero for iPhone for example.

I'm confused why ars is running such an advert for stackexchange sites, though I've like to see more from rpg.stackexchange.com that subjective fluff like this.

Still, I think a lot of "web is crap" answers are because the microsoft solutions don't provide a good enough experience. No websockets, no webgl, etc. I think it's a shame as there's conceptually little difference between xml-based XAML and xml-based HTML, both with code behind the ui elements - c# or js. Just separate the business logic from the ui and your golden, again something ms doesn't really encourage with their tooling.

I'm confused why ars is running such an advert for stackexchange sites, though I've like to see more from rpg.stackexchange.com that subjective fluff like this.

Still, I think a lot of "web is crap" answers are because the microsoft solutions don't provide a good enough experience. No websockets, no webgl, etc. I think it's a shame as there's conceptually little difference between xml-based XAML and xml-based HTML, both with code behind the ui elements - c# or js. Just separate the business logic from the ui and your golden, again something ms doesn't really encourage with their tooling.

Yeah, this article sucks. Someone has already mentioned HTML5 offline/local storage. You could also distribute your webapp in a native package containing a thin native wrapper to launch it within a web browser "control" you have tested it with (including cutting edge features like canvas, svg, etc). That would make porting your app between various platforms and the desktop much easier.

Writing a web application you are completely at the mercy of EVERY web browser. So, in essence you have even MORE testing to do because the web browser is really your operating system. Plus, web browsers are only now getting closer to the interactivity that native applications have had for years. Writing a native application user interface will render identically on a specific operating system. And, there have always been best practices for keeping the bulk of your code portable.

Having read Ars for a long time, I think these Ask Stack articles are pretty poor. In this situation, there is not enough information in the original question to justify *five* answers for going native... Without requirements, how can you uniformly endorse one choice over another? This is not good software engineering.

I suggest that a better approach for Ask Stack (if it's going to stay around), would be to re-post the question, and then write an *original* article that provides a framework for understanding the question itself, and the various answers from Stack Exchange...

In this case, something like:

Q: Should I go native or web?

A: Application development has changed dramatically with the introduction of robust web technologies.[HTML5, GWT, Pyjamas, Sencha, etc., etc., etc.]However, native application development tools have also expanded and improved...[Talk about iOS applications, or Windows 8, or Qt or whatever.]There are positive and negative aspects of developing a native application, or going "web"...[write about native upside][write about native downside][write about web upside][write about web downside]

I would expect a few questions to be answered in such an article -- what are the strengths and weaknesses? what are the current trends in new software? what does the future look like?

Facebook, Linkedin and Twitter amongst others use web techs to develop their applications and they work just fine.

That is exactly why none of those companies have apps available for iOS or Android, right?

If anyone read the answers, they would note there were more reasons to go native than because of problems using web technologies. User trust and adoption rates was one of them. You could expand on this by adding that it's an arms race among your competitors. If your biggest competitor has an iOS app available, you pretty much need to as well. That is not to be ignored, even though the reason is non-technical.

I am currently a web dev (using HTML5/CSS3/rich client apps/etc.) after nearly 20 years of being a native app dev, and I will say a few things:

1) The benefits of building web apps FAR outweigh the few remaining limitations. Especially as previously native-only API's get abstracted and exposed to the web -- thinking location/sensors, 3D, and so on -- the line of what you can and can't do in a web app vs. a native app is becoming very blurry indeed.2) Many of the "pain points" of developing web apps (Javascript sucks, everyone agrees -- RailsConf recently was a great example of just how much *web devs* hate Javascript, but hey, things like CoffeeScript take some of the pain out, and maybe something like Dart will solve the problem...) are really just native app developers complaining about an unfamiliar ecosystem. Get familiar with the technologies and toolsets available, get an understanding of what you GAIN from developing web apps, and you'll never want to go back to "write a million times, debug everywhere" (native coding).3) Here's the "it's just your opinion, man" (nods to Lebowski) part: web app development IS the model of the future. Die-hard native app developers can scoff and insult and fret and scream, but if you look at the trend lines, native blips like the AppStore are just that -- blips. Every single other trend is pointing towards OS-agnostic code, and right now, OS-agnostic coding means web dev.

Web applications may be OS agnostic, but are they browser agnostic? Because, the browser is now your OS. What many seem to forget is the testing effort. Now, if browsers eventually all work identically then the problem is solved.

I would not have a problem web applications if the technology stack would stabilize and the technologies could actually replace the current crop of native capabilities. Other items to consider are how to monetize web applications and how to let users continue to use the software once you decide to take down the servers that are required to support it.

"Web applications may be OS agnostic, but are they browser agnostic? Because, the browser is now your OS. What many seem to forget is the testing effort. Now, if browsers eventually all work identically then the problem is solved."

Of course, you have to test per-browser. This sucks, and it needs to be fixed (with stronger/better web standards, and consumer insistence upon browser compliance as a first-order concern).

That being said, compare the difference between testing on, say IE vs Firefox, to the difference between testing on, say Mac vs Windows. The first requires that you be aware of and compensate for the technical differences between the systems, but it is solvable. The second requires that you use a completely different toolchain and software ecosystem. Often times entire test methodologies have to change based upon which OS you use, whereas the same basic methods of testing will work across all browser, just with some diminishing number of "asterisks" you have to account for in the test results.

All software development is moving towards OS agnosticism, simply because the "average" consumer simply doesn't CARE about their OS; does the average iPhone user know that they're using iOS 4 vs 5, or Eclair vs ICS, or WinMo 6.5 vs 7 vs 8? Naw. They just want their APPS to work. Given how expensive platform lock-in is for everyone EXCEPT the platform makers, given how little consumers CARE about the platform, and given that every single shop and open source collective is working towards obfuscating the platform with e.g. facade API's, the trend is clear: locking yourself into native (ie, tied-to-one-platform) coding is a very poor long-term career strategy. It will be profitable for a while, simply because so few people are choosing to do it, and so talent is scarce (just like finding AS/400 specialists is scarce, these days). But eventually that "scarce but profitable" equation will tip with the industry into "obsolete," and those who haven't been riding the wave into OS-agnosticism will be in real trouble.

Facebook, Linkedin and Twitter amongst others use web techs to develop their applications and they work just fine.

That is exactly why none of those companies have apps available for iOS or Android, right?

Yes, they have apps, but they aren't native at all. Facebook's app is written entirely using HTML5 / CSS /Javascript. They write the same code once, and deploy it to all platforms using respective wrappers. I haven't used the Twitter or LinkedIn apps, but I assume the original poster was referring to them using the same technology.

Writing a web application you are completely at the mercy of EVERY web browser. So, in essence you have even MORE testing to do because the web browser is really your operating system. Plus, web browsers are only now getting closer to the interactivity that native applications have had for years. Writing a native application user interface will render identically on a specific operating system. And, there have always been best practices for keeping the bulk of your code portable.

100% inaccurate. Because if you are writing for EVERY browser you are a dolt. We write explicitly for Mozilla. Period. Now the fact that our current alpha works in Chrome, Opera, and Safari is a plus. The fact that it's totally broken in IE is just sad. It's sad because we are simply following HTML5 and CSS3 guidelines.

Writing a web application you are completely at the mercy of EVERY web browser. So, in essence you have even MORE testing to do because the web browser is really your operating system. Plus, web browsers are only now getting closer to the interactivity that native applications have had for years. Writing a native application user interface will render identically on a specific operating system. And, there have always been best practices for keeping the bulk of your code portable.

100% inaccurate. Because if you are writing for EVERY browser you are a dolt. We write explicitly for Mozilla. Period. Now the fact that our current alpha works in Chrome, Opera, and Safari is a plus. The fact that it's totally broken in IE is just sad. It's sad because we are simply following HTML5 and CSS3 guidelines.

Writing a web application for only one browser sounds an awful lot like a native application for only one OS.

Show me a web application that provides superior interactivity with a truely smooth response for the user.

Show me a native app that works the same across multiple OS's with the same codebase.

First, answer the request and then I'll answer yours.

The point is that neither readily exist for various reasons: both have tradeoffs to achieve their respective purposes.

Native apps do have access to OS resources, but can only be found on that one OS.Browser apps sacrifice native benefits but can be readily available on a larger scale across multiple OS's. To disregard either is ignorant. Each have their respective benefits and drawbacks.

I can argue I can build a web app faster than a native and have it more widely available and rev'd faster than a native app.

I could also argue that a native app might have more native features and a smoother interface.

Pick your poison based on your intended user base and the developers making it.

I will make this assertion: when browsers start granting more access to native libraries is when you'll see a monstrous change.

Show me a web application that provides superior interactivity with a truely smooth response for the user.

Show me a native app that works the same across multiple OS's with the same codebase.

First, answer the request and then I'll answer yours.

The point is that neither readily exist for various reasons: both have tradeoffs to achieve their respective purposes.

Native apps do have access to OS resources, but can only be found on that one OS.Browser apps sacrifice native benefits but can be readily available on a larger scale across multiple OS's. To disregard either is ignorant. Each have their respective benefits and drawbacks.

I can argue I can build a web app faster than a native and have it more widely available and rev'd faster than a native app.

I could also argue that a native app might have more native features and a smoother interface.

Pick your poison based on your intended user base and the developers making it.

I will make this assertion: when browsers start granting more access to native libraries is when you'll see a monstrous change.

I appreciate a well thought out response; thanks. These kinds of exchanges are what make development worthwhile. I respect developers willing to critically consider the pros and cons on both sides. +1

Nothing wrong with local applications, but they are harder for doing support such as for maintenance and updates. This is especially true if you have varying hardware platforms. (System admin for 10 years). With a web application, you have to make changes only once on a server (i.e. just one machine instead of many) There is nothing to keep someone from using a system as a private web server. Besides web based content is platform independent for the user of the web. http://www.instructables.com/id/Uses-fo ... ate-cloud/

Now that the touchpads are getting equivalent screen footprints as regular pc's, there is no need for special programming for them per se. Personally I love to take (open source code) from the web and and mold it to my needs (html5, javascript, and etc). (w3schools.com). I will either use the code locally or throw it on the server. Have browser, will compute.

Sourceforge.net and other sites all have a boatload of web server based programs, and in most cases you do not have to reinvent the wheel spending a lot of time building your own programs.