10 ms·

Why apps are not the future

269 points by davewiner 15y ago

jgroome 15y ago
I don't think anyone outside of the app-development ecosphere seriously thinks that the Web is dead. It's a pretty absurd thing to say.
- k-mcgrady 15y ago
  I'm an app developer and I certainly don't think the web is dead. But I don't think apps are going to go away either. Both have their own use cases. And I think one of the biggest advantages of apps for developers has nothing to do with technology. It is the ecosystem. It is A LOT easier to make money with an app, sold through an app store, than it is to make money from a website. Especially on a mobile device where users don't want to type in lots of credit card information every time they visit a new website.
- randomdata 15y ago
  As a web developer, I think it is dying, but not in the way you immediately think. Modern websites are starting to resemble full-fledged applications. Built using entire MVC frameworks atop the Javascript runtime that abstract the underlying primitives, just like their native brethren. Today, from a programmer's standpoint, there is little difference between building a native and web application. Every new browser iteration just brings tighter integration into the underlying system. There are no real web-specific technologies being introduced. We are reaching the point where the web serves little purpose other than a clumsy virtual machine. The natural progression will be to go full on virtual machine, like Java attempted to do many years ago, where HTML/CSS/etc is just another application on that virtual machine. The idea of pointing a browser to an address to open an application will stick around, but I think the web parts, a program that renders interlinking hypertext documents, is dying – though certainly not dead yet.
  - bad_user 15y ago
    In the meantime Wikipedia is still the most useful product of the Internet and the biggest database of human knowledge. It's only surpassed in traffic by Google, Facebook, Youtube and Yahoo. the web serves little purpose other than a clumsy virtual machine That clumsy virtual machine can bring you Facebook.com on every mobile phone, regardless of the platform. And if good native apps are now available for Facebook, well, we are talking about Facebook.
    - deleted 15y ago
      [deleted]
    - dextorious 15y ago
      """In the meantime Wikipedia is still the most useful product of the Internet""" You missed the point. There's nothing Wikipedia does that cannot be done in an native-gui mobile App. It's just a list of articles, a way to search for them, and a system to edit them. Nothing web particular about Wikipedia, one can imagine a Wikipedia app for mobile and desktop OSs that achieves the exact same thing.
      - jgroome 15y ago
        But surely the success and therefore usefulness of Wikipedia is down to the fact that it's available to everyone with a web browser? Apps are only ever going to have a tiny proportion of the target market, compared to the number of general web users out there. That's what this is about. Of course you can do the same functionality that's made Wikipedia work in an app, but I don't think you'd ever get the numbers needed to make it useful.
        randomdata 15y ago
        In the model I was referring to, the browser doesn't go away. Only the built-in web does. Replaced by a more general virtual machine with reasonably low level access to the underlying system. We are, more and more, treating the web this way anyway. It is becoming a pointless abstraction. There is no particular reason for HTML, CSS, etc. to be built-in components, but that does not mean the web has to go away completely. If your network location wants to load an HTML document, you can command the browser to fetch an HTML renderer over the network. But you can just as easily serve an application of another kind, depending on your desires and needs.
king_magic 15y ago
"Visualize each of the apps they want you to use on your iPad or iPhone as a silo. A tall vertical building. It might feel very large on the inside, but nothing goes in or out that isn't well-controlled by the people who created the app. That sucks! The great thing about the web is linking." I'm not convinced. I see the "app" response to "linking" as being something like Windows 8 contracts. In fact, I wouldn't be surprised if iOS and Android have something similar to contracts in the next 2-3 years. At least I would hope so! I think that there are applications that make more sense to implement as a traditional app, and that there are applications that make more sense to implement as a web app. I don't see this changing anytime soon. I really don't.
- AndrewDucker 15y ago
  Well, Android has "Intents", which allow similar functionality, although not as much as "Contracts" if I understand correctly.
  - king_magic 15y ago
    I was actually not familiar with Intents. Good to know.
- deleted 15y ago
  [deleted]
  - king_magic 15y ago
    You got me. Microsoft totally copied this. Nevermind their history, stretching back 20+ years, of providing support for integrating one application with another. DDE? OLE? COM automation? Yeah, none of those things could possibly be considered precursors to something like contracts. But no. Microsoft totally ripped off Android here. eye-roll
    - Raphael 15y ago
      Android deserves credit for actually delivering. Microsoft has been banging away for 20 years and still hadn't arrived at the optimal solution.
thetrendycyborg 15y ago
You can link with apps. Intents do this. http://developer.android.com/reference/android/content/Intent.html http://developer.android.com/reference/android/content/Inten...
- k-mcgrady 15y ago
  To an extent you can do this on iOS as well with URL schemes.
- ch0wn 15y ago
  That's what I thought of. The model of Intents is also a lot more powerful than simple web links, but Web Intents[0] are already on their way to fix that. [0] http://webintents.org/ http://webintents.org/
dwiel 15y ago
I agree with the sentiment of the op, however, I dont think you can ignore the fact that so many people are willing to spend a dollar or two on an app whereas paying for access to a web site seems relatively rare (outside of the business world).
- deleted 15y ago
  [deleted]
- toyg 15y ago
  Show me a (useful) website that costs less than $5 for lifetime access. Many SAAS companies charge the same as an app, but per month, so you can't really compare it with a one-off payment.
  - rgbrgb 15y ago
    http://www.google.com/ http://www.google.com/
    - toyg 15y ago
      I don't understand whether you're trolling or not. Google doesn't make you pay for access, last I checked.
      - rgbrgb 15y ago
        >>> Show me a (useful) website that costs less than $5 for lifetime access. The business model is often completely different for the web. We pay with our eyeballs (ads) and our thoughts (click data).
        scrod 15y ago
        Nice. So that pretty much guarantees that only those SAAS apps that are operated by the largest corporations, and that harvest your personal data most efficiently, are the ones that dominate. Everything else is only that much more likely to disappear in an instant, taking with it not only all your documents, but the app's functionality itself as well. I really don't know what people like you are smoking.
djKianoosh 15y ago
I think one potential answer to this is the ability for mobile/tablet apps to embed a browser inside the app. So you see this already with the twitter app on the ipad, when you click a link, it opens a browser in-app. The app makers don't reaaaally want you to leave, so the in-app browser is a nice compromise for them. And as a user, I like it. I don't necessarily need/want to leave the twitter app on my ipad. I just want to read the linked content real quick and jump back to the app. Works for me :)
- hack_edu 15y ago
  Unfortunately, the browser experience can vary drastically depending on the app linking out. Plenty just dont at all. You see a link, but clicking doesn't do much but let you copy the text, if you're lucky to even have that. It's frustrating and makes me tend to avoid links in most all apps. Take Flipboard, and otherwise beautiful app that is the gold standard for future blockbuster apps; when you decide to open a link to a full article you will get stuck inside an awkward hardy-useful piece of Safari. Even if you click out, you efffectively lose your place in the flow of what you were browsing. This is an example of bad integration from the browser. Don't even get me started on the apps that come with built-in browsers that feel like a toynrather than a tool. I want to read the linked content not necessarily real quick and return back, and trust that the experience will be as good as a native app. In a perfect world all Apps would be web apps.
DrJokepu 15y ago
Regardless whether the author is right or wrong, "I don't care" is not a valid way to dismiss a counterargument. It's an effective way to resolve cognitive dissonance however.
davesims 15y ago
Linking is one of the things that I think Android got right over iOS. Google -- web company that they are -- smartly realized that their mobile OS platform needed to borrow metaphors from the web and attempted to do this with their Intent/Activity architecture. The challenge here is the execution -- it's Java-heavy and unwieldy compared to <a href=...>, but the basic structure is there and allows for interesting interleaving of Activities from one app into another. I haven't yet seen a lot of discussion or adoption of Open Intents, but I think it's an interesting approach. It does, again, seem to suffer from an inheritance of Java's heaviness, and that may be a fatal flaw. http://www.openintents.org/en/intentstable http://www.openintents.org/en/intentstable Whether this approach succeeds in sustaining rich-client apps as web apps mature remains to be seen, but I do think it points to the fact that OP's criticism was a concern in the minds of Android's developers at the earliest stages.
- themanr 15y ago
  Also possible on Android is for apps to register themselves as link targets for certain domains. For example http://www.github.com http://www.github.com addresses can optionally open in the github app.
  - babebridou 15y ago
    You can specify your app as a receiver for as many authorities as you'd like, by the way, or even register your own schema. You can also declare your app as a content provider, which means that your app/service becomes a data source, just as the contact list, or the photo repository, and make that data available to others, defining your own private permissions, etc. My app FairyPreview for instance (https://market.android.com/details?id=com.fairyteller.linkpreview https://market.android.com/details?id=com.fairyteller.linkpr...), is registered as an authority for the myriad link minimizers out there, so whenever you click on a minimized link in the Twitter app or anywhere apart from a browser, it will suggest my app for a faster preview instead of taking hours to load a webpage designed for a desktop browser hiding behind an unknown bit.ly link, itself disguised as a t.co, for example. It's not perfect and it's very old, the code is from 2009, my very first attempt at playing with the cross-app link system, but it works pretty well still. I'm strongly thinking about opening the source code, since I don't make any money out of it (free, no ad, maybe 50 downloads :P), and there's plenty of improvements I'd love to do but don't have the time these days.
scrrr 15y ago
I think apps are here to stay, but just like in the Chrome browser they might be simply links to a web-app. So the title should read "Why native apps are not the future".
clintavo 15y ago
We keep having the same debates over and over. We've seen this before on the desktop. It started with apps that had to be written for both Windows and Mac. Then the web came along and, as bandwidth increased, many apps were able to be run as web apps, simplifying code maintenance and giving developers the ability to easily target multiple platforms. Apps that benefit from linking work better as web apps. Some types of apps, however, run better as native apps: things like games and Photoshop. So we ended up with both. Mobile will follow the same track: we'll end up with both.
- wvenable 15y ago
  The reason why this conversation is coming up again is that so many applications that are web applications on the desktop are more commonly accessed as native apps on mobile. For example, on iOS I use a native client for IMDB, my bank, Mint, Wikipedia, and so on. But on the desktop I use web sites for these services. There has been a shift back to native on mobile. I agree that we'll end up with both but perhaps more importantly is that the difference between web and mobile will blur together even more.
  - politician 15y ago
    I think the real reason that you see apps on mobile devices is that an app puts an easy to use branded icon on the "desktop" instead of requiring the user to open a browser and navigate to the site. I don't think it has anything to do with lack of access to capabilities (e.g. Mint doesn't need access to my camera). Try this thought experiment: What do you think would be the reaction from users and developers if Apple simply renamed Safari's "Add link to home screen" option to "Install App"?
    - wvenable 15y ago
      I never said anything about "lack of access to capabilities". Native applications, in the vast majority of cases, are just better in every way than the similar web versions. They're faster, cleaner, and more capable. If both are being offered, it makes no sense to choose the web version. My company makes an iOS-compatible web application with no plans for a native client right now. We use some JavaScript[1] to remind users to add us to their homescreen. But if we had the resources, we would build a native client -- it's a no brainer. [1] http://cubiq.org/add-to-home-screen http://cubiq.org/add-to-home-screen
tgrass 15y ago
It is easy for me to imagine a world that moves from the messy chaos of the web to the clean, self-contained, predictability of the app, and linking would be a mere ancillary concern. Apps are the path of least resistance for the consumer.
mrich 15y ago
You gotta love IT. On Windows there was perfect integration between apps after Microsoft added linking and embedding using COM/OLE. 2D/3D hardware acceleration was standard. Linux as a competing OS implemented most of this also. Then came the web, and after years of standardization we now have hardware accelerated 2D & 3D, near-native performance (albeit using a completely new toolchain) and most of the standard desktop things. We have gained platform independence and ubiquity. Now we have to reinvent everything on mobile devices.... Granted, most of it is already there. But I sure would love to see most new mobile apps implemented in HTML5, to make them work cross device as much as possible.
- dextorious 15y ago
  I wouldn't call COM/OLE "perfect integration between apps" at all. And no, "2D/3D hardware acceleration" was not standard for the majority of Windows applications out there, including the Windows desktop.
  - davesims 15y ago
    "I wouldn't call COM/OLE "perfect integration between apps" at all." Oh come on, it was so simple! All you had to do was set up a ProgID and/or a GUID in the registry (no! not HKEY_LOCAL_MACHINE, silly!, HKEY_USER! Oh wait, you're right, it is HKLM...) and then implement IUnknown in your app and the register the interface when you installed your app...hopefully with Windows Installer, which makes all of this a simple 15-step process. There's only like, 25 different registry keys to keep track of and 12 layers of interfaces to implement. It was perfect I tell you!
IanDrake 15y ago
I think we've lost focus here. Web pages as apps are silly, but there are just things you can't do from a web page on a mobile phone, like interface with the camera, GPS, compass, local caching, etc... That's where apps come in (or should).
- jlongster 15y ago
  The only reason you can't do that from the web is because nobody's build the APIs yet. You can certainly do it from the web once they are available, and they are about to be: https://wiki.mozilla.org/WebAPI https://wiki.mozilla.org/WebAPI
- politician 15y ago
  PhoneGap exposes those features to JavaScript through Device APIs.
  - Spearchucker 15y ago
    Lol, was about to mention PhoneGap.
- rmc 15y ago
  you can't do from a web page on a mobile phone, like interface with the camera Not yet. GPS Geolocation: http://dev.w3.org/geo/api/spec-source.html http://dev.w3.org/geo/api/spec-source.html compass Slightly related, gyroscopes & device orientation http://slides.html5rocks.com/#slide-orientation http://slides.html5rocks.com/#slide-orientation local caching Loads of ways to locally cache things: http://slides.html5rocks.com/#offline-storage-title http://slides.html5rocks.com/#offline-storage-title 2½ out of 4. Not bad
- billions 15y ago
  A Qualcomm tech showed me a picture taken from the web browser in android. Said should be out in a year
- arethuza 15y ago
  You can use an application to enable web apps to get access to images from the iPhone camera: http://picupapp.com/ http://picupapp.com/
babarock 15y ago
Linking is really the only feature I care about in the web. And it's not a negligible one. I'm tired of all the Flash animations, the AJAX updates or other fade-ins and shiny effects. It looks pretty, but I'm not connecting to a website to watch a fashion show, I'm really here for the content. I wish we could go back to a more "HTML-only" oriented web. You still find some of those (usually with old Unix hackers or computer scientist) and they're amazingly enjoyable to read. Also, parsing them and running grep/sed/awk/... is a breeze. Am I crazy to ask for data I can manipulate easily?
mekoka 15y ago
I believe native and browser-based apps can and will coexist. As a web developer, I've had my share of frustrations with the browser and I certainly would welcome a more flexible and feature rich alternative for some use cases. To give an example, I can see native development overturn browser dominance in the manufacturing of Content Management Systems. For years these apps have been tied to browser technology and their usability and features have been limited because of it. Sure it makes them easy to deploy (all you need is a browser), but in exchange you get crappy wysiwygs, lack of remote access (ftp, ssh), image editing that sucks and a string of other annoyances that we've simply learn to accept out of convention. But when you think of it, there's no reason it should be like this. Organizations typically only have a handful of people that require access to the admin panel. You could simply have them install a native client that communicates with the server via http, exactly like the browser does, but offers a much more elaborate API. The added bonus would be the possibility to easily delegate various other tasks to other tools (Unix style). Other normal web users (consumers) can continue to access the frontend (as opposed to the admin panel) via browsers. This is a future I can definitely embrace.
- bad_user 15y ago
  I'm not sure I agree. Since I discovered Google Apps, I forgot about Microsoft Office. Google Docs is always there. It may be a crappy experience on my Android, but I have access to content I wouldn't otherwise. Collaborative editing and sharing is really easy too - I don't have to ask other people to buy iPhones / iPads / Androids to get them up to task. They only have to have an email on which I send an invite. And sure you can make a better native app and I would appreciate one on my Android, however I remember how this one time I forgot my phone and borrowed the iPhone of a friend to access a really important document. On the whole, web apps are more accessible. Native apps are a nice bonus to this experience, however if the core is not web-based, then it loses a lot of value.
  - dextorious 15y ago
    """On the whole, web apps are more accessible. Native apps are a nice bonus to this experience, however if the core is not web-based, then it loses a lot of value.""" Well, that can be easily solved with native apps that also have a web counterpart, for desperate times (i.e in the middle of Tahiti without your laptop/mobile phone/tablet).
thespace 15y ago
Very basic but there is a way in iOS http://iphonedevelopertips.com/cocoa/launching-your-own-application-via-a-custom-url-scheme.html http://iphonedevelopertips.com/cocoa/launching-your-own-appl...
roc 15y ago
Webapps need to better handle offline usage and poor network conditions. Until then, apps still have a huge leg up on mobile devices. Mobile devices are battery constrained. Radios to provide data feeds are a big factor in battery drain. Interpreted languages increase battery drain. And network coverage is far from universal, to say nothing of download caps and cell network performance concerns. Apps are preferred today because they're more responsive, they drain less power and they're generally usable offline and in dodgy network conditions. The web has many advantages over native applications, but until it gets better for mobile users, users are not going to get past the more-immediate shortcomings to care much about those advantages. And given that we seem to have reached a point where potential battery life past 1 day of solid use is traded off for greater performance during operation, I don't see the battery/network situation changing much any time soon.
- beatle 15y ago
  it's also a lot easier for developers to make money from native apps (free distribution, no infrastructure needed) vs. web applications (requires a lot of traffic, infrastructure, servers, bandwidth, system administration, etc.).
- zerostar07 15y ago
  By the same argument, though, apps will be obsoleted as soon as the next battery technology arrives, because, let's face it, installing apps, updating and uninstalling is a ghost long dead. As soon as Apis to access camera, microphone etc come to the browser, who would choose to program native?
  - bulte-rs 15y ago
    > installing apps, updating and uninstalling is a ghost long dead. So, when not installing native apps (which takes time) we add - in the case of e.g. the iphone - webapps (links) to our home screens. Which is faster than installing a native app. After that we 'endure' a longer loading time every time we start the app. And we still have to remove the icon from our home screen when we're done with it. Mind you, I see the advantages of web apps; but this does not seem like any different from the native app use case; it seems a bit worse to me actually. > who would choose to program native Performance junkies? graphically intensive app-developers (games?). Sure, we may have an 'opengl'-component to use in our webapps; but why the extra overhead?
billions 15y ago
Apps are shaping into Native, Hybrid, and HTML5. Native will always own a) 3D & graphics, and b) frequent users. HTML5 is in the immediate future shaping to be a 'try before you download' the app. It will be dominant in one time use (web) apps. I am working on an HTML5 marketplace- PM me if you're curious
jollyjerry 15y ago
A friend brought up a good point the other day that the popularity of the iOS app store has actually pushed back on advances in web technologies on mobile devices. Because the sanctioned way to sell applications must go through Apple, less attention overall has been spent building mobile webapps. Also, since the hardware is also out of developer's control, there hasn't been a push to make native hardware available to the javascript. Even with that, I do think that we're on the cusp of a big webapp revolution (again). With all these emerging JS frameworks (backbone, ember, derby, knockout, etc), and the modern and capable webkit powering so many mobile devices, developers will take note.
MatthewPhillips 15y ago
Linking is nice but the real killer feature is that installing, updating, and opening a website happen at the same time. Apple, Google, and Microsoft can build their own linking mechanism, but I have to preinstall the app before the link will work.
- Someone 15y ago
  Fixing that is not too hard. If you look at Mac OS X Lion, for instance, part of that already is in place (in a different domain). If you download a .xyz file and double-click it, the Finder will suggest looking for applications that can open .xyz files. I think a logical extension would be that the system would automatically download free viewer apps instead. Add a seamless way to upgrade to the editor app, and you are all set (tangentially related: I think a thing like OpenDoc using that infrastructure could succeed in today's market)
  - MatthewPhillips 15y ago
    Could they download and install these viewer apps in a fraction of a second or two, because thats what a browser does. The web works on the basis of progressive enhancement so all the browser needs to fetch is one Html file which it can display to the user while it downloads all other resources. I don't see a native code matching that.
    - Someone 15y ago
      "all the browser needs to fetch is one Html file which it can display to the user while it downloads all other resources." If only. There are pages where that is possible, but typically, at the very least, browsers need to download some css, too (for example, google.com, on my system, does 9 http requests of which one fails). Even with inline css, a browser can discover, halfway through a file, that some css moves a div up top, floats it, etc. Add to that 'not everybody' specifies image dimensions in the HTML and that Javascript that runs on page load may do DOM updates, and you get a much more complex model. Deciding when to start rendering a page is somewhat of a black art. If you wait until you are sure you have all information you need, the browser will appear slow; if you do not, you will have to restart page layout sometimes. "in a fraction of a second or two" Pages that load at that speed are rare. Again taking google.com as example, it loads almost 200kB here (most of it from cache, but that would not be much different in what I envision). When running from cache, rendering that simple page takes about half a second, I guess (FireBug reports 700ms and up, but it will have some overhead)
namank 15y ago
You know the people who make phone software are actually aware of this? In Android, the concept of Activity and Intent serves to essentially promote this. Its not a solved problem by far, but work HAS been done in that direction. Rest assured, this work is only going to speed up from here. After all, smartphones and tablets are marketed as consumption devices. The manufacturers would be hugely remiss if they didn't learn anything from the internet. And as we know, Steve Jobs and his industry descendants are anything but remiss. This is not to say the OP are wrong. Web doesn't compete with apps, it supports them. The two are complementary paradigms, not competing.
taylorbuley 15y ago
Deep linking is perfectly possible in apps. The !# hasbang is ugly, yes, but the HTML5 History API corrects this with the ability to pushState, replaceState and popState without necessarily having to deal with hashes. Moreover, this style of linking matters most with publicly available data. For private data, such as the stuff I'm working on storing in the browser with IndexedDB, having a public link isn't necessary for data that's not publicly available. I of course want to support browser history/links in full (see http://warpspire.com/experiments/history-api/ http://warpspire.com/experiments/history-api/ for an example of what's possible) but my point is that when apps are personalized there is not always a need for a link that can be shared across the web. If I wanted to prognosticate about our web-based future I'd look beyond vanilla hyperlinking and at Web Intents instead.
kiriappeee 15y ago
I think the problem is actually the way people are attempting to define an app the same way they tried to define a pc. The pc exists today and we are by no means in what many refer to as the post pc era. The form factor has changed but the pc remains. Similarly I think Dave has a point as to what is lacking in apps and assuming things like offline data storage get sorted along with better responsiveness and longer battery life, all that'll mean is that the form factor of the app has changed. Not that the app has lost and the web has won. I think web is simply the medium of delivery for an app like how the mobile OS is currently the medium for those apps to work in. Apps will remain the future. No matter how they change it'll still be the future. A more detailed writing on my blog in response to this : http://techstopmuse.blogspot.com/2011/12/apps-confusion-as-much-as-with-pc.html http://techstopmuse.blogspot.com/2011/12/apps-confusion-as-m...
richardburton 15y ago
Why does it have to be binary? Why does one school of thought have to lose in order for another to win?
Tichy 15y ago
Another thing I recently realized: if the trend is to store everything in the cloud. How long until we also store apps in the cloud? Oops, they are now web sites...
- tikhonj 15y ago
  Not just any websites, but websites locked down by Apple/Microsoft/whomever for your own good!
zeeed 15y ago
that's all well and good. the key is that you can sell an app easily given a unified interface. that beats everything that is being done on the web, hands down. We have to understand that apps make money and that this is why people will have people write more apps, which will fuel the economy and (us) entrepreneurs. That someone will switch off the web at some point is somewhat unlikely and when the time comes, probably secondary.
iradik 15y ago
Apps allow content provides to hide their data and only share it in a highly controlled environment. It's very unweb like, but appears that controlling a scare resource is profitable.
marknutter 15y ago
I can think of more reasons: - app discoverability sucks ass - apps require updates - app development is unnecessarily tedious and must be done x number of times for x platforms - iOS apps need to be approved by Apple, and you have to play the game by their rules if you want to charge money for them - apps lack basic features of browsers - no universal find, no back/forward buttons, no bookmarking of pages or states, no organizing apps into tabs, etc. Let's be honest: not counting games, the vast majority of the native apps out there would work just fine (or better) as websites. Add API's like access to the camera and there's even less reasons to develop a native app. Apps will be relegated to games and highly sophisticated interfaces, which if I had to guess probably represents around 10% of all the apps out there (heck, most of the games out there could probably be done in the browser).
sreitshamer 15y ago
He means iOS apps, not desktop apps, right? Desktop apps aren't "silos". The PC/Mac is a personal systems-integration device with mechanisms like pasteboards to transfer data between apps. Unfortunately iOS (so far) has very little of this.
Havoc 15y ago
>It pleases the money folk to think [...] That users are happy to live in a highly regulated, Disneyfied app space, without all that messy freedom. Sadly I think those folks are right. Shiny things do appeal to average people above freedom, flexibility etc. Given enough people with both money and an interest in shiny things, apps will rule supreme.
- dextorious 15y ago
  It's not like the flexibility to export you data in some format or the freedom to modify the code means anything to people --or like it should mean. How about the freedom from baby-sitting your OS install and the flexibility to just use a nice, polished app and go on with your REAL work?
solipsist 15y ago
Has it ever occurred to you that the next generation technology might harness the advantages of both apps and the web? That's the way innovation occurs. Incremental improvements. Referring back to past implementations. Standing on the shoulders of giants. Learning from both the good and the bad of technology. When people bring up the debate of Apps vs. Web, it's equivalent to saying "Facebook vs. Google+ - which one will people use in the future? You either get the Facebook like button or Google circles. One or the other, but not both."
- gambler 15y ago
  How exactly will it happen?
mufumbo 15y ago
The web will prevail. It's just question of time. Just be smart and make profit with the app fever while you can.
perfunctory 15y ago
> Why apps are not the future They are not the future indeed. They are the present.
tcarnell 15y ago
Yep, completely agree with the article. For me an important difference between the 'web' and 'apps' is that generally speaking nobody builds mobile apps out of generosity or egalitarianism, ie to give something to the world for free - mobile app developers are in it for the money. However, the openness and non-proprietary nature of the web seems to encourage people to be generous and share content and services. How many open source mobile apps are there compared to really great open source web/pc software?
charlieok 15y ago
The URI (or now more correctly, IRI) is a Web concept that is just as applicable in native apps as it is in HTML/Javascript apps. Use it.

269 points by davewiner 15y ago

I don't think anyone outside of the app-development ecosphere seriously thinks that the Web is dead. It's a pretty absurd thing to say.

k-mcgrady 15y ago
I'm an app developer and I certainly don't think the web is dead. But I don't think apps are going to go away either. Both have their own use cases. And I think one of the biggest advantages of apps for developers has nothing to do with technology. It is the ecosystem. It is A LOT easier to make money with an app, sold through an app store, than it is to make money from a website. Especially on a mobile device where users don't want to type in lots of credit card information every time they visit a new website.
randomdata 15y ago
As a web developer, I think it is dying, but not in the way you immediately think. Modern websites are starting to resemble full-fledged applications. Built using entire MVC frameworks atop the Javascript runtime that abstract the underlying primitives, just like their native brethren. Today, from a programmer's standpoint, there is little difference between building a native and web application. Every new browser iteration just brings tighter integration into the underlying system. There are no real web-specific technologies being introduced. We are reaching the point where the web serves little purpose other than a clumsy virtual machine. The natural progression will be to go full on virtual machine, like Java attempted to do many years ago, where HTML/CSS/etc is just another application on that virtual machine. The idea of pointing a browser to an address to open an application will stick around, but I think the web parts, a program that renders interlinking hypertext documents, is dying – though certainly not dead yet.
- bad_user 15y ago
  In the meantime Wikipedia is still the most useful product of the Internet and the biggest database of human knowledge. It's only surpassed in traffic by Google, Facebook, Youtube and Yahoo. the web serves little purpose other than a clumsy virtual machine That clumsy virtual machine can bring you Facebook.com on every mobile phone, regardless of the platform. And if good native apps are now available for Facebook, well, we are talking about Facebook.
  - deleted 15y ago
    [deleted]
  - dextorious 15y ago
    """In the meantime Wikipedia is still the most useful product of the Internet""" You missed the point. There's nothing Wikipedia does that cannot be done in an native-gui mobile App. It's just a list of articles, a way to search for them, and a system to edit them. Nothing web particular about Wikipedia, one can imagine a Wikipedia app for mobile and desktop OSs that achieves the exact same thing.
    - jgroome 15y ago
      But surely the success and therefore usefulness of Wikipedia is down to the fact that it's available to everyone with a web browser? Apps are only ever going to have a tiny proportion of the target market, compared to the number of general web users out there. That's what this is about. Of course you can do the same functionality that's made Wikipedia work in an app, but I don't think you'd ever get the numbers needed to make it useful.
      - randomdata 15y ago
        In the model I was referring to, the browser doesn't go away. Only the built-in web does. Replaced by a more general virtual machine with reasonably low level access to the underlying system. We are, more and more, treating the web this way anyway. It is becoming a pointless abstraction. There is no particular reason for HTML, CSS, etc. to be built-in components, but that does not mean the web has to go away completely. If your network location wants to load an HTML document, you can command the browser to fetch an HTML renderer over the network. But you can just as easily serve an application of another kind, depending on your desires and needs.

king_magic 15y ago

"Visualize each of the apps they want you to use on your iPad or iPhone as a silo. A tall vertical building. It might feel very large on the inside, but nothing goes in or out that isn't well-controlled by the people who created the app. That sucks! The great thing about the web is linking." I'm not convinced. I see the "app" response to "linking" as being something like Windows 8 contracts. In fact, I wouldn't be surprised if iOS and Android have something similar to contracts in the next 2-3 years. At least I would hope so! I think that there are applications that make more sense to implement as a traditional app, and that there are applications that make more sense to implement as a web app. I don't see this changing anytime soon. I really don't.

AndrewDucker 15y ago
Well, Android has "Intents", which allow similar functionality, although not as much as "Contracts" if I understand correctly.
- king_magic 15y ago
  I was actually not familiar with Intents. Good to know.
deleted 15y ago
[deleted]
- king_magic 15y ago
  You got me. Microsoft totally copied this. Nevermind their history, stretching back 20+ years, of providing support for integrating one application with another. DDE? OLE? COM automation? Yeah, none of those things could possibly be considered precursors to something like contracts. But no. Microsoft totally ripped off Android here. eye-roll
  - Raphael 15y ago
    Android deserves credit for actually delivering. Microsoft has been banging away for 20 years and still hadn't arrived at the optimal solution.

thetrendycyborg 15y ago

You can link with apps. Intents do this. http://developer.android.com/reference/android/content/Intent.html http://developer.android.com/reference/android/content/Inten...

k-mcgrady 15y ago
To an extent you can do this on iOS as well with URL schemes.
ch0wn 15y ago
That's what I thought of. The model of Intents is also a lot more powerful than simple web links, but Web Intents[0] are already on their way to fix that. [0] http://webintents.org/ http://webintents.org/

dwiel 15y ago

I agree with the sentiment of the op, however, I dont think you can ignore the fact that so many people are willing to spend a dollar or two on an app whereas paying for access to a web site seems relatively rare (outside of the business world).

deleted 15y ago
[deleted]
toyg 15y ago
Show me a (useful) website that costs less than $5 for lifetime access. Many SAAS companies charge the same as an app, but per month, so you can't really compare it with a one-off payment.
- rgbrgb 15y ago
  http://www.google.com/ http://www.google.com/
  - toyg 15y ago
    I don't understand whether you're trolling or not. Google doesn't make you pay for access, last I checked.
    - rgbrgb 15y ago
      >>> Show me a (useful) website that costs less than $5 for lifetime access. The business model is often completely different for the web. We pay with our eyeballs (ads) and our thoughts (click data).
      - scrod 15y ago
        Nice. So that pretty much guarantees that only those SAAS apps that are operated by the largest corporations, and that harvest your personal data most efficiently, are the ones that dominate. Everything else is only that much more likely to disappear in an instant, taking with it not only all your documents, but the app's functionality itself as well. I really don't know what people like you are smoking.

djKianoosh 15y ago

I think one potential answer to this is the ability for mobile/tablet apps to embed a browser inside the app. So you see this already with the twitter app on the ipad, when you click a link, it opens a browser in-app. The app makers don't reaaaally want you to leave, so the in-app browser is a nice compromise for them. And as a user, I like it. I don't necessarily need/want to leave the twitter app on my ipad. I just want to read the linked content real quick and jump back to the app. Works for me :)

hack_edu 15y ago
Unfortunately, the browser experience can vary drastically depending on the app linking out. Plenty just dont at all. You see a link, but clicking doesn't do much but let you copy the text, if you're lucky to even have that. It's frustrating and makes me tend to avoid links in most all apps. Take Flipboard, and otherwise beautiful app that is the gold standard for future blockbuster apps; when you decide to open a link to a full article you will get stuck inside an awkward hardy-useful piece of Safari. Even if you click out, you efffectively lose your place in the flow of what you were browsing. This is an example of bad integration from the browser. Don't even get me started on the apps that come with built-in browsers that feel like a toynrather than a tool. I want to read the linked content not necessarily real quick and return back, and trust that the experience will be as good as a native app. In a perfect world all Apps would be web apps.

DrJokepu 15y ago

Regardless whether the author is right or wrong, "I don't care" is not a valid way to dismiss a counterargument. It's an effective way to resolve cognitive dissonance however.

davesims 15y ago

Linking is one of the things that I think Android got right over iOS. Google -- web company that they are -- smartly realized that their mobile OS platform needed to borrow metaphors from the web and attempted to do this with their Intent/Activity architecture. The challenge here is the execution -- it's Java-heavy and unwieldy compared to <a href=...>, but the basic structure is there and allows for interesting interleaving of Activities from one app into another. I haven't yet seen a lot of discussion or adoption of Open Intents, but I think it's an interesting approach. It does, again, seem to suffer from an inheritance of Java's heaviness, and that may be a fatal flaw. http://www.openintents.org/en/intentstable http://www.openintents.org/en/intentstable Whether this approach succeeds in sustaining rich-client apps as web apps mature remains to be seen, but I do think it points to the fact that OP's criticism was a concern in the minds of Android's developers at the earliest stages.

themanr 15y ago
Also possible on Android is for apps to register themselves as link targets for certain domains. For example http://www.github.com http://www.github.com addresses can optionally open in the github app.
- babebridou 15y ago
  You can specify your app as a receiver for as many authorities as you'd like, by the way, or even register your own schema. You can also declare your app as a content provider, which means that your app/service becomes a data source, just as the contact list, or the photo repository, and make that data available to others, defining your own private permissions, etc. My app FairyPreview for instance (https://market.android.com/details?id=com.fairyteller.linkpreview https://market.android.com/details?id=com.fairyteller.linkpr...), is registered as an authority for the myriad link minimizers out there, so whenever you click on a minimized link in the Twitter app or anywhere apart from a browser, it will suggest my app for a faster preview instead of taking hours to load a webpage designed for a desktop browser hiding behind an unknown bit.ly link, itself disguised as a t.co, for example. It's not perfect and it's very old, the code is from 2009, my very first attempt at playing with the cross-app link system, but it works pretty well still. I'm strongly thinking about opening the source code, since I don't make any money out of it (free, no ad, maybe 50 downloads :P), and there's plenty of improvements I'd love to do but don't have the time these days.

scrrr 15y ago

I think apps are here to stay, but just like in the Chrome browser they might be simply links to a web-app. So the title should read "Why native apps are not the future".

clintavo 15y ago

We keep having the same debates over and over. We've seen this before on the desktop. It started with apps that had to be written for both Windows and Mac. Then the web came along and, as bandwidth increased, many apps were able to be run as web apps, simplifying code maintenance and giving developers the ability to easily target multiple platforms. Apps that benefit from linking work better as web apps. Some types of apps, however, run better as native apps: things like games and Photoshop. So we ended up with both. Mobile will follow the same track: we'll end up with both.

wvenable 15y ago
The reason why this conversation is coming up again is that so many applications that are web applications on the desktop are more commonly accessed as native apps on mobile. For example, on iOS I use a native client for IMDB, my bank, Mint, Wikipedia, and so on. But on the desktop I use web sites for these services. There has been a shift back to native on mobile. I agree that we'll end up with both but perhaps more importantly is that the difference between web and mobile will blur together even more.
- politician 15y ago
  I think the real reason that you see apps on mobile devices is that an app puts an easy to use branded icon on the "desktop" instead of requiring the user to open a browser and navigate to the site. I don't think it has anything to do with lack of access to capabilities (e.g. Mint doesn't need access to my camera). Try this thought experiment: What do you think would be the reaction from users and developers if Apple simply renamed Safari's "Add link to home screen" option to "Install App"?
  - wvenable 15y ago
    I never said anything about "lack of access to capabilities". Native applications, in the vast majority of cases, are just better in every way than the similar web versions. They're faster, cleaner, and more capable. If both are being offered, it makes no sense to choose the web version. My company makes an iOS-compatible web application with no plans for a native client right now. We use some JavaScript[1] to remind users to add us to their homescreen. But if we had the resources, we would build a native client -- it's a no brainer. [1] http://cubiq.org/add-to-home-screen http://cubiq.org/add-to-home-screen

tgrass 15y ago

It is easy for me to imagine a world that moves from the messy chaos of the web to the clean, self-contained, predictability of the app, and linking would be a mere ancillary concern. Apps are the path of least resistance for the consumer.

mrich 15y ago

You gotta love IT. On Windows there was perfect integration between apps after Microsoft added linking and embedding using COM/OLE. 2D/3D hardware acceleration was standard. Linux as a competing OS implemented most of this also. Then came the web, and after years of standardization we now have hardware accelerated 2D & 3D, near-native performance (albeit using a completely new toolchain) and most of the standard desktop things. We have gained platform independence and ubiquity. Now we have to reinvent everything on mobile devices.... Granted, most of it is already there. But I sure would love to see most new mobile apps implemented in HTML5, to make them work cross device as much as possible.

dextorious 15y ago
I wouldn't call COM/OLE "perfect integration between apps" at all. And no, "2D/3D hardware acceleration" was not standard for the majority of Windows applications out there, including the Windows desktop.
- davesims 15y ago
  "I wouldn't call COM/OLE "perfect integration between apps" at all." Oh come on, it was so simple! All you had to do was set up a ProgID and/or a GUID in the registry (no! not HKEY_LOCAL_MACHINE, silly!, HKEY_USER! Oh wait, you're right, it is HKLM...) and then implement IUnknown in your app and the register the interface when you installed your app...hopefully with Windows Installer, which makes all of this a simple 15-step process. There's only like, 25 different registry keys to keep track of and 12 layers of interfaces to implement. It was perfect I tell you!

IanDrake 15y ago

I think we've lost focus here. Web pages as apps are silly, but there are just things you can't do from a web page on a mobile phone, like interface with the camera, GPS, compass, local caching, etc... That's where apps come in (or should).

jlongster 15y ago
The only reason you can't do that from the web is because nobody's build the APIs yet. You can certainly do it from the web once they are available, and they are about to be: https://wiki.mozilla.org/WebAPI https://wiki.mozilla.org/WebAPI
politician 15y ago
PhoneGap exposes those features to JavaScript through Device APIs.
- Spearchucker 15y ago
  Lol, was about to mention PhoneGap.
rmc 15y ago
you can't do from a web page on a mobile phone, like interface with the camera Not yet. GPS Geolocation: http://dev.w3.org/geo/api/spec-source.html http://dev.w3.org/geo/api/spec-source.html compass Slightly related, gyroscopes & device orientation http://slides.html5rocks.com/#slide-orientation http://slides.html5rocks.com/#slide-orientation local caching Loads of ways to locally cache things: http://slides.html5rocks.com/#offline-storage-title http://slides.html5rocks.com/#offline-storage-title 2½ out of 4. Not bad
billions 15y ago
A Qualcomm tech showed me a picture taken from the web browser in android. Said should be out in a year
arethuza 15y ago
You can use an application to enable web apps to get access to images from the iPhone camera: http://picupapp.com/ http://picupapp.com/

babarock 15y ago

Linking is really the only feature I care about in the web. And it's not a negligible one. I'm tired of all the Flash animations, the AJAX updates or other fade-ins and shiny effects. It looks pretty, but I'm not connecting to a website to watch a fashion show, I'm really here for the content. I wish we could go back to a more "HTML-only" oriented web. You still find some of those (usually with old Unix hackers or computer scientist) and they're amazingly enjoyable to read. Also, parsing them and running grep/sed/awk/... is a breeze. Am I crazy to ask for data I can manipulate easily?

mekoka 15y ago

I believe native and browser-based apps can and will coexist. As a web developer, I've had my share of frustrations with the browser and I certainly would welcome a more flexible and feature rich alternative for some use cases. To give an example, I can see native development overturn browser dominance in the manufacturing of Content Management Systems. For years these apps have been tied to browser technology and their usability and features have been limited because of it. Sure it makes them easy to deploy (all you need is a browser), but in exchange you get crappy wysiwygs, lack of remote access (ftp, ssh), image editing that sucks and a string of other annoyances that we've simply learn to accept out of convention. But when you think of it, there's no reason it should be like this. Organizations typically only have a handful of people that require access to the admin panel. You could simply have them install a native client that communicates with the server via http, exactly like the browser does, but offers a much more elaborate API. The added bonus would be the possibility to easily delegate various other tasks to other tools (Unix style). Other normal web users (consumers) can continue to access the frontend (as opposed to the admin panel) via browsers. This is a future I can definitely embrace.

bad_user 15y ago
I'm not sure I agree. Since I discovered Google Apps, I forgot about Microsoft Office. Google Docs is always there. It may be a crappy experience on my Android, but I have access to content I wouldn't otherwise. Collaborative editing and sharing is really easy too - I don't have to ask other people to buy iPhones / iPads / Androids to get them up to task. They only have to have an email on which I send an invite. And sure you can make a better native app and I would appreciate one on my Android, however I remember how this one time I forgot my phone and borrowed the iPhone of a friend to access a really important document. On the whole, web apps are more accessible. Native apps are a nice bonus to this experience, however if the core is not web-based, then it loses a lot of value.
- dextorious 15y ago
  """On the whole, web apps are more accessible. Native apps are a nice bonus to this experience, however if the core is not web-based, then it loses a lot of value.""" Well, that can be easily solved with native apps that also have a web counterpart, for desperate times (i.e in the middle of Tahiti without your laptop/mobile phone/tablet).

thespace 15y ago

Very basic but there is a way in iOS http://iphonedevelopertips.com/cocoa/launching-your-own-application-via-a-custom-url-scheme.html http://iphonedevelopertips.com/cocoa/launching-your-own-appl...

roc 15y ago

Webapps need to better handle offline usage and poor network conditions. Until then, apps still have a huge leg up on mobile devices. Mobile devices are battery constrained. Radios to provide data feeds are a big factor in battery drain. Interpreted languages increase battery drain. And network coverage is far from universal, to say nothing of download caps and cell network performance concerns. Apps are preferred today because they're more responsive, they drain less power and they're generally usable offline and in dodgy network conditions. The web has many advantages over native applications, but until it gets better for mobile users, users are not going to get past the more-immediate shortcomings to care much about those advantages. And given that we seem to have reached a point where potential battery life past 1 day of solid use is traded off for greater performance during operation, I don't see the battery/network situation changing much any time soon.

beatle 15y ago
it's also a lot easier for developers to make money from native apps (free distribution, no infrastructure needed) vs. web applications (requires a lot of traffic, infrastructure, servers, bandwidth, system administration, etc.).
zerostar07 15y ago
By the same argument, though, apps will be obsoleted as soon as the next battery technology arrives, because, let's face it, installing apps, updating and uninstalling is a ghost long dead. As soon as Apis to access camera, microphone etc come to the browser, who would choose to program native?
- bulte-rs 15y ago
  > installing apps, updating and uninstalling is a ghost long dead. So, when not installing native apps (which takes time) we add - in the case of e.g. the iphone - webapps (links) to our home screens. Which is faster than installing a native app. After that we 'endure' a longer loading time every time we start the app. And we still have to remove the icon from our home screen when we're done with it. Mind you, I see the advantages of web apps; but this does not seem like any different from the native app use case; it seems a bit worse to me actually. > who would choose to program native Performance junkies? graphically intensive app-developers (games?). Sure, we may have an 'opengl'-component to use in our webapps; but why the extra overhead?

billions 15y ago

Apps are shaping into Native, Hybrid, and HTML5. Native will always own a) 3D & graphics, and b) frequent users. HTML5 is in the immediate future shaping to be a 'try before you download' the app. It will be dominant in one time use (web) apps. I am working on an HTML5 marketplace- PM me if you're curious

jollyjerry 15y ago

A friend brought up a good point the other day that the popularity of the iOS app store has actually pushed back on advances in web technologies on mobile devices. Because the sanctioned way to sell applications must go through Apple, less attention overall has been spent building mobile webapps. Also, since the hardware is also out of developer's control, there hasn't been a push to make native hardware available to the javascript. Even with that, I do think that we're on the cusp of a big webapp revolution (again). With all these emerging JS frameworks (backbone, ember, derby, knockout, etc), and the modern and capable webkit powering so many mobile devices, developers will take note.

MatthewPhillips 15y ago

Linking is nice but the real killer feature is that installing, updating, and opening a website happen at the same time. Apple, Google, and Microsoft can build their own linking mechanism, but I have to preinstall the app before the link will work.

Someone 15y ago
Fixing that is not too hard. If you look at Mac OS X Lion, for instance, part of that already is in place (in a different domain). If you download a .xyz file and double-click it, the Finder will suggest looking for applications that can open .xyz files. I think a logical extension would be that the system would automatically download free viewer apps instead. Add a seamless way to upgrade to the editor app, and you are all set (tangentially related: I think a thing like OpenDoc using that infrastructure could succeed in today's market)
- MatthewPhillips 15y ago
  Could they download and install these viewer apps in a fraction of a second or two, because thats what a browser does. The web works on the basis of progressive enhancement so all the browser needs to fetch is one Html file which it can display to the user while it downloads all other resources. I don't see a native code matching that.
  - Someone 15y ago
    "all the browser needs to fetch is one Html file which it can display to the user while it downloads all other resources." If only. There are pages where that is possible, but typically, at the very least, browsers need to download some css, too (for example, google.com, on my system, does 9 http requests of which one fails). Even with inline css, a browser can discover, halfway through a file, that some css moves a div up top, floats it, etc. Add to that 'not everybody' specifies image dimensions in the HTML and that Javascript that runs on page load may do DOM updates, and you get a much more complex model. Deciding when to start rendering a page is somewhat of a black art. If you wait until you are sure you have all information you need, the browser will appear slow; if you do not, you will have to restart page layout sometimes. "in a fraction of a second or two" Pages that load at that speed are rare. Again taking google.com as example, it loads almost 200kB here (most of it from cache, but that would not be much different in what I envision). When running from cache, rendering that simple page takes about half a second, I guess (FireBug reports 700ms and up, but it will have some overhead)

namank 15y ago

You know the people who make phone software are actually aware of this? In Android, the concept of Activity and Intent serves to essentially promote this. Its not a solved problem by far, but work HAS been done in that direction. Rest assured, this work is only going to speed up from here. After all, smartphones and tablets are marketed as consumption devices. The manufacturers would be hugely remiss if they didn't learn anything from the internet. And as we know, Steve Jobs and his industry descendants are anything but remiss. This is not to say the OP are wrong. Web doesn't compete with apps, it supports them. The two are complementary paradigms, not competing.

taylorbuley 15y ago

Deep linking is perfectly possible in apps. The !# hasbang is ugly, yes, but the HTML5 History API corrects this with the ability to pushState, replaceState and popState without necessarily having to deal with hashes. Moreover, this style of linking matters most with publicly available data. For private data, such as the stuff I'm working on storing in the browser with IndexedDB, having a public link isn't necessary for data that's not publicly available. I of course want to support browser history/links in full (see http://warpspire.com/experiments/history-api/ http://warpspire.com/experiments/history-api/ for an example of what's possible) but my point is that when apps are personalized there is not always a need for a link that can be shared across the web. If I wanted to prognosticate about our web-based future I'd look beyond vanilla hyperlinking and at Web Intents instead.

kiriappeee 15y ago

I think the problem is actually the way people are attempting to define an app the same way they tried to define a pc. The pc exists today and we are by no means in what many refer to as the post pc era. The form factor has changed but the pc remains. Similarly I think Dave has a point as to what is lacking in apps and assuming things like offline data storage get sorted along with better responsiveness and longer battery life, all that'll mean is that the form factor of the app has changed. Not that the app has lost and the web has won. I think web is simply the medium of delivery for an app like how the mobile OS is currently the medium for those apps to work in. Apps will remain the future. No matter how they change it'll still be the future. A more detailed writing on my blog in response to this : http://techstopmuse.blogspot.com/2011/12/apps-confusion-as-much-as-with-pc.html http://techstopmuse.blogspot.com/2011/12/apps-confusion-as-m...

richardburton 15y ago

Why does it have to be binary? Why does one school of thought have to lose in order for another to win?

Tichy 15y ago

Another thing I recently realized: if the trend is to store everything in the cloud. How long until we also store apps in the cloud? Oops, they are now web sites...

tikhonj 15y ago
Not just any websites, but websites locked down by Apple/Microsoft/whomever for your own good!

zeeed 15y ago

that's all well and good. the key is that you can sell an app easily given a unified interface. that beats everything that is being done on the web, hands down. We have to understand that apps make money and that this is why people will have people write more apps, which will fuel the economy and (us) entrepreneurs. That someone will switch off the web at some point is somewhat unlikely and when the time comes, probably secondary.

iradik 15y ago

Apps allow content provides to hide their data and only share it in a highly controlled environment. It's very unweb like, but appears that controlling a scare resource is profitable.

marknutter 15y ago

I can think of more reasons: - app discoverability sucks ass - apps require updates - app development is unnecessarily tedious and must be done x number of times for x platforms - iOS apps need to be approved by Apple, and you have to play the game by their rules if you want to charge money for them - apps lack basic features of browsers - no universal find, no back/forward buttons, no bookmarking of pages or states, no organizing apps into tabs, etc. Let's be honest: not counting games, the vast majority of the native apps out there would work just fine (or better) as websites. Add API's like access to the camera and there's even less reasons to develop a native app. Apps will be relegated to games and highly sophisticated interfaces, which if I had to guess probably represents around 10% of all the apps out there (heck, most of the games out there could probably be done in the browser).

sreitshamer 15y ago

He means iOS apps, not desktop apps, right? Desktop apps aren't "silos". The PC/Mac is a personal systems-integration device with mechanisms like pasteboards to transfer data between apps. Unfortunately iOS (so far) has very little of this.

Havoc 15y ago

>It pleases the money folk to think [...] That users are happy to live in a highly regulated, Disneyfied app space, without all that messy freedom. Sadly I think those folks are right. Shiny things do appeal to average people above freedom, flexibility etc. Given enough people with both money and an interest in shiny things, apps will rule supreme.

dextorious 15y ago
It's not like the flexibility to export you data in some format or the freedom to modify the code means anything to people --or like it should mean. How about the freedom from baby-sitting your OS install and the flexibility to just use a nice, polished app and go on with your REAL work?

solipsist 15y ago

Has it ever occurred to you that the next generation technology might harness the advantages of both apps and the web? That's the way innovation occurs. Incremental improvements. Referring back to past implementations. Standing on the shoulders of giants. Learning from both the good and the bad of technology. When people bring up the debate of Apps vs. Web, it's equivalent to saying "Facebook vs. Google+ - which one will people use in the future? You either get the Facebook like button or Google circles. One or the other, but not both."

gambler 15y ago
How exactly will it happen?

mufumbo 15y ago

The web will prevail. It's just question of time. Just be smart and make profit with the app fever while you can.

perfunctory 15y ago

> Why apps are not the future They are not the future indeed. They are the present.

tcarnell 15y ago

Yep, completely agree with the article. For me an important difference between the 'web' and 'apps' is that generally speaking nobody builds mobile apps out of generosity or egalitarianism, ie to give something to the world for free - mobile app developers are in it for the money. However, the openness and non-proprietary nature of the web seems to encourage people to be generous and share content and services. How many open source mobile apps are there compared to really great open source web/pc software?

charlieok 15y ago

The URI (or now more correctly, IRI) is a Web concept that is just as applicable in native apps as it is in HTML/Javascript apps. Use it.