Apps are too much like 1990's CD-ROMs and not enough like the Web
hanselman.com
hanselman.com
- 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).
Discoverability sucks ass. Period. Unless you already have a strong network, or lots of advertising dollars, the chances of anyone finding your software, of any kind, is low.
"apps require updates"
While that is true of some implementations, there is no reason why apps cannot be downloaded on each execution. You could even use a URL bar to show the network location of the app, if you want to.
"app development is unnecessarily tedious"
A modern web application is no better in this regard. In fact, most of the recent frameworks that have sprung up to solve the problem of building web apps all seem to be loosely based on the same ideas from OpenStep that are used in popular native frameworks.
"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."
I mentioned it in an earlier discussion, but it seems worth repeating: The web browser is just another platform API. There is no reason why, say, CocoaTouch could not include those things by default for all apps too.
The whole web vs. native discussion is pretty silly because it all comes down to a few specific implementations that we keep pointing to, when anyone can change the state at either end of the spectrum on a whim.
Due to the web's open and standards-based nature, all you have to deal with is compatibility problems, which are resolved over time. I 'll take that over having to build for 6 different APIs, in 6 different languages in order to reach everyone's phones.
Minor? Keep in mind, it's not just per browser vendor. It's per version, per browser vendor. This is handled better today with the score of libraries you have to add in any web project but the problem is still there and will likely get worse before it gets better.
>That is the huge advantage of the web.
What? Objective-C is a standard. Cocoa is a known entity. So already I have one language and one API compared to three languages. If I include Android then I have two languages and two APIs vs three completely different and unrelated languages.
>PHP is just one backend, which really could be replaced by anything else.
Unless you replace it with JavaScript, that's yet another language I need to write and maintain. Not to mention, after all this effort I still can't consistently (if at all) provide an interface as nice as I can with an App.
> Are you telling me native apps don't need server backends?
Some do, not all. But of the ones that do, much of what you would need to do is just handled by the framework (e.g. storing data in the cloud, syncing, game serving and coordination, all handled by IOS SDK with no backend work on my part).
2) Learn a whole language and a whole api for one of the ~10 different mobile platforms vs 1 single language for every browser? That's a huge advantage. Seriously how much time you have to waste on learning different frameworks that do the same thing (display an app on a touch device)?
3) The backend problem is the same for both native and web apps; and PHP won't ever make your website snappier than an app because that's a browser problem.
"three completely different and unrelated languages."
What does that even mean? It's a stack of 3 complementary and orthogonal technologies that don't overlap. Don't you need to learn about layout and properties files when you do iOS development or android development or x development?
For me it all comes down to developer happiness, that is, achieve maximum effect in less time. That's why i m a webdev diehard and will never endeavor on proprietary closed frameworks.
Irrelevant. I need one language to describe the data, a completely different language to specify how to lay it out and a third completely different language to do any dynamic work (which is a lot these days). In e.g. iOS I can do all this with Objective-C.
>For me it all comes down to developer happiness, that is, achieve maximum effect in less time.
Agreed.
>That's why i m a webdev diehard and will never endeavor on proprietary closed frameworks.
That's why I'm not and hopefully will never have to be.
Not everyone has access to unlimited data plans or fast connections.
It would make it much slower to open an application each time. After all, vast majority of applications don't do this, so there must be a reason why.
1) it only downloaded a new version of the app when it changed (easy with ETags);
2) apps were lightweight (hard on current mobile platforms).
If platform vendors and application developers cared, it would be easy to make most applications weigh a few hundred kilobytes. We could then do exactly like what Web apps such as Twitter do natively.
Anyhow, I could come up with an equally harsh assessment of web apps as you did of native apps:
* web app discoverability sucks (seriously how much money is spent on SEO?)
* web apps constantly change on you or disappear when the shop is bought out
* web app development can be a multilayered nightmare of browser bugs and code shims
* you pretty much need to sell your soul to a bank or Paypal to sell anything on the web (let's see how Stripe works out long term before we declare victory there)
* many apps lack basic features like site-wide search, working back/forwards buttons, working bookmarking due to bad Ajax use, incoherent and inconsistent UI, etc.
Now, I happen to like web app development better than native app development, but I'm not a big fan of triumphalism in any of its stripes. Heck, the vast majority of websites out there would work just fine (or better) as paper brochures or a rolodex.
The web will continue changing and evolving and the browser will only be one of many ways that it will be consumed. Native apps will be integrated with web services more and more over time.
Apple has done a spectacular job of monetizing small apps, Google is building a good infrastructure for ad-sponsored apps, I wouldn't discount their long term potential.
I find the distinction to pretty blurry, myself. If you look at Cappuccino, you could practically search and replace a few tokens and have your code natively compile in Cocoa.
As web applications become more complex, proper separation of concerns, like MVC, starts to become important. Once you do that, as seen with Cappuccino and echoed in many other frameworks like SproutCore Backbone to name a couple more, the process starts to very closely resemble native development.
We now have the web browser playing double duty. We want it to be a hyperlink document viewer and we want it to be a platform for applications. Personally, I would like to see the browser be only a platform for applications and let the hyperlink document viewer be one of the many applications you can run in the browser.
seriously how much money is spent on SEO?
With that said, web apps go viral faster than anything else, that's because there's no barrier to entry. You don't have to be a member of the iPhone users club to try out links.
web app development can be a multilayered
nightmare of browser bugs and code shims
you pretty much need to sell your soul to a
bank or Paypal to sell anything on the web
If you're getting screwed by Paypal, you're only losing some money. However, if you're getting screwed by Apple, you lose your product and business model.
Compared to multi-platform development for OS X,
iOS, Android, Symbian, WinMo 6, WinMo 7, Windows 7,
Windows 8, Blackberry, Samsung Bada, Linux ; it's
heaven like.
Then there are libraries / frameworks that abstract all these platforms away or allow you to use a language that you're experienced in: MonoTouch, PhoneGap, Unity, etc.
Now, libraries don't fix all the problems and sometimes you will have to deal with the platform but they do take care of a whole lot.
Yea, free ones. I don't care as much about how many people are using the thing as I do how profitable it is.
I'll grant you that it's more effort today than it was with an App, but an App platform provides an easier method of discovery [1], an easy method for billing and even an advertising platform. With the web this is all on you and the web is more ad focused so you're probably more likely to be competing with free.
[1] Random chance with the user entering the right google keywords vs doing a category search in the app store and knowing you can see everything in that category.
- Web app discoverability is much worse
- Updates is a minor issue for users
- App development is not the user's concern
- App store approval is a net win for users. It eases their concerns about malware.
- Browser functions are not useful in most apps and the add an extra layer of abstraction
Native app can be made into just fine web apps but that is not always good enough. The best apps are still native.
This is especially one of the glaring holes with web apps in relation to their native counterparts. There just isn't a central destination for users to easily assess and access them. If web developers can come together and make this happen on a greater and more open scale than what the App Store, Chrome Store, or any other restricted app directory is currently offering, then the web has a chance at reengaging those native app users. Until then, the web is a jungle.
Discoverability is a big problem. The chrome web store is an example, it's interesting, but it's only built into chrome, and we had too many failed "Web directory" projects in the past anyway. There are other routes, like facebook viral apps, but these are also siloed.
The back button is useful to some apps, some of the time. Why should you show it all the time and confuse users? Native back buttons also allow you to show context; you can display information about where the back button takes you.
When web applications have only limited APIs, limited call rates, and changing everytime I can only think that I can turn on my Apple II and continue to use the same applications as 30 years ago.
Again, don't compare Google Spreadsheet with Microsoft Excel, look at the Microsoft balance sheet.
If you're interested I've written more rants about this on:
- The Data Portability Fact Sheet: http://blog.databigbang.com/the-data-portability-fact-sheet/
- Google Search NoAPI: http://blog.databigbang.com/google-search-no-api/
Plus, for the client-side of things view source is a lot easier than decompiling a binary.
You are only one case. Can you summarize all the application that you use everyday for work? are they native or web applications?
* Websites require connectivity
* Web development is unnecessarily tedious and requires coding in multiple half assed languages and targeting different browsers and platforms (and scale)
* Most websites don't make any money at all regardless of which rules you play by, but you're playing by google's unknowable rules at minimum
* Websites lack basic features of apps, such as offering complete control over the user experience (e.g. Not wasting screen real estate on web browser cruft)
* Let's be honest, including games every website could be implemented as an app.
I actually agree with your post in many ways, but all your points can be turned around without even being clever or disingenuous. I think some things (e.g. Magazines and most content apps) should be websites not apps. Other things should be apps. A few things should be both. Websites need to devise ways to work offline (which magazine apps do, but suck anyway).
Let's take a simple example: Ken Rockwell sells interactive camera manual apps for iOS devices. Could this be a web site? Sure, but not much use when you're hiking or caving or doing a shoot on a building site huh? Also much harder to monetize.
others are also problems on the web (eg discoverability and tedious development on x platforms).
camera apps
flashlight
calculators
document editors / todos
games
My iPad has 32GB of space (about 50 CD-ROMs), two cores each faster than any computer in the 1990s plenty of RAM, etc... It wants to be used like a thin client web browser thing. What a horrible waste.
A user knows where an app starts and ends and they know what icon they need to touch to get there.
Websites are far more ethereal and it isn't as clear when you've left one site and landed on another. And it's much harder remembering how to get there.
Case in point: how many people type 'facebook' into google and click the first link instead of entering 'www.facebook.com' into the address bar.
In all my infinite wisdom, I tried out a few apps from google chrome. And gave them permission to see what websites I view. Does anyone know if that goes away once I uninstall said app, or is there any extra mucking about and cookie removal I should take care of to make sure feedly isn't following me everywhere, even after it's uninstalled?
Once you uninstall a Chrome extension and close all tabs (since code could have been injected into them), there won't be any code related to it running on your machine.
It is still theoretically possible that while a Chrome extension was running that it updated state (via a cookie or otherwise) on webpages you were visiting, so perhaps clearing cookies could be helpful, but I'm not aware of this happening.
Frequent updates are often used to churn an app for visibility on iTunes for better discoverability. Thanks to this, apps are updated for very minor reasons, and most people don't give a crap about minor updates.
apps are still little islands of functionality that don't talk to each other
That's not entirely true. Apps are only islands if you make them that way. Many iOS apps talk to each other using URL protocol handlers as an interchange mechanism. I just bought TextExpander Touch, and it works with over 120 other apps. There's some Twitter clients that do something similar. No question that this would be even better with more support for it in the OS, but it works now.
I spent much of last year working on an HTML5 app. Maybe HTML5 will equal the app experience someday. But that day is not today.
The article also says the water level is rising -- which is true, but why assume native is standing still? On the contrary, I see native APIs evolving far more quickly because of the huge competition in mobile platforms. iOS has gone from 1.0 to 5.0 while HTML5 has been in gestation.
Native is a moving target, and HTML isn't catching up, let alone surpassing.
Because the App Store already has your card on file, they can do this with minimal friction. Same goes for Amazon.
However. This good sense is far from universal, yet. When I browse the web on my mobile device, I stumble across a lot of pages that look as if they've never been viewed on a mobile browser - or, worse, that seem to think I'm using a mobile browser from 2003. Many other sites still use Flash - it will probably be another five years before the last one of those gets the memo that Apple mailed four years ago. And even the sites that have a mobile design often use stock frameworks like OnSwipe, which I find to be an effective commercial for native apps or, for that matter, unstyled plain text.
In short, it's too early in the web's counterattack to deem it effective. For at least another year, that app icon is more valuable than a hyperlink, because it provides evidence that at least one programmer has spent at least five minutes looking at the app on a mobile device before signing off on it.
And that's a good thing. App developers have a much wider set of APIs to play with so they can do more while web app developers are stuck with whatever they had around 2005. There's been enormous progress on the back-end of web apps, but the browser side hasn't kept up.
The article complains mainly about two issues both of which are solved by the Android platform:
1) The keeping-applications-up-to-date problem has been addressed by the auto-update mechanism introduced by a market update for some time now. The apps are updated silently in the background without any user-interaction whatsoever. That's exactly what Chrome does for the web. If you keep Chrome open for decades then you web app will not upgrade either, at least not in the way you think it will.
2) The every-app-is-an-island problem is symptomatic of iOS since you are only allowed access as Apple sees fit. However, this is a solved problem on the Android platform through the use of Intents and the Back button which works as good as any web linking would.
Do you realize you're comparing a crippled, poorly-designed gadget with a distributed, massively networked system for browsing documents and information?
'Apps' do not work like 'the web' because they're not supposed to work that way. They're supposed to be static, stable, simple, reliable, offline, well-tested, usable. 'The web' is literally thrown together like so many ingredients in hobo chili. 'An app' is a Bonsai tree. Unfortunately, most people spend all their time tweaking the chili and spend absolutely no time pruning their bonsai. God, I hate making these comparisons.
I'm sorry for being angry, but it's getting sickening just reading the titles for weird articles like these that make no sense.
It's really tough to say what the clear winner is. There are advantages and disadvantages to both approaches. AFAIK, Apple has always bet the bank on the first approach and it's done well for them.
History would seem to suggest that the first approach provides a richer end user experience where as the latter provide ubiquity. I'm not sure which will win out in the long-run.
I still don't understand how discovery is any worse for native apps. On the web most people use search engines to find an app? App stores have search too. Plus, search engines usually find apps on app stores. If anything this makes discovery better for the native app.
This isn't limited to things that run on smartphones: Games that are installable are an easier sell than network games.
In some ways, they SHOULD be easier to pay for, as they have a chance of sticking around and at least partially working if the company goes belly up.
Just wondering, since those are the only languages I know, but aren't programming languages for writing native applications (like C++) harder than, say, JavaScript?
So in other words, the latest web technology will always be lagging behind. Yeah, that's pretty obvious.
But the sad thing is we're comparing two already horribly flawed systems. No one in their right mind should be arguing in terms of a locked-down, Disney-fied, compartmentalized experience versus a slow, infuriatingly clumsy and intermittently-available simulacrum of the same thing. We need to own our own devices and create, modify, and deploy our own software on our own terms. (And please don't insult my intelligence by claiming that the ability to browse to any given URL can constitute these freedoms in any materially useful way.) To publicly ask for anything less is so lacking in imagination and ambition as to be criminal; it serves only to reinforce the pathetic productivity-destroying dichotomy seemingly being forced upon us.