Why Native Apps are Here to Stay
Comment on the blog post.
Comments are currently closed for this discussion. You can start a new one.
Keyboard shortcuts
Generic
| ? | Show this help |
|---|---|
| ESC | Blurs the current field |
Comment Form
| r | Focus the comment reply box |
|---|---|
| ^ + ↩ | Submit the comment |
You can use Command ⌘ instead of Control ^ on Mac
1 Posted by Charles Parnot on 08 Sep, 2011 04:10 PM
Hi Drew,
Great post! It looks like one of his point was that the web content is there to stay because of the universal open nature of HTML. And indeed, it is nice that HTML is out here and offers a great, flexible and forward-compatible way of providing content.
But you rightly point out that the web content in only part of the story of what web apps are about. Accessing and displaying such content can be done via a web app or a native app, and native app are still ahead and will likely always have an advantage over a cross platform tool like 'the web'.
And then, independent of a web app or not, once the content is gone from the server, you are back to relying on local storage and backups of the data, if any is even available.
Coming from the other side, content created by native apps can be a silo, sure, and may only be local. But if it's your private personal content, the fact that it's local is not a bad thing. Then, the future is of course the cloud, so the issue of locality is less and less a problem. Finally, the issue of your content format is real, and being able to access it independent of the app can be problematic. But a lot of progress has been made, and between html, xml and sqlite, there are less and less threats of one's data being lost forever.
Charles
Support Staff 2 Posted by drewmccormack on 08 Sep, 2011 05:57 PM
Hi Charles,
I am certainly not against the browser or HTML. They play an important role. What I am against is the notion that they can and should play ALL roles. That is basically what was espoused.
Personally, I prefer the best user experience where possible, and until now that means native.
Some argue that the gap is closing. I've been hearing that in relation to all sorts of technologies over the years, and they never seem to catch up. That's because the problem isn't just a question of accessing the Address Book and other services on the device, as many are suggesting, it's that the HTML app doesn't feel like it belongs on the device. If you try to fake it, it's never quite right. And even if you could do it, you would have to do it on all platforms, and you might as well go native.
Drew
3 Posted by Bill on 09 Sep, 2011 03:47 PM
All one has to do is point to a few examples where native apps outshine their web app counterparts. Two I can think of off the top of my head are Facebook and Bank of America. Try accessing facebook.com or box.com via Safari on the iPhone and you get a far poorer experience than using the native app.
4 Posted by Charles Parnot on 09 Sep, 2011 07:47 PM
Totally agreed, and as you point out in the article, this is still the myth of a cross-platform development toolkit. Maybe the myth will come true one day, but still a long way IMO too.
Now, maybe I did not make myself clear, but all I said was in support of your post and was going in the same direction. My angle was to distinguish between the content and the container (the data and the code?), where of course, HTML is a nice format to have and happens to work out of the box in a browser, but then that's not the web. The web goes beyond HTML, and there you quickly hit many of the issues typically brought again native apps: things break (no update but new browsers), things disappear (server goes down), things change (web site is updated, older version not there anymore), things are hidden (server-side processing). And these issues are in a way worse on the web than with native apps, since at least with native apps, you inherently have local copies.
Bottom line is: there are arguments even beyond usability to be made against web apps, even for things that are typically thought to be strengths of web apps.
I prefer to see the web as just another platform, a very nice and powerful one, but with enough limitations and issues that one should not limit itself to it.
5 Posted by Josh on 10 Sep, 2011 08:10 PM
All of the initial arguments make sense actually.
Besides, when choosing to go cross-platform or native, the arguments shouldn't be just technical, but the business side is extremely important: the ROI with cross-platform is far better than with different native apps and the management of code bases is simpler and less expensive too. Single code-base, multiple platforms.
Choosing cross-platform has always been a good choice with these perspectives, even before the advent of web or of smartphones. It is unlikely that suddenly best practices change just because of a few technical arguments and I also believe that the difference in UX is minimal in any case.
Two other examples where the smarter decision has been taken: SalesForce and Google both have new mobile web apps. Facebook also recruited someone who built a web-technology based store.
Support Staff 6 Posted by drewmccormack on 10 Sep, 2011 08:37 PM
Hi Josh,
Web developers are often very quick to dismiss user experience, and 'go for the money' of a huge market. I am personally not interested in that, and would rather deliver the best user experience that I can.
Note that even web based giants like Google and Facebook acknowledge the importance of native user experiences, because they always deliver native apps alongside their 'fallback' web sites. And most people, given the choice, will use the native app.
I don't know if just developing for the web to 'cut costs' will really cut it with customers. If a competitor does offer a native solution in addition to their web site, you may have a problem.
Drew
7 Posted by Josh on 10 Sep, 2011 09:00 PM
I, on the other hand, am not dismissive of UX at all. If you read me carefully I wrote that the difference in UX between a native app and a mobile web app is minimal. In fact, in most business cases, the additional 'optimized' UX on a native app as compared to what can be done with a native app, is not even needed. Salesforce is a great example. Do you really think they'd decide to jeopardize their client base if there was no advantage to the cross-platform way?
The proposal of a cross platform mobile web app trumps that of a native app most of the time: the potential client knows he can access many platforms with a single code base and the cost-effectiveness is immediately obvious when explained properly.
Also, I wasn't talking about mobile versions of web sites at all, I was referring to mobile web apps. Not the same thing. You confuse the two.
Support Staff 8 Posted by drewmccormack on 10 Sep, 2011 09:12 PM
I'm afraid I have difficulty with the statement that a web app can provide a near-native experience, and think others would too. Even Jeremy Keith didn't go that far, resorting to the ever young 'it will catch up some day'.
When you don't recognize they web apps have an inferior user experience, I'm afraid you are already acknowledging that you don't understand the problem. There is not a single web app on the planet that has delivered such a good experience that I didn't think a native app would be better.
Good example: Amazon's cloud reader. I downloaded it on my iPad, and was willing to give it a chance. I was actually hoping that Amazon had managed to do better than their poor native app.
And it is quite an impressive web app. But I am already back on the crappy native app, because even a crap native app is better than a very good web app. Sad but true.
Drew
9 Posted by Anonymous on 10 Sep, 2011 09:53 PM
As a web app developer, I'm already seasoned to the challenge of distributing multiple flavors of my apps onto different platforms/vendors - CSS (believe it or not) is quite capable adapting presentation to rich or limited platforms/devices.
So, while you're writing Obj-C/Cocoa Touch for iOS customers, I am coding in JS/CSS that can run on any platform my customer wants depending on their situation - if they lose their iPhone 5 in a bar and replace it with an Android, that is Ok, they can still use my app. If they're traveling and only have access to an XP PC with IE6, I can still help them out (sacrificing some eye candy).
You might argue that UX or native 'feel' is more important than app portability, which is a fair call. At the end of the day, it depends on the app and the intended audience, but I'd like to think that I can create a relatively rich UX with the features offered by CSS3, including the ability to keep with a native look/feel (in the case of iOS anyway).
We're getting there, but I long for a world where devices only dictate the display size and hardware features available to the application, and it's the developer's repsonsibility to have the software adapt to suit the environment.
It's also worth looking at the rapid pace in which the capabilities of the web platform is developing. These APIs and features will eventually make it into the mobile platform (indeed a lot already have). It really is becoming a very rich toolset, but with a key differentiating factor from the native/vendor specific toolset in that the web toolset is backed by open standards and cross-vendor participation in the development of those standards -- essentially letting them put all their cards on the table in some kind of common respect for the interest of the consumer (which is important for the success of all vendors).
Like I mentioned, we're not there yet, but the gap is closing and I really do think the point is approaching that the end user will not know the difference (nor will they care) between a native or web app. The only difference they will care about is that they can experience the app on any platform they want/need to. Beyond that it comes down to developer preference: use a common toolset to develop for each platform, or use a different toolset for each platform.
I agree with the other comment that with the whole cloud movement, the way in which the face of the app is presented or delivered is independent of the service/API, however i would add that with the surge in server side JS (namely node) it makes even more developer sence to take advantage of the web as a complete platform (e.g shared model logic / JS between app and service).
I think it's worth pointing out what we can expect to see (or already have) from the web stack which will no doubt become available on mobile platforms. I've probably missed a few, but you get the idea:
Geolocation, device orientation, WebGL, local storage, indexedDB, connection status,
Anyway, apologies for the stream-of-dribble comment, but I think shouldn't discount the emergence of the web as a complete platform just yet.
Support Staff 10 Posted by drewmccormack on 10 Sep, 2011 10:04 PM
I really think you're underestimating how difficult it will be to completely fake a native experience. There are already many frameworks that attempt to do this, but I don't think anyone is fooled. That's because the web app is not native, it's an imitation, just like QT, SWT, and many other cross platform solutions that have come and gone.
That is not to say that web techs like JS are in any way worse, just that in most cases they are not native. WebOS is an example of a case where the native APIs were using web tech. The problem is really when you try to fake Obj-C/Cocoa or some other API with JS, HTML and friends.
Drew
11 Posted by Ionuț G. Stan on 10 Sep, 2011 10:55 PM
Here's a nice article from someone working for Mozilla that discovered how people in Taiwan are actually using the mobile web a lot: http://paulrouget.com/e/mobilewebapps/
Support Staff 12 Posted by drewmccormack on 11 Sep, 2011 07:52 AM
It's an interesting read, but it just confirms what I say: you can use the web if there is no alternative, but a native app nearly always delivers a better experience.
I should be very clear that I am not against the web or web apps. I see it as coexisting with native apps. Jeremy Keith has an entirely different agenda: to eradicate native apps, and good user experience with it.
Drew
13 Posted by Josh Nursing on 11 Sep, 2011 05:53 PM
in fact that should be 'nearly always delivers a nearly better performance'.
Not experience: it's ludicrous to claim UX is automatically dependent on UI
performance. For instance, somebody coding native could still give you a
crappy workflow and somebody coding a mobile web app (not web page, not web
app a *mobile* web app, don't confuse everything) could still give you
better workflow or functionality.
Try to list the cases where for a business, the minimal extra performance of
the native UI is absolutely necessary. Games perhaps?
Also even people who code native sometimes go out of their way for the
native app not to look like a default native app for branding purposes, so
mobile web app coders don't necessarily want to do that.
In short, there are few and dwindling instances where a business would
absolutely need the minimal extra performance of a native app, and most of
the time, the advantages of coding cross-platform mobile web apps trump
coding 2 or three different native apps with different teams and managing
different code-bases etc...
Salesforce, Google, DropBox didn't need native apps: explain why.
As mentioned above by somebody else, Javascript (or better, CoffeeScript)
will also be used to code server-side a lot in the future, so people who
know web technologies will be more efficient.
Finally, there is also a way to produce native apps even though you code in
mobile web technologies but I gather you never tried that and you never
tried coding a mobile web app (not a web page, not a web app, a mobile web
app).
If you really want to compare them, do so in a business environment, factor
in the costs and timeline for coding three native web apps and compare to
the costs and benefits of coding a single cross-platform mobile web app. But
for this, you'd have to know how to do so.
Support Staff 14 Posted by drewmccormack on 11 Sep, 2011 06:06 PM
I don't know about salesforce, but DropBox and Google make native apps for Android and iOS (at least), so I don't know where you get that.
It has nothing to do with performance. It is possible to write a native app in JS and other web tech, and WebOS is an example of that.
It has everything to do with the native look and feel you get when you use the native APIs, at no cost. You can try to fake it in a web app, and plenty do, but nobody is fooled.
In theory you could make a perfect copy of the native behavior, but it would be very difficult to do so. Whereas it is very easy to use the native APIs to make an app that feels like it belongs on the device.
So I also don't buy your business case. You can mess around trying to fake a good XP on each platform, but you are better off going native on the major platforms.
And even if it does cost a bit more to make native apps, I guarantee you will be much more likely to succeed in the marketplace. The few bucks you save on app development will simply result in poor adoption of your app. False economics.
Drew
15 Posted by Charles Parnot on 12 Sep, 2011 04:09 AM
Interesting you have DropBox in the list, since this is the perfect example of being successful thanks to a native app on each platform: Windows, Linux, Mac at first then also iOS and Android. What makes DropBox magic on a computer is how it magically works with your filesystem. This will never be possible with a web app (once the filesystem is dead, maybe).
16 Posted by bryan on 14 Sep, 2011 10:46 AM
besides the user experience, from a dev angle, there's also the fact that the functions are not all truly cross-platform.
i often mind myself having to write platform specific code (HTML/CSS or JS) for different features of an app because the API is either not supported or subtly different or the platform-side code (the "server" in this case) and has a nuance that requires a particular property to be set (or not). and this holds true wether I use a wrapping framework like PhoneGap with or without another framework like Sencha, Jo or jQueryMobile.
Now suddenly, in trying to just write one codebase, but I'm using several different frameworks (and I have to learn the way of each of those) while at the same time, I'm grossly aware that I chose this route at the expense of cutting out some "older" (yet, actually they not THAT old) phones. Boom!
It would have been simpler (read cheaper and easier) to write the native apps to begin with (in most cases).
It's just as messy and has a looong way to go. And while vendors compete with each other to differentiate, the frameworks try desperately hard to keep up and standardize.
I think it's a case for the best tool for the best job (once again) and HTML web apps will definitely not replace a native app but there's space for both, and knowing both should help.
17 Posted by Jan van den Ber... on 15 Sep, 2011 09:03 AM
I'm a web app developer myself. We've recently released our first HTML5 mobile app for iOS and Android using the PhoneGap and jQuery Mobile frameworks. I think the argument that the user experience is always better in a native app is simply not true. The UX possibilities of CSS3 outnumber any other existing presentational framework out there. Although I do agree that an inexperienced developer would more likely create a better looking app in a framework like Obj-C/Cocoa Touch then in HTML5.
The performance of native apps is better, but we found it negligible. Taken into account that mobile OS vendors keep increasing the JavaScript performance of their products, this gap will be closed very soon.
The remark that HTML, JavaScript en CSS are merely presentational technologies makes me think that you have no idea what HTML5 is all about.
18 Posted by Matt on 02 Oct, 2011 10:24 AM
Summer's nearly up. If Mental Case 2 were to be developed as a web app will it come a bit quicker ;-)?
Support Staff 19 Posted by drewmccormack on 02 Oct, 2011 12:18 PM
It's almost there. Few weeks to go.
To do what we have done on the web would be close to impossible ;)
Drew
20 Posted by Mackcesia on 30 Nov, 2011 11:04 AM
casino casino online online casino casino casinos online free pokies
drewmccormack closed this discussion on 30 Nov, 2011 04:04 PM.