Why native apps are here to stay
mentalfaculty.com
mentalfaculty.com
The smart money is in making a web app for everyone first, perhaps not with all the bells and whistles, but sufficiently functional, and then making platform-specific apps.
Regarding "offering the same lowest common-denominator user experience on all devices"—know your audience. You don't have to make your app pixel-perfect for IE 6 if iOS users are all you're targetting. Web browsers "degrade" gracefully.
One of the features of web apps is that they can be anything—"the web is open". Mobile native apps are (often solely) available through app stores which are dictatorships, controlling when—and if—your app and its updates are released.
Regarding "camera flash control XHTML extensions", Mozilla's WebAPI[1] is trying to provide a standard API to interact with (namely) phones' software and hardware.
Many web apps haven't proven to be financially profitable except a well-publicized few,
The 1990s called. They want their metaphor back.
Let's face it: The "dictatorship" metaphor was fun (Remember the cartoons with the X-wing fighter torpedoing the AT&T Death Star logo? Good times.) but it was probably overwrought even back in the old days when DOS software and Mac software and each of the 23 different Unices were binary incompatible and emulation was dog slow and virtualization was like science fiction and choosing a platform felt like proposing marriage. But now? It might even be a dangerous line of thinking. You need to learn to think like your customer, and they don't see this oh-so-crucial distinction between "native apps" and "web apps". Except to the extent that web apps are a trifle more difficult to find: Instead of finding the pretty icon and touching it, you have to touch Safari and then type the name of your desired app into the Googles.
(No, of course the average customer doesn't know how to bookmark a URL. They don't know what a URL is.)
A defining characteristic of the metaphorical "dictatorship" is that people can't vote. In particular: They can't vote with their feet, because the wall is too high or the ocean too wide or the border guards (on whichever side of the border) are too expensive to bribe. But there are only two kinds of native-app platforms today:
A) The platforms in which a full-featured HTML5-compliant browser is at most two clicks away at any time;
B) The platforms that are being crushed to death by iOS, Android, and the other platforms in Category A.
Where's the big barrier here? Half of my native apps embed entire HTML5 web pages. Or they link out to HTML5 web pages. Meanwhile, an increasing quantity of web pages prompt me to install native apps. The answer to "web apps or native apps" is "both", to the degree that they interpenetrate and are inseparable, and what reason is there to believe that this won't continue?
Developers obviously care about their release schedules and their profit share and the backend technology underlying each and every screen on the phone, but customers don't know and they don't much care.
> Web apps are a trifle more difficult to find
That's pretty much my point—Apple want to control what you put on their devices. Remember when they were touting web apps[1]? Look at the page now. Most recent: 12/03/2010. iPhone 3Gs. They dropped that as soon as they realised they were harming their profits with the App Store.
Also, how do you reconcile the idea of an Apple who wants to maximise profits from the App Store with an Apple who limits what apps can be sold through that store? They're literally turning down paying customers in the App Store because they think it'll hurt their real business, selling devices.
There is no way to upload files on Mobile Safari. I'm told this has finally been implemented in Android 2.2. It's 20-frackin-11 and an App like Instagram is not even possible as a Web App.
App developers use Push Notifications to increase engagement with their App and notify users when something interesting happens. Ditto, for Local Notifications and Background Location. That's not even possible with Web Apps.
The new hotness in 2012 will probably be NFC. Web Apps probably won't have access to hardware data exchange for years.
And the list will keep going on. There will be new functionality in mobile phones released each year. Native Apps will get access to this functionality right away. Web Apps will have to wait for years to get access to this functionality.
Even current usages have issues. A few hours ago I decided I wanted to move a bunch of RSS feeds into Google Reader so I could prototype a new tool I'm working on.
So easy enough, create new Google Apps account, populate RSS feeds.
I'm not sure what was going on but my Google Apps admin console kept timing out. No idea what the problem was, my wifi, my ISP, international cable, some erroneous proxy, Google apps itself I dunno... maybe the bad/stormy weather outside... But it took me over 5 minutes to create a new user account.
Everything else seemed to be running fine so I thought it would correct itself. However after about 10-15 minutes of no improvement and very slow progress. I gave up trying to add RSS feeds (and put them into folders) via the web.
Annoyed at this point I downloaded an RSS client, added all the feeds I wanted, exported the OPML and uploaded it to google in around 10 minutes.
To do a simple chore I had to revert to a native client, and that is the reason why native apps are here to stay for me.
They are reliable and fast, ignoring other benefits. Web apps in a lot of use cases just aren't upto task.
Solve the monetization problem and I guarantee developers will look at web apps more seriously.
It's like the uncanny valley where humanoid things get so close to being fully realistic that the small difference in their behavior or look & feel causes people to be totally turned off. If it looks like a native app but doesn't quite behave like one, it's noticeable and (at least the people I've talked with) do not like it.
Maybe the HTML5 experience isn't good enough, but it truly sucks to have to write the app once for each platform.
I'd love to see the specific examples you're talking about; details like whether the apps were made by people with equivalent skills, and whether you're REALLY talking about the same app being judged better or worse.
Because it's so easy to write HTML5 and JavaScript, well, lots of idiots do it. If the study compares an app written by a median HTML5/JavaScript app developer with an app written by a median ObjectiveC developer, then it's not the environment you're actually comparing.
You can't get the best experience for each platform if the tools and frameworks you use are dumbed down to accommodate the lowest common shared experience across everything.
I agree that some UI changes are necessary between platforms as different as the PC, the Wii, and a touch-screen-based phone. But I very much disagree that you can't take advantage of solid cross-platform tools. I've written such tools, in fact.
Some native code to interface to native UI is necessary, but none of the native UI is really rocket science, and something offered natively on one phone can typically be done manually on another. Then it becomes an abstraction in the cross-platform library, and your code doesn't need to know how it's implemented.
But then again I'm a game developer, so I guess you've admitted that I could potentially already understand cross-platform development. ;)
I am planning on having a Web-app component to my next product, actually, and have been reading about them all; Dojo and jQuery Mobile are the two finalists I'm considering.
But the primary app is a game, and the production values for games make doing them entirely as web apps not an option.
Clunky scrolling would be a problem, sure, as well as choppy animations. I'll have to see what can be done when I actually dive in to writing the HTML5/CSS components.
The thing is, it's certainly POSSIBLE for web apps to animate better than they do. It may not be time for web apps to take over on phones, but it's only a matter of time. Processors in phones are getting more powerful, and the WebKit-based browsers are being optimized; scrolling animations really shouldn't be significantly slower done in JavaScript than they are in, e.g., Java on Android.
That's a nice theory. Here's the reality:
1) Client wants to build 4 native apps for Android, iPhone, iPad, Blackberry, WinMo7.
2) Client is in sticker shock that it will cost $100k+ to roll out
3) Client does a bit of googling, drawn like a deer in headlights to the Titanium showcase page
4) Client ditches native apps, goes the Titanium route because it's cheaper, doesn't realize that most of those are funded directly or indirectly by Titanium
5) Client fails to monetize application because users think it sucks.
6) Chalks it up to "the market isn't ready", repeat from step 1.
This story is roughly 75% of the mobile contracting market by volume, although for obvious reasons <1% in terms of app sales. It comes up a lot in enterprise mobile dev as well.
The moral of the story is that it's much easier to focus on the upfront development cost and ignore the unquantifiable murky cost of ending up with a bad product. It's the same thought process behind e.g. credit card debt--present pleasure for future pain is easy to rationalize.
Cute theory, but lots of good apps failed to get monetized as well, even when users like them (say 4.5 stars, and lots of great reviews?).
The failure can be in the promotion or marketing of apps at this point. There are too many apps out there for good apps to be discoverable without promotion.
Also, good and bad UI can be written in native and HTML/JavaScript. Some apps really don't need native to be good. It really depends on the app; the content and the UI design really trump fancy native-only effects.
1. They're generally not as fast as native web apps. At the very least they don't appear to be so.
2. A user/employee is more familiar with apps that are native and they will understand them better than a web app.
It is up to your customer to know what they're willing to sacrifice, immediate cash or the quality and recognition of their product in the long run.
You are patently wrong in your assessment and seem to miss some major aspects of the Titanium architecture.
Read this documentation: http://developer.appcelerator.com/apidoc/mobile/1.4/Titanium... and tell me how I should use custom fonts. I reported this issue in early July.
1. What problem am I trying to solve?
2. Which technology choice provides the best solution to the problem and the best UX? Which one does the user prefer?
3. Implement it.
That said, the author of this post is absolutely right in regards to the browser being a limited cross-platform solution available everywhere vs native apps being specialized solutions for a given platform.
Even developing the client side of a web app in HTML5, CSS3, JavaScript so that it's fast and it works in most browsers is still more complicated and tedious than anything you experience when building native applications.
There are two main advantages to web applications, though:
* A potentially larger audience (addressed in the post).
* The ease with which users accept to pay a recurring monthly fee. It can be emulated via in-app subscriptions, but let's face it, it's less common and/or accepted by users.
Come to think of it, the only correlation I can think of is that web applications are more prolific for online sales than desktop apps, which typically relied on a model of "buy me, install me, and you own me". My experience in the gaming world suggests that people are happy to pay for things within the desktop game interfaces, too. I have also read that iPhone apps with in-app sales (particularly for free apps) are greater than the initial app sales, and it is obvious that users have no problems making payments for things through their phone apps.
I assumed that "web app" refers to things that must be run through a web browser, as opposed to "app that can connect to the Internet", which will cover recurring subscriptions like Norton's latest virus updates and so forth.
"if you follow my TOS"
I just tried to make a multi-touch piano keyboard work in-browser using html5. The only thing that worked was the graphics, since that was a single image! The chances of playing a sound when the user presses a key in any kind of cross-browser way seems shot.
Html has been around for decades and its still not fit for purpose.
Unless of course he's totally supportive of using a hyperTEXT markup language to write applications, I don't know.
The thing I am realizing is both Apple and Microsoft have extremely unstable APIs that are driven by political or maybe stupidity purposes (some non-engineering reason), where perfectly good software just stops working because some bureaucrat at the Duopoly decided to nix something for arbitrary or foolish reasons.
But you can't do this with HTML apps, since it's not a monopoly, duopoly, or oligarchy, it's an actual competitive market for browsers. If your browser decides to stop supporting HTML4, it's broken and no one will use it.
This means you can write once for web apps and be confident it will continue to work forever.
That's a huge advantage and has changed the way I think about things. Now I am of the opinion that if there is any possible way to make something run in the browser, that is the preferred and superior choice. It's also instantly Mac/PC and Linux cross compatible too.
As we are reaching the point where the browser is a poor mans virtual machine and nothing more, why not just provide a virtual machine and let HTML be just another application on the virtual machine?
But then, that is only half the story. Apps that can use the power of deep access on front end, on top of a strong thing on the back end - those are the apps which are really making use of native story to build a more useful product than otherwise would have been possible.
The only conclusion I could draw is that this guy is an iOS developer who likes developing native apps. Fine with me, but he doesn't go anywhere from there.
We've tried making them work, but mobile browsers just aren't good enough yet to process the JS at a reasonable speed.
We have text editors IDEs, command line utilities, etc. not every application needs to interact with a network. More importantly, not every web aplication is some kind of fancy CRUD interface, we do a lot more with computers than managing our online presence.
Maybe I'm ignorant.. but how is this true? Apple could have NOT release the API for creating iPhone apps, and there wouldn't be any iPhone apps. You can crack, jailbreak, hack, and hax0r all you want. No API, no native app.
And there was an app store (well, a fully free store) before Apple even released their APIs. I don't know how people discovered the APIs (reverse-engineering ? Leaks from Apple ?), but they had them.
I still don't believe Apple "was pushed into it by the overwhelming strength of the jailbreak community". Apple must have had it planned, even before the SDK and the Appstore infrastructure was ready. The web app-only strategy was retarded; no one wanted that, and Apple knew it. Still, consumers would never accept the walled garden model if it was enforced after native apps were allowed. Web apps were only a surrogate until the Appstore was ready, but they couldn't market it like that, could they?
Anything that does not specifically require decentralization probably should be written as a web service.
One example is the Adobe Integrated Runtime, or AIR, which "... intends to provide a versatile runtime-environment that allows existing Flash, ActionScript, or HTML and JavaScript code to be used to construct Internet-based applications that have many of the characteristics of more traditional desktop-like programs." - http://en.wikipedia.org/wiki/Adobe_AIR
Another example of a hybrid option, one which is much simpler than AIR, and which I haven't seen anyone really trying, is where the application is sold without a GUI of its own. You interact with it through your browser, and it acts as your proxy to the Internet. This allows for increased computation, better display, and optimized communication, such that the experience is somewhere between pure web app and pure native app. The customer gets the good feeling of "owning" the thing for which they paid, and the developer's work is simplified by using the browser as a cross-platform GUI.