5 ms·

What’s the Future? Native Apps or Mobile Web Apps?

29 points by JacobOscarson 15y ago

MatthewPhillips 15y ago
How does Readability (a web app) achieve the launch screen when run from the home screen on an iPad?
- joeminkie 15y ago
  <link rel="apple-touch-startup-image" href="/startup.png"> under "Specifying a Startup Image": https://developer.apple.com/library/safari/#documentation/AppleApplications/Reference/SafariWebContent/ConfiguringWebApplications/ConfiguringWebApplications.html https://developer.apple.com/library/safari/#documentation/Ap...
  - MatthewPhillips 15y ago
    awesome, thank you.
thomasfl 15y ago
Good read. There is way to many native mobile apps out there that could have been mobile web apps.
andrewflnr 15y ago
> Can you name one great application the last 10 years that wasn’t a web app or a game? Yes. Scrivener.
- deleted 15y ago
  [deleted]
- ezy 15y ago
  Or pick any of the content creation apps at all, really. Essentially, if your app is glorified advertising or a just a front-end to an online database, yeah, you can probably use the web. Otherwise, if there's more than just pretty, mostly static, graphics over the top of SQL, then you better go native otherwise your competitors will. I see articles like this all the time that talk about "their mom" not minding such and such. Really, they are just talking about setting the bar low enough to step over it. My parent used a shitty virus laden install of windows xp for years, and crashing was just part of the experience, like a sticky lock or a worn screwdriver. Do not use others expectations as an excuse -- surprise and delight people. (dammit :-))
- kenjackson 15y ago
  Chrome, Firefox, OneNote, Sharepoint, iTunes, Windows Media Center, Camtasia, VMWare, Git, Garage Band, Final Cut Pro, CS5+, True Crypt, Visual Studio 2010, ... The list can go on and on (although some might be slightly older than 10 years old).
  - JacobOscarson 15y ago
    Actually, most of these applications are more than 10 years old. And back-end systems, develompent tools and heavy duty media creation apps can hardly be compared to something that's a candidate for a web app.
    - wvenable 15y ago
      So as long as you exclude apps that are lousy as web applications then all new good apps are web applications? How pragmatic.
    - kenjackson 15y ago
      Had to look it up, and only three were older than 10 years old. VS (going back to the first version), VMWare, and Final Cut Pro). Chrome (2008) Firefox (2004) OneNote (2003) Sharepoint (2001) iTunes (2001) Windows Media Center (2002) Camtasia (2002) VMWare (1999) Git (2005) Garage Band (2004) Final Cut Pro (1998) Creative Suite (2003) True Crypt (2004) Visual Studio (1995)
- brimpa 15y ago
  TextMate
minalecs 15y ago
I think the biggest problem is that Apple has created the behavior of going to the appstore to find stuff, and until startups and developers stop going this route, or Apple really starts doing what they say, and promote HTML5 apps.. then the transition will be slow.
- ry0ohki 15y ago
  It's true, I've known a couple of startups who went the mobile web route only to continually hit the "I can't find your app in the store" support question. Using Phone Gap or a wrapped mobile web app in a native app mitigates this though.
Sakes 15y ago
I agree. There are too many road blocks for mobile apps to replace web apps. Until you can solve the data input problem on mobile devices, and massive content delivery limitations by screen size, web apps will still rule. When it comes to games, the computer vs. mobile device really isn't a fair comparison. They both solve different entertainment needs. One is an intense or shared experience need, the other is a casual time filler need. The concept of a portable gaming system is not new. Mobile games are just more accessible than previous systems.
glhaynes 15y ago
This doesn't address how to monetize a "mobile web app" - not a problem if you're just wrapping your marketing materials in a UIWebView like he recommends, but how do you make money off of a "real" app if it's "just a web page"? One-click purchasing through a store that already has your cc info is critical when we're talking about impulse <$5 purchases. Anyway, this is just patently untrue for many, many users: But you know what? My dad doesn’t care about the deceleration of a scroll and neither does yours. Not mentioning the “native experience” of my brother’s ZTE! Yeah, dad doesn't care about "scroll deceleration", but if the app feels clunky and unresponsive, they do care and won't come back. Again, it depends on whether we're talking about real apps that do something or just wrapped-up marketing pages.
rmason 15y ago
The vast majority of business applications don't need to be native apps. Once jquery mobile reaches version 1 lots of companies will be able to justify mobile versions of their websites that are stopped now by the price tag of creating a native application.
nikcub 15y ago
html5 will steadily wire up the missing features over the next few years with WebGL, device API workgroup[1], notifications api[2], video and audio tags etc. the problem is that vendors will have a conflict in implementing those features since they will compete with their native apps and app stores Apple and Google will need developer pressure to keep them honest, and hopefully give us access to the appstore upside of distribution while writing to just the html5 api [1] http://www.w3.org/2009/05/DeviceAPICharter http://www.w3.org/2009/05/DeviceAPICharter [2] https://groups.google.com/a/chromium.org/group/chromium-html5/browse_thread/thread/b5749c130b6a784c/5e90d4eb77a27e65 https://groups.google.com/a/chromium.org/group/chromium-html...
- voidfiles 15y ago
  The thing google, and apple need to protect is there distribution channel, not there platform. If you lock down your distribution platform you can charge 30% for recurring subscriptions. This incentivizes companies like Apple, and Google to not optimize the experience of packaging, and installing mobile apps over the air. They don't want to hobble there web experience though, as that is something many people do on their phones. Things like WebGL will make it into phones eventually, standards are just slow. Google has already started to implement the Device API in honeycomb.
- jbail 15y ago
  I think Apple and Google can protect their distribution channels and support mobile web as an equal to native. They can maintain the same approval processes, charge the same fees, and enforce submissions of your mobile apps to the same places if you want inclusion in their app stores. For mobile web, it could be as simple as compressing a folder of specially named HTML and JS files or providing an absolute URL where the main "executable" HTML file lives. In the end, Apple and Google can make the same amount of money from mobile apps vs native apps. I don't find many reasons they would care how the app is made (except that maybe they want "exclusive" apps that are only on one platform or the other --- or they want to not include absolute URL mobile web apps because you can submit an app and change it entirely the next day by changing the files on your server...though you could get around this by mandating that your app be submitted as packaged HTML/JS)
ThomPete 15y ago
Why do people need there to be only one winner? It's going to be both web and native. Performance matters and web simply aren't up to it for a long time to come. Even with WebGL etc.
- erikpukinskis 15y ago
  The article isn't about picking a winner, it's about what the current pros and cons are of choosing each as your platform for development. Understanding the tradeoffs is important because we don't have unlimited development resources.
ericflo 15y ago
Push notifications mean native apps win.
thomasilk 15y ago
It will take a long time till there will be no native apps anymore. As long as the choice remains between the browser experience and native apps, native apps will still have a chance. The moment the first OS finds a new and cooler more native style experience way to access the internet and website, Webservices will win.
ignifero 15y ago
Why doesn't HTML5 include support for camera input, accelerometer, compass & voice commands? How long before these are integrated?
- potatolicious 15y ago
  Because it will never end. Today it's camera, accelerometer, compass, and voice commands... tomorrow it'll be something else. Right now, since apps are predominantly native, a vendor can add new hardware and capabilities to their devices without the prior blessing of a standards body. Standards bodies will always be several years behind the state of the art in features, which means anything really compelling and new will always be in native form.
  - ignifero 15y ago
    Well, geolocation didn't take long to incorporate, hopefully the rest will follow.
    - potatolicious 15y ago
      Didn't take long to incorporate into the spec (even then, it's practically light speed by W3C standards, and a tortoise crawl by native standards)... but support in the wild is still pretty pathetic. As long as IE lives, web standards will move at a snail's pace. I'd say we're >5 years (probably more!) out from being able to, in general, expect something like geolocation to be supported in your average user. If you want to move faster than the competition and give more hardware/features to your users, you're still going native.
      - ignifero 15y ago
        it works decently on webkit browsers (and palm os i think, and nokia). The thing is there should be at least drafts for camera or voice support in webkit, simply because there is a need for it (Or else there wouldn't be projects like phonegap or titanium). With the proliferation of tablets and more and more mobile devices, going native will soon be a sisyphean task.
krosaen 15y ago
As a developer, I hope html5 apps end up being the norm, but one key difference between desktop apps and mobile apps is that you pretty much always have your phone with you. As a consumer, I love web apps because I can access them from anywhere and dont' need to have my computer with me. But if I always have my smart phone with me, what's my incentive to prefer a web app to a native one, especially one that syncs to the cloud?
deleted 15y ago
[deleted]
jarrett 15y ago
At the moment, it looks like the trend is towards fragmentation in mobile platforms. A lot of companies are jumping on the mobile bandwagon, and they're not all adopting Android. I don't know if this trend will continue, but even with the current level of fragmentation, developing web apps seems very attractive. Already, developing the same app for the iPhone, iPad, Android phones, and Android tablets is an expensive prospect. Appcelerator helps, but it's not a perfect solution, in part because it doesn't and probably never will support every platform. With HTML/CSS/JS, on the other hand, you get cross-platform compatibility for free. "But," you say, "not all mobile devices have good support for web technologies!" This is true, but I think we can expect that to change. Support for the web should constantly improve across all platforms over time. Since I prefer to invest in the technological long-run, I'll put my money on web apps except when native-only features are required. That way, instead of trying to port my app to an ever-increasing number of platforms, an ever-increasing number of platforms will--of their own accord--come to support my app.
wslh 15y ago
What's the future? i) Trains ii) Cars iii) Buses iv) Airplanes v) Subway vi) Trolleybus vii) Segway viii) Helicopters ix) Others I don't have an answer yet.
frankus 15y ago
Aaron Hillegass gave a great talk incorporating this topic at the Voices That Matter conference in Seattle a few weeks ago. He made a few assumptions about the type of project that a client might ask the "web or native" question about, where there is a certain amount of backend work, a certain amount of design work, and a certain amount of presentation-layer work, either native or HTML/CSS/JavaScript. The backend and design work scale identically for web and native apps as you move from "prototype" to "usable app" to "delightful experience". The client side work scales relatively linearly across this axis for native code, but tends to rise exponentially for a web app. He actually said that couldn't really think of any good examples of a "delightful experience" in a web app, particularly on mobile. He cited the example of one of the top web companies on the planet working for years to build what is arguably a worse word processor than the "hello world" example code included in most native platform SDKs. Another issue is that once you start really trying to nail the user experience on each platform, most of the cross-platform nature of a mobile web app goes away. Sure, you can use something like PastryKit to make a web app that acts just like a native iPhone app, but then you end up with a very un-Android-like app when using it on Android. Something like JQuery Mobile is a great way to get a usable product to market on multiple platforms quickly, but ultimately not everything that could be just a web app should be just a web app.
jmitcheson 15y ago
cough Phone Gap cough AppCellerator cough
drdaeman 15y ago
Either author has narrow definition of what "app" is, or he forgot a lot of apps. I could remember CPU-intensive applications (for example, number crunching of all sorts), cryptographic applications, OS-integrated applications (VPN, network filesystems of all sorts, process monitoring, and whatever else needs to be integrated with OS), all sorts of plugins and so on.

29 points by JacobOscarson 15y ago

MatthewPhillips 15y ago

How does Readability (a web app) achieve the launch screen when run from the home screen on an iPad?

joeminkie 15y ago
<link rel="apple-touch-startup-image" href="/startup.png"> under "Specifying a Startup Image": https://developer.apple.com/library/safari/#documentation/AppleApplications/Reference/SafariWebContent/ConfiguringWebApplications/ConfiguringWebApplications.html https://developer.apple.com/library/safari/#documentation/Ap...
- MatthewPhillips 15y ago
  awesome, thank you.

thomasfl 15y ago

Good read. There is way to many native mobile apps out there that could have been mobile web apps.

andrewflnr 15y ago

> Can you name one great application the last 10 years that wasn’t a web app or a game? Yes. Scrivener.

deleted 15y ago
[deleted]
ezy 15y ago
Or pick any of the content creation apps at all, really. Essentially, if your app is glorified advertising or a just a front-end to an online database, yeah, you can probably use the web. Otherwise, if there's more than just pretty, mostly static, graphics over the top of SQL, then you better go native otherwise your competitors will. I see articles like this all the time that talk about "their mom" not minding such and such. Really, they are just talking about setting the bar low enough to step over it. My parent used a shitty virus laden install of windows xp for years, and crashing was just part of the experience, like a sticky lock or a worn screwdriver. Do not use others expectations as an excuse -- surprise and delight people. (dammit :-))
kenjackson 15y ago
Chrome, Firefox, OneNote, Sharepoint, iTunes, Windows Media Center, Camtasia, VMWare, Git, Garage Band, Final Cut Pro, CS5+, True Crypt, Visual Studio 2010, ... The list can go on and on (although some might be slightly older than 10 years old).
- JacobOscarson 15y ago
  Actually, most of these applications are more than 10 years old. And back-end systems, develompent tools and heavy duty media creation apps can hardly be compared to something that's a candidate for a web app.
  - wvenable 15y ago
    So as long as you exclude apps that are lousy as web applications then all new good apps are web applications? How pragmatic.
  - kenjackson 15y ago
    Had to look it up, and only three were older than 10 years old. VS (going back to the first version), VMWare, and Final Cut Pro). Chrome (2008) Firefox (2004) OneNote (2003) Sharepoint (2001) iTunes (2001) Windows Media Center (2002) Camtasia (2002) VMWare (1999) Git (2005) Garage Band (2004) Final Cut Pro (1998) Creative Suite (2003) True Crypt (2004) Visual Studio (1995)
brimpa 15y ago
TextMate

minalecs 15y ago

I think the biggest problem is that Apple has created the behavior of going to the appstore to find stuff, and until startups and developers stop going this route, or Apple really starts doing what they say, and promote HTML5 apps.. then the transition will be slow.

ry0ohki 15y ago
It's true, I've known a couple of startups who went the mobile web route only to continually hit the "I can't find your app in the store" support question. Using Phone Gap or a wrapped mobile web app in a native app mitigates this though.

Sakes 15y ago

I agree. There are too many road blocks for mobile apps to replace web apps. Until you can solve the data input problem on mobile devices, and massive content delivery limitations by screen size, web apps will still rule. When it comes to games, the computer vs. mobile device really isn't a fair comparison. They both solve different entertainment needs. One is an intense or shared experience need, the other is a casual time filler need. The concept of a portable gaming system is not new. Mobile games are just more accessible than previous systems.

glhaynes 15y ago

This doesn't address how to monetize a "mobile web app" - not a problem if you're just wrapping your marketing materials in a UIWebView like he recommends, but how do you make money off of a "real" app if it's "just a web page"? One-click purchasing through a store that already has your cc info is critical when we're talking about impulse <$5 purchases. Anyway, this is just patently untrue for many, many users: But you know what? My dad doesn’t care about the deceleration of a scroll and neither does yours. Not mentioning the “native experience” of my brother’s ZTE! Yeah, dad doesn't care about "scroll deceleration", but if the app feels clunky and unresponsive, they do care and won't come back. Again, it depends on whether we're talking about real apps that do something or just wrapped-up marketing pages.

rmason 15y ago

The vast majority of business applications don't need to be native apps. Once jquery mobile reaches version 1 lots of companies will be able to justify mobile versions of their websites that are stopped now by the price tag of creating a native application.

nikcub 15y ago

html5 will steadily wire up the missing features over the next few years with WebGL, device API workgroup[1], notifications api[2], video and audio tags etc. the problem is that vendors will have a conflict in implementing those features since they will compete with their native apps and app stores Apple and Google will need developer pressure to keep them honest, and hopefully give us access to the appstore upside of distribution while writing to just the html5 api [1] http://www.w3.org/2009/05/DeviceAPICharter http://www.w3.org/2009/05/DeviceAPICharter [2] https://groups.google.com/a/chromium.org/group/chromium-html5/browse_thread/thread/b5749c130b6a784c/5e90d4eb77a27e65 https://groups.google.com/a/chromium.org/group/chromium-html...

voidfiles 15y ago
The thing google, and apple need to protect is there distribution channel, not there platform. If you lock down your distribution platform you can charge 30% for recurring subscriptions. This incentivizes companies like Apple, and Google to not optimize the experience of packaging, and installing mobile apps over the air. They don't want to hobble there web experience though, as that is something many people do on their phones. Things like WebGL will make it into phones eventually, standards are just slow. Google has already started to implement the Device API in honeycomb.
jbail 15y ago
I think Apple and Google can protect their distribution channels and support mobile web as an equal to native. They can maintain the same approval processes, charge the same fees, and enforce submissions of your mobile apps to the same places if you want inclusion in their app stores. For mobile web, it could be as simple as compressing a folder of specially named HTML and JS files or providing an absolute URL where the main "executable" HTML file lives. In the end, Apple and Google can make the same amount of money from mobile apps vs native apps. I don't find many reasons they would care how the app is made (except that maybe they want "exclusive" apps that are only on one platform or the other --- or they want to not include absolute URL mobile web apps because you can submit an app and change it entirely the next day by changing the files on your server...though you could get around this by mandating that your app be submitted as packaged HTML/JS)

ThomPete 15y ago

Why do people need there to be only one winner? It's going to be both web and native. Performance matters and web simply aren't up to it for a long time to come. Even with WebGL etc.

erikpukinskis 15y ago
The article isn't about picking a winner, it's about what the current pros and cons are of choosing each as your platform for development. Understanding the tradeoffs is important because we don't have unlimited development resources.

ericflo 15y ago

Push notifications mean native apps win.

thomasilk 15y ago

It will take a long time till there will be no native apps anymore. As long as the choice remains between the browser experience and native apps, native apps will still have a chance. The moment the first OS finds a new and cooler more native style experience way to access the internet and website, Webservices will win.

ignifero 15y ago

Why doesn't HTML5 include support for camera input, accelerometer, compass & voice commands? How long before these are integrated?

potatolicious 15y ago
Because it will never end. Today it's camera, accelerometer, compass, and voice commands... tomorrow it'll be something else. Right now, since apps are predominantly native, a vendor can add new hardware and capabilities to their devices without the prior blessing of a standards body. Standards bodies will always be several years behind the state of the art in features, which means anything really compelling and new will always be in native form.
- ignifero 15y ago
  Well, geolocation didn't take long to incorporate, hopefully the rest will follow.
  - potatolicious 15y ago
    Didn't take long to incorporate into the spec (even then, it's practically light speed by W3C standards, and a tortoise crawl by native standards)... but support in the wild is still pretty pathetic. As long as IE lives, web standards will move at a snail's pace. I'd say we're >5 years (probably more!) out from being able to, in general, expect something like geolocation to be supported in your average user. If you want to move faster than the competition and give more hardware/features to your users, you're still going native.
    - ignifero 15y ago
      it works decently on webkit browsers (and palm os i think, and nokia). The thing is there should be at least drafts for camera or voice support in webkit, simply because there is a need for it (Or else there wouldn't be projects like phonegap or titanium). With the proliferation of tablets and more and more mobile devices, going native will soon be a sisyphean task.

krosaen 15y ago

As a developer, I hope html5 apps end up being the norm, but one key difference between desktop apps and mobile apps is that you pretty much always have your phone with you. As a consumer, I love web apps because I can access them from anywhere and dont' need to have my computer with me. But if I always have my smart phone with me, what's my incentive to prefer a web app to a native one, especially one that syncs to the cloud?

deleted 15y ago

[deleted]

jarrett 15y ago

At the moment, it looks like the trend is towards fragmentation in mobile platforms. A lot of companies are jumping on the mobile bandwagon, and they're not all adopting Android. I don't know if this trend will continue, but even with the current level of fragmentation, developing web apps seems very attractive. Already, developing the same app for the iPhone, iPad, Android phones, and Android tablets is an expensive prospect. Appcelerator helps, but it's not a perfect solution, in part because it doesn't and probably never will support every platform. With HTML/CSS/JS, on the other hand, you get cross-platform compatibility for free. "But," you say, "not all mobile devices have good support for web technologies!" This is true, but I think we can expect that to change. Support for the web should constantly improve across all platforms over time. Since I prefer to invest in the technological long-run, I'll put my money on web apps except when native-only features are required. That way, instead of trying to port my app to an ever-increasing number of platforms, an ever-increasing number of platforms will--of their own accord--come to support my app.

wslh 15y ago

What's the future? i) Trains ii) Cars iii) Buses iv) Airplanes v) Subway vi) Trolleybus vii) Segway viii) Helicopters ix) Others I don't have an answer yet.

frankus 15y ago

Aaron Hillegass gave a great talk incorporating this topic at the Voices That Matter conference in Seattle a few weeks ago. He made a few assumptions about the type of project that a client might ask the "web or native" question about, where there is a certain amount of backend work, a certain amount of design work, and a certain amount of presentation-layer work, either native or HTML/CSS/JavaScript. The backend and design work scale identically for web and native apps as you move from "prototype" to "usable app" to "delightful experience". The client side work scales relatively linearly across this axis for native code, but tends to rise exponentially for a web app. He actually said that couldn't really think of any good examples of a "delightful experience" in a web app, particularly on mobile. He cited the example of one of the top web companies on the planet working for years to build what is arguably a worse word processor than the "hello world" example code included in most native platform SDKs. Another issue is that once you start really trying to nail the user experience on each platform, most of the cross-platform nature of a mobile web app goes away. Sure, you can use something like PastryKit to make a web app that acts just like a native iPhone app, but then you end up with a very un-Android-like app when using it on Android. Something like JQuery Mobile is a great way to get a usable product to market on multiple platforms quickly, but ultimately not everything that could be just a web app should be just a web app.

jmitcheson 15y ago

cough Phone Gap cough AppCellerator cough

drdaeman 15y ago

Either author has narrow definition of what "app" is, or he forgot a lot of apps. I could remember CPU-intensive applications (for example, number crunching of all sorts), cryptographic applications, OS-integrated applications (VPN, network filesystems of all sorts, process monitoring, and whatever else needs to be integrated with OS), all sorts of plugins and so on.