Hacker News new | past | comments | ask | show | jobs | submit login
App-pocalypse Now (codinghorror.com)
242 points by Evgeny on Feb 25, 2014 | hide | past | favorite | 188 comments



On the reason why people will spend $5 on a coffee but not $1 on an app:

I've been thinking about this for a while and noticed this behaviour amongst my friends. I have one friend who is a true apple fan-boy and finishes his phone contract early so he can get the latest iPhone earlier at much cost etc.

I recently finished an app and said - hey, do you mind downloading it for me and checking it out? He says, "but it costs £1?!" I said, "ok, no worries, I'll GIVE you the £1 right now"

He still said "No". Why? Because "he never spends money on apps." Weird, right?

Then last night I'm watching Horizon - "How we make decisions" [1], and they talked about how when we feel we are ahead we are much more cautious than when we feel we are behind, when we experience "loss aversion" and are more likely to take a gamble.

I wonder if this is the best way to monetize apps. So you offer the app for free (no risk at all), then instead of offering "add-ons", you offer to remove "restrictions", implying that the user is already behind and they should take the gamble to get back to their "free" app.

[1] http://www.telegraph.co.uk/culture/tvandradio/tv-and-radio-r...


Isn't it simple really.

With coffee (and food in general) I know what I going to get it's a craving I have right now, it's chemistry.

With an app I don't know what I am getting and I don't have that same need so my intellect needs to be persuaded which is a much harder thing to accomplish. It's psychology.


That's a good point, but not the whole story(at least for me).

I love my Kindle. I am very adverse to buying books on it, even though I would sometimes go hungry to buy physical books. It makes no sense, I know and acknowledge that it makes no sense, yet it is still part of my decision making process, and post-event evaluation process. Meaning - those books on my bookshelf that I may never read - no regret, they may come in handy. That ebook I bought and actually used - I still have nagging "did I blow $9.99 on that - I could have gotten by with googling and reading the docs".


Well there are reasons I am adverse to buying ebooks.

DRM - if I am going to buy it I want to actually feel like I own it.

portability - will I be able to read my books in the future?

sharing - when I get a good book I let all my friend borrow it and read it. I borrow friends books a LOT, in fact thats probably the main way I read books is just borrowing my friends' books or borrowing them from the library.

selling - when I am sick of looking at a book on the bookshelf that I probably won't pick up again I either sell it or donate it to the library. So many books have passed through my hands and very very few have stayed there.


And yet you still buy a coffee for 5USD no questions asked. Thats kind of the point :)


You can't just by one app, unless you link the iPhone to your credit card, which a lot of people do not want to do.


He had already done that, because he needed to buy a couple of very expensive music apps he "needs". I would agree if that was the case though. Should have said.

But usually he doesn't like to buy any apps on general principle. I wanted to explore the feeling of aversion he has to paying £1 on his device, which is so strong he won't do it even if someone pays him £1 to do it.

I've felt that aversion myself, and as an indie app dev I'm naturally quite keen on finding ways to explain it or work around it. Some of the bigger companies seem to get around this by just targetting kids who don't experience the aversion 'cos it's not their cash - but I don't want to do that.


>> He had already done that, because he needed to buy a couple of very expensive music apps he "needs".

Maybe he just doesn't want to get into the habit of casually buying apps. I see them as a category of impulse purchase that I largely want to avoid, because I have enough categories of impulse purchase in my life already.

I get more than enough use out of my smartphone as a comms device, as a web browser and as a kindle terminal.


I'm currently surveying 600 of my early users of my android app.

What's disconcerting so far is their answer to the following question:

The app will be 100% free for you forever (thank you for the support) however what do you think is reasonable pricing? Consider, that some of the revenue will be re-invested in making the app better for all users

It's early days now but it's trending towards $1/$2 when in reality I believe that it's worth allot more to anyone who gets a fair amount of value from it.


Once you get something for free it becomes hard to associate a monetary value to it.


Price and value are not the same thing. Lots of labor can make something valued, usefulness can make something valued, but as early liberal and Marxist political economists found out the hard way, it's nearly impossible to derive a theory prices from a theory of value.

The price is going to be determined by supply and demand, not by your labor or the usefulness of the app.

There are occasions when you can successfully price a good above supply and demand (when you have a monopoly on a good that isn't easily substitutable), but I doubt you're in that scenario.


Even better introduce restrictions after a set time limit that the user needs to pay to regain. (Just don't tell EA)


Hmm - interesting. Two samples spring to mind:

One of my apps is called "Calculate" [1] which has you solving maths problems. There is always a solution which you can view. You start off with ten solutions and when you run out you can IAP more.

I recently played a game called "Pocket Rally". Download was free, but after the first few levels you had to pay to upgrade to the full version, which I did.

"Calculate" has zero purchases so far (although it was only released a month or so ago and only has about 50 users). With "Pocket Rally" I didn't seem to mind paying the £1 to upgrade. I think the key difference between the two is that with Pocket Rally I didn't know I was behind, so when I found out I was I upgraded. With Calculate I let people know from the off how many solutions they have left - they are well aware of the situation and not really experiencing loss.

So the key is to introduce restrictions after some time limit and not warn them beforehand. That way they truly experience loss-aversion.

Not sure if this is evil or just marketing.

EDIT: changed lots of spelling and grammatical errors

[1] https://play.google.com/store/apps/details?id=com.simplyappe... (and before anyone complains about the self promotion, this is also something you are supposed to do, right?)


Downloading your game right now. The fact that your app didn't require any extra permission is great. I wish more developers would follow this.


Yeah give them all the solutions and then take them away after a day or so.

If they had some complete percentage you could also reduce that once they are removed, that's an achievement loss right there.


Now I'm starting to laugh at all the evil ways I could treat my users!


It's called Shareware, we had it 15 years ago. We had also demo or trial versions.

(Hopefully they get again in fashion)


Yes but what we're looking at here is: can we use cognitive bias to increase the number of people who pay for the full version.

So you give someone a demo for free. They know it's a demo and they know it's free. They will be cautious about buying a full version.

But if you give them a game for free, and then they find out whilst using it that it's only a demo, they will experience "loss aversion" and are more likely to upgrade since people experiencing loss aversion are more likely to gamble as they try to reconcile their loss.


> Hopefully they get again in fashion

Android has <15-min "refund" (actually I wonder if this is a "undo" where the payment didn't actually took place and goes through after the timeout, like gmail's "undo send mail", thus avoiding a chargeback)

Also, IAPs allows one to implement the demo/trial/shareware model. Most implementations are poor though, making you think you have the full game/app but subtly (or not so subtly) crippling it beyond usability, or compromising the experience with ads.


The 15 minute refund isn't really long enough to decide if you like an app, and definitely not long enough for a game.


> (Hopefully they get again in fashion)

Windows Phone and Windows 8 allow developers to provide a trial mode for their apps, to give users a chance to decide if they like it.


>> "I already have 30 apps on my phone, some of them very good. Do I need another one? I don’t use the 30 I have."

I hate seeing this argument. Why do you have those 30? Why don't you delete them? Having 30 apps on your phone doesn't mean you don't need more apps. They aren't all the same. It's not like saying 'I have 30 cans of diet coke in the fridge why do I need another?' It's more similar to 'I have sausage and diet coke in the fridge, why should I buy these vegetables'? Because they solve a different problem than the things you already have.

I think the reason people are reluctant to spend money on apps is the same reason they are reluctant to spend money on music or movies no matter who convenient it's made for them - people don't see value in digital goods as easily as they see it in physical goods.


>> I think the reason people are reluctant to spend money on apps is the same reason they are reluctant to spend money on music or movies no matter who convenient it's made for them - people don't see value in digital goods as easily as they see it in physical goods.

I wholeheartedly disagree. By your logic, people wouldn't pay money for Windows, or Photoshop, or thousands of other software packages. Oh, and Steam! People pay $20 or more on Steam for some mediocre stuff.

The problem with paying for apps is two-fold: Frankly, 99% of apps out there aren't worthy of my money. Most of the few I actually pay for (Spotify and LastPass come to mind), I don't pay for for the app, it's for the service behind the app.

Second, app developers have done this to themselves, in two ways - first, putting out just really shitty, awful apps (especially games) that aren't worth money.

Also, in perpetuating a race to the bottom and setting the expectations way too low on price. I saw somewhere that Jobs thought the perfect price point for an app is $10 (I might be wrong on the source, but someone said it). I agree with this. If you really believe you have a great app, price that shit accordingly. If you have a great app and price it at $10, if you get a third of the downloads you'd get at $3, you're still ahead. And, your users will feel like part of an exclusive club, and invite their friends to be part of it.

Of course, this is my opinion, and no one ever listens to me.


You are right. Most apps are utterly useless and not worth a single penny.

Many people have no problem with paying for software.

For instance, Liine can charge $49.99 for their Lemur iPad app because the touch screen really brings something to the table. However, a dedicated control surface will beat a generic touch screen all the time. Even with a Lemur, most people would prefer real hardware with dedicated encoders, knobs, buttons and faders.

In the same vein, there are actually not that many instances where an iPad or smartphone version of an application is superior to its desktop version. In fact, in most cases, the touch screen experience is frustrating, fiddly and utterly annoying.


> If you have a great app and price it at $10, if you get a third of the downloads you'd get at $3, you're still ahead.

The problem is that the way the app stores work turn it into an all-or-nothing game. If you get a third of the downloads you would've gotten at a lower price point today, you're so far down the charts that you'll get fewer the next day, and fewer the day after that, etc.

At least, this is the reasoning behind the race to the bottom mentality. Not sure how true it actually is.


There are a few things inherent in the design and policies of the app store that pushes prices to be low.

One is that there are no demos possible. You can't make an app that works for 30 days and then stops working. You can sort of do this by limiting the app and having it fully unlocked by in-app purchase. I really don't mind that model at all, because I just see it as a demo version.

Another limiting policy is that there is no upgrade pricing. The app is just the app.


This is actually possible on Windows Phone, and used extensively. It's the pretty version of having a lite/express/free and pro/full/complete app.


I believe that trials are allowed on the Google Play Store. I wish that these were more widely used with Android games.


>> I wholeheartedly disagree. By your logic, people wouldn't pay money for Windows, or Photoshop, or thousands of other software packages. Oh, and Steam! People pay $20 or more on Steam for some mediocre stuff.

The mistake in his logic is generalizing to all digital goods. People are hesitant to pay for mobile goods relative to others. Look at Angry Birds. In terms of hours of enjoyment (or distraction for your kids), it is worth much more than $.99 based on what you would pay for something as basic as a Slinkee. However, it took me almost a year of playing only the demo versions to finally buy the full game. This may be a positive in terms of people resisting purchase of frivolous goods, but the point about mobile goods being valued less than their physical or non-mobile counterparts stands.

What's the most expensive app to ever hit the top charts for iPhone/iPad purchases? My guess is that it is substantially cheaper than the most expensive best-selling software.

Final note: I wholeheartedly agree with you that the proportion of useless to useful apps is likely the most important factor in this valuation difference.


It's 30 separate applications to access what's effectively the same data type: documents on the WWW, some of which have an interactivity component.

Worse: each app has its own set of rules, capabilities, and/or disabilities in terms of sharing URLs, privacy permissions to be managed, update cycles, and the rest.

There's a reason we got URLs, HTTP, and HTML.

It's as if you needed to use a different viewer / reader application to read PDFs from different companies. Hell, my preference is to have one uniform reader which can handle text, PDF, GS, ePub, or whatever else comes rolling my way. Not quite there yet, though Calibre begins to unify the access (its native viewers are crap, however, and I've yet to figure out how to change its PDF viewer to something vaguely sane).


  > There's a reason we got URLs, HTTP, and HTML.
Ok, build those 30 apps with URLS, HTTP and HTML. Ok I will drop CSS into the bag. No javascript though.

Let's see the results.


Why? (the javascript restriction)

There's quite a lot of websites where the app is a mediocre replication of the website. Especially magazines.


Quite. Both counts.


Cool, you write me an android app without java and we can compare


It's not like diet coke and sausage and vegetables. It's more like "I have sausage, diet coke, ice cream, milk, beans, beef, eggs, broccoli, tomatoes, carrots, onions, garlic, tuna, cabbage, chicken, pork, cucumbers, corn, potatoes, artichoke, apples, cherries, oranges, cheese, bananas, shrimp, yogurt, kiwi, grapes etc. I guess I can live without that avocado you are offering."


From a security standpoint, the metaphor is indeed like another can of diet coke. While browsers are constantly being patched and updated, the same cannot be said for the majority of apps. The benefits of updating a browser are evident but targeting individual apps is difficult to impossible. Many apps are closed source, proprietary, and marketed by companies that have no interest in security. Even those that have such an interest can only spend so much money / manpower on security issues. Considering most of these apps offer nothing new over their browser based equivalents, this argument makes perfect sense. Once money comes into the mix, it simply becomes an argument against paying money for what are essentially useless apps masking security holes.


I have 100 bookmarks in my browser: OMG websites are evil.


How quickly can you delete 95 of those bookmarks? How long would it take you to delete 25 apps?


Also, how fast can you browse through and find the bookmark you need? There's a lot of useful data attached to each one of them, including a tree structure.

If you lose a bookmark (or maybe you're on a different device), how easy is it to get it back? You can even choose from a wealth of great search engines!

Maybe search engines will come for "native" apps. Maybe that's what OP hinted at at the end. Even then, those apps are not cross-platform.


Faster than scrolling through pages of apps. There are search engines for native apps already, the app stores, perhaps they should be updated to "search on device" and give the subset of results that are installed on the device already.


Better: even my Android browser lets me sort the bookmarks by frequency of use. Hell, I don't think my desktop browsers even do that.


Firefox absolutely does.


That is not a fundamental issue of the apps. It's a flaw of app management. The core of my analogy remains unchallenged. Besides, there is an app for that: http://lifehacker.com/5645850/apps-uninstall-bulk-removes-an...


Well if that's the extent of your analogy it's completely flawed. In your analogy someone has misused the bookmark feature to save too many. In my response - I point out it's a pain to remove apps. In future, sure maybe somebody will make app managers on par with web browser bookmarking features. Bookmarking a site is not a prerequisite for using a website, whereas installing an app is.

To point to yet another crummy app that performs extremely basic functionality that should probably be part of the os, is not really a sterling defense of the app model.


Better yet, how long does it take to update those 95 bookmarks?


Perhaps the phone app interaction model causes undue mental taxation. Perhaps better integration with the OS would allow people to get over the mental barriers of having to scroll through 3 pages and decypher 30 app names to perform a task on their phone, or a more feature rich phone os that didn't leave so many basic features up to app developers.


Oh, so we've come full circle.

Don't download random Windows apps from the internet, they're bad for your PC!

Hey, here's my nice shiny app store where the applications are curated. Only quality content, categorized, free of spyware and other distractions.

Oh no - market pressure has pushed the bar lower and lower and I once again have to rely on the Internet for reviews and comparisons of apps in order to install only the decent and trustworthy apps.

Kind of sounds like the Windows model all over again. But this time I have to go through your BS systems to publish an app on my own device. Yay progress!


And the answer which the Linux world came up with: we're going to offer you a repository with your distro from which you can obtain most or all of the applications you need.

In the case of one particular distro, Debian, this was backed by a Social Contract[1] and Constitution[2], expressed in Policy[3] which was ultimately enacted by A Package Tool (APT)[4] with user feedback and interaction supported through the Debian Bug Tracking System (BTS)[5].

Among the principles of the Social Contract: "Our priorities are our users and free software".

The result: a distro with a tremendous number of packages available (49,614 on my jessie/sid install), in which the significant concerns are user experience (including privacy and security), and freedom of software. The last possibly best exemplified in LWN's coverage of a story ... wow, already a decade ago, on LWN: "Debian and the hot babe problem". It concerned an "ITP" (intent to package) a new piece of software. I'll let Jon Corbet take it from here:

The program involved is hot-babe, a graphical CPU utilization monitor. It works by displaying a typical Bruno Bellamy drawing of a minimally-clad, maximally-endowed woman. As the CPU gets busier ("hotter"), the woman undresses to compensate. Your editor, whose journalistic ethics required that he investigate this utility, found it to be an amusing addition to the desktop - for about five minutes, or until the children walk in, whichever comes first.

The Debian developers raised the obvious, predictable objection to the inclusion of this utility: the associated images were covered by a non-free license.

Hot babes notwithstanding, one thing I noticed Debian didn't have problems with a decade ago were drive-by installs of spyware and adware which were plaguing Windows at the time. That, um, "ecosystem" has now moved into the mobile space, and the negative equity and goodwill associated will, I suspect, play out in time there as well.


And Debian got first release on August 16th, 1993; 20 years ago. It saved many from shareware/crapware app-colypse of 90s.

Am I the only on dreaming of Debian (an exactly Debian) developing an app repository (at least for Android), where free apps are carefully supported, building on top of each other where no tricks or crap exist.


F-Droid?

Yeah, it's not really "debian" per-se, and it has it's own issues, but it's close.


I'm looking forward to native Linux on a mobile platform. Preferably a tablet.


Google could help kickstart that ecosystem by offering a promotion category for "Best Free/Open Source apps" in Play. Only apps with a GPL compatible license and fully buildable from a public repo are eligible.


Why only apps licensed under a GPL compatible license? What about all the GPL incompatible free/open source licenses?


I'm not sure Google has the incentives in place to be interested in this, but it seems like a perfect fit for CyanogenMod as they try to grow as a platform.


The incentive is that Google will benefit form having an ecosystem of high quality apps. A good ecosystem lowers the bar to creating high quality apps - the non-app open source software ecosystem is pretty conclusive proof of that.

But you're right - CyanogenMod is probably a better forum for such an ecosystem to bootstrap.


Hmmm, maybe I should have appealed to Google's strategy rather than their incentives. An APT/RPM style model strikes me as counter to the prevailing direction that Android, and Google more generally has been moving.

I think that from their perspective, mass market users don't care about license terms or free-ness as in freedom. They seem to care about free-ness as in sticker price, even when it comes with prohibitive in-app purchase requirements. If we look at mass market targeted app stores based on APT-like repository systems, well, all we really have is the Ubuntu Software Center. And that isn't clearly better than the Android Market to the mass market user, and I would go further to claim that the inverse is true. So I can't see strategically why Google would change direction toward an Ubuntu Software Center style direction, and the higher quality but less user friendly APT/RPM/pacman is just a complete non-starter.

But CyanogenMod seems to have reached its market position by appealing to the ethics of openness. So it makes sense given their prevailing strategies. They also have a history of providing relatively open/customizable alternatives to Android components, and an app repository in the tradition of APT/RPM would fit right in with their past initiatives.


Sure, if instead of Android you mean a Linux distribution for phones


F-Droid is the best Android application repository around. It contains only free software.


> Oh no - market pressure has pushed the bar lower and lower

Considering the Apple store, market pressure has nothing to do with it. It has been 95% ultra low-quality, ultra-low quality crap from the beginning (stuff that a Shareware site from 1998 would have been ashamed to host).


I saw the WebMD app nag and thought for more than a few moments that it was from codinghorror.com.

And was unmistakably annoyed.

Then I realized that was precisely the point. And yes, it's absofuckinglutely annoying.

Right up there with interstitials and flyovers on webpages. I'm thinking of writing a default Stylebot CSS to simply block any element class / ID starting with "fly".

The other problem, of course (and checking to see if Jeff addresses this -- yes, obliquely) is that every app comes with its own permissions set(s) which I the user need to individually inspect and vet. And, frankly, which I'm increasingly reluctant to do so.

Fastest way to get your app removed from my phone? Request additional permissions. Goodbye Pandora, whatever that "identify that song" app was, Facebook, Mr. Number (irony: nominally a privacy-enhancing app) and others.


Fastest way to get your app removed from my phone? Request additional permissions.

Unfortunately there's little the developers can do about it, short of not adding any features. You have to ask for every permissions your app could potentially need to use, upfront. You can't ask at point of use. This is a huge Android flaw.


My local credit union works fine in a browser, but their (cr)app (the cr is silent) wants access to my complete contact list, presumably for spamming purposes. Nope! Not happening.

Other than that oddity in their outsourced app, they're a legit business, not scummy at all, which makes it weird. A place that specializes in financial transactions should probably stick to traditional protocols like a website and stay out of the (cr)app business.

I want to do mobile banking. I don't want them to add the feature of "spam my friends and family" at all. No thanks!


Another problem is that you need some permissions for even the most basic functionality.

Let us assume I'm making a singleplayer game that happens to take more space than 50MB. For that I need internet and external storage write permissions in addition to network and wifi state etc (see http://developer.android.com/google/play/expansion-files.htm...)

And all this because the persons designing android thought that 50MB is enough for all applications and thus made their package manager to cap packages at 50MB. Imagine if .deb or .rpm would be 50MB max.


Writing to storage I can allow.

Location, comms (absent some networking), messaging, address book / contacts, phone ID, Nope Nope Nope.


If you want to use 50mb of my phone's flash space then yeah, you'd better have a good reason for that.


Requesting 50M+ of storage for a single player game is a good enough reason, that's not outrageous for graphics resources, music etc. But would you understand that this necessarily leads to the app having to request:

    <uses-permission android:name="com.android.vending.CHECK_LICENSE" />
    <uses-permission android:name="android.permission.INTERNET" />
    <uses-permission android:name="android.permission.WAKE_LOCK" />
    <uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" />
    <uses-permission android:name="android.permission.ACCESS_WIFI_STATE"/>
    <uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" />
as well?


If there's not a damned good reason I can see for you to need those perms, then it's "no fucking way".

Pandora, my location and address book? Nope, nope, nope.


The problem, as I've been trying to explain, is that if any other user does want a feature that somehow uses those perms, the app has to request them at install. There is just no other way on Android.

Realistically you can only use apps that aren't developed further.


"any other user does want a feature that somehow uses those perms,"

Nobody "needs" or "deserves" or is "entitled" to my location and contact list merely because they would really like to spam me and my friends. If that is "development" then I don't want it. My contact list is absolutely positively none of their business and I will not cooperate with them. They need me a lot more than I need them, so we'll see how this turns out.


You misunderstood. If the app has any other users that want to use a feature that needs it on their phone the app maker has to request it on your phone too even if you would never use it.

There are way more people that want new features from their apps than there are users that check the permissions list. This is a lost cause until Google fixes Android.


And you misunderstand: for many of us, that's an absolute dead stop.

It's also an ethical issue: my contact list isn't even mine -- it's other people's data, and their association with me. Even if I am OK providing it, there's no way I can assure that others are. Requesting contact lists is utterly immoral (and yes, so are companies which do it).

What I'd like? What I'd like is granularity on this. I'd like to be able to mark my contact info off-limits. I'd like to duck the surveillance society altogether. I'd really like a legal framework which governs this stuff, as it doesn't seem there's any other way to get the changes I'd prefer. Yes, I'm aware that's going to cause a lot of pain for a lot of companies, but it's absolutely something they've brought on themselves with the present set of circumstances.


What I'd like is granularity on this.

Well, that makes two of us. I'm sure all Android developers would like the option to request permissions at point of use, so users who want to use the feature can give the permission, and the ones who don't, don't have to. But it isn't there, period. So the choice is: don't add features users ask for and listen to the people telling you they don't trust you to use the permissions you request wisely, or add features your users are asking for, and tell the ones that don't trust you to get lost.

You get one guess at what application developers do.

BTW. Good luck with getting the government to legislate that you can't implement features users ask for.


The permission set is just a huge flaw in Android. They really need to adopt the iOS model.


What's the IOS model?

My view: I should be able to specify what (if any) of my information is available. It's up to the app to decide if it wants to be there or not.

There are some tools (I run across mentions, and there was one Google apparently pulled after "accidentally" releasing it) which do this. But really, it's why I'm looking for a dumb phone and a tablet running the tools I want (Web, eBook reader, SSH) and local apps, but not Android. Really bad taste in my mouth.


The iOS model uses App Store reviews (with whatever static analysis secret sauce they do), plus user permission requests for access to some things like location and contacts.

I'd suggest Nokia's Symbian permission model was better, if a little annoying. It asked each time the app tried to use a given permission (until you permanently allowed/disallowed it).


I never had a Symbian device (though a couple of friends had Psions), but always had a bit of a soft spot for them.


I never had a Symbian device...but always had a bit of a soft spot for them.

As someone who had and had to develop for it in the early days: those two things are directly correlated.


Surprisingly, in Europe we had that fade two years ago.

Every company wanted a Facebook page and a year later an iOS app. Amusingly the marketing departments and executives of many companies were out of touch with their audience/consumer as most had a Android phone or tablet. Two years ago many disco, bar, smaller shops, etc. had such native apps. The main point was they all were useless as they lacked a lot of features that there equivalent websites offered.

Fast forwards to 2014 (Europe), most such native apps vanished as well as many business related Facebook pages have decreased in popularity or "dried-out". Now, some companies offer hybrid apps for Android/iOS that is basically a WebView that shows a slightly modified version of their HTML5 website.


I wish I lived in your Europe.

In mine all those venues still have websites built on Flash.


Apps are the new CD-ROMs. The Web will win.

http://www.hanselman.com/blog/AppsAreTooMuchLike1990sCDROMsA...


All this "the web will win" is bad bad bad. Call me old-fashioned, but it seems like I am one of the few people left who actually cares about standalone apps which I can download to my harddrive and then even use in the case that a) i don't have internet connection b) the product was killed by the company or c) that the company itself still exist. Just think about the idea that all arcade machines like pacman were "cloudbased". I am pretty sure all those games would have been lost long ago and nobody would be able to pay them in mame today.

What I'd prefer to see is "the internet-harddrive based on a gitlike technology wins" (something like encrypted remote ZFS with full versioning and some additional database capability for metadata). Either I host this internetdiscs on my own or I just rent some space at some random provider. Or I do both and do automatic synchronisation between them for backup purpose. When it comes to most tasks, the only role the internet should play is to synchronize my data between all of my devices. I never want to be in the situation where I depend on a website of a flshy new startup which might be dead in a few months.

(I hope my intent is clear, I am on my phone right now and hate to type long texts this way)


Curious question. How many apps do you have that are not games and very niche that don't require an internet connection?

I tend to find that the most useful apps require a connection to login, refresh data, etc.


I did not say that apps should not use the internet at all! For updates, new content and so on some reliance on the internet is totally fine, I just hate apps which will not work offline altough there is no logical reason to do so. I uninstalled several singleplayer games just for this reason.

The only apps which I regularly use on my phone are:

- sms/messages

- email

- whatsapp

- webbrowser

- alien blue for reddit

- weather app

- look up contacts/phone numbers

- camera app / panorama app

- sudoko style puzzle game

- a simple app to track my spendings

- some other small single player games

So the first half of the list obvioulsy requires internet connection but the rest should be strictly offline except for updates and perhaps new content.

And I am not so much worried about my phone apps but more about programs which I need for work on my deal computer. Right now I am using Word/Office a lot but somehow I am afraid that in a few years there will only be some cloud based online version left.


But don't you really wish that your camera/panorama app were a webpage? Then you could use the same one across all of your devices, and you wouldn't need to install anything! And instead of doing local processing on your phone to stitch things, it could send the photos out to a datacenter for stitching and get a finished image back! And if you're out of cell range, maybe it could just cache any camera data and let you see the finished images later when you're back online. And it'd be great for disk space, because everything lives in the cloud and instead of saving videos locally you just have to wait for them to load and use a bunch of bandwidth every time you want to watch one.

Yeah, me neither.


I travel quite a lot with trains in southern Germany and the internet connection there is _bad_. So no, I don't want my camera app to be a webpage. Or if you hiking in the mountains and you want to make a paborama but you realize that there is no connection? Or i travel to asia for a few weeks but I can not access my camera webpage because roaming costs are too high? Or apple bought my favorite camera app and now the app/webpage is gone (I am looking at you, Snappycam)?

For a lot of applications it totally makes sense to augment its functionality by some internet connecticity, I am just against all apps/webpages which force me to be online even tough main functionality of this app would work without internet.


I have an app called TripView. It gives public transport information and you can plan a trip using it. It does use internet for updating and real time information. But the main reason I use it is because It doesn't need an internet connection to work, unlike Google Maps or 131500.com.au.


Priority Matrix does a good job working offline, even without an account.


PDF reader and Kindle are probably my most used apps.


Except the web has always been a Frankenstein mess for development and still is.

As someone with long experience in both fields back to the 8 bit days, I welcome the native renaissance.


has always been a Frankenstein mess

cough Android gargle

Or for that matter, rewriting your app for every phone platform.


> Or for that matter, rewriting your app for every phone platform.

Cordova, Qt/C++, Xamarin Mono, Unity, Cocos-2D-X, Titanium, ....

There are lots of alternatives to minimize duplicate native code. Plus it is not as if one doesn't need to write once, debug everywhere with HTML 5.


And how much of the apps written with such frameworks will feel remotely like a native app? How much of the frameworks you mention even support a reasonable amount of target platforms?

I don't disagree HTML5 has porting problems between devices & browsers. I'm just saying that native apps have more.


I can't speak for all of them but I use Xamarin at work, and it absolutely does translate to native look and feel for the app. Although once you get to the GUI layer, it's not much more than a thin C# wrapper for the native OS framework and you have to write a lot of platform specific code. But everything else is cross-platform. And you're coding in C# and not Objective-C (or Java), which is a more predictable and less verbose experience, at least for me, and I've made half a dozen apps using Objective-C.


I sure hope that the "native renaissance" is not entirely proprietary spamware. "Apps" need to die and real software needs to take its place.


I hope by native renaissance, you aren't referring to "only on Apple iOS"


"Yes, JavaScript, HTML and CSS is a mess and it's hard, but it won't always be." - Let's wait till then.


Web developers have been claiming forever that the web will take over and nobody will need apps or software outside of a browser, but is not close to becoming true yet on mobile. If you're considering making a poor web app or a poor native app, your time is probably better spent on the web app. Even if you're crafting an average app, it's probably a better use of your time to just get it working on the web. But the UX and speed that is possible in an exceptional native app is just not possible on the web today.

Airbnb absolutely benefits from having a fantastic app experience. Facebook and Twitter absolutely benefit from having exceptional apps. Google's iOS Gmail app isn't even a very good app (slow performance from being a web wrapper?) but it's still way better than using the web app in Safari. Basically if user experience and speed are a high priority and you are capable of making a decent app, the web is not a substitute for a native app.


There's actually nothing technical on any mobile platform preventing apps from linking together. The reason it's not done is that in-the-cloud companies prefer the intermediary links be done in the cloud where the data can be analysed (inter app analytics is big business), and users actually find it disconcerting or mildly confusing, when the cloud model is actually that much worse for them.

What amuses me about the "web will win" crowd is you don't have to dig very far to find they all have a radically different conception of what they mean by the web.


Well there is, and that's called 'They won't let you onto the App store if you link data between apps directly on the device'. Plus there's legitimate concerns about malicious behavior if you don't stay confined to your pre-determined sandbox. But this is one of my biggest annoyances as a developer, and I can't wait for a mobile device that will let me write scripts freely that allow me to directly interact with the file system and manipulate those files however I wish.


I don't see why trusting random strangers with data is a good default, in fact so good that it should be the only option. I don't see why anyone but advertising firms and the like would actually want such a future.


Access to user data and native vs. web are orthogonal concerns.

E.g., on iOS you don't have to give an app access to any data, but can still have the app installed -- access is a post-install, standardized dialog when the app requests permission.

Similarly you could easily invent web apis that would give access to data (like location, which already exists).


My point was that web applications would typically have access to more data per default, in a world with no native apps with all your applications in "the cloud" more of your data would likely also be in the hands of others. I don't think they are orthogonal concerns at all.

Regarding the Coding horror link here though, I do agree with the point about native applications that essentially are repackaged web pages.


Ah, I took your point to be completely the opposite! Oops.

Whether it's a native app or "in the cloud", I think most people want their data to be synched across devices, so you're going to have to trust somebody with it.

(Well, unless you're synching encrypted data, but maybe what we should all be doing, but I wouldn't hold my breath...)


Permissions are a real problem of installed apps, but otherwise I wonder if web apps are that much better _if_ they are really applications and not documents/content.

The general functionality provided by web browsers (URLs, the back button, searching in a apge, etc) is very useful as a common basis for different content centric sites. But it just doesn't work very well for applications regardless of whether or not these applications are based on HTML/JavaScript or on some other GUI toolkit.

Yes the back button can be made to do _something_ in any app. But how can users have a reasonable expectation or intuition of what it's going to do? "Go back" used to mean "show me the page I saw before clicking the hyperlink". Bookmarking meant "remember the current page".

But applications don't have pages, they have states. Pages are concrete. States are abstract. That is the real problem, not the specific technology on which applications are based.


It's called one-page app. You can control the browser tab history with HTML5/JS5 and create WebApps that offer all the same functionally you see in most native apps.


I think you misunderstand me. I didn't say it was technically impossible to create applications based on HTML/JavaScript that have similar functionality to installed apps.

What I said is that if you do that, you get the very same UX problems as well. You can implement back button functionality in either technology, but what it does needs to be reinterpreted for every single app because you have lost the page as a concrete unit of reference.

There may be other useful units of reference, but they are different ones in different apps regardless of technology.


Isn't the app-craze just a sign that websites are too complicated, slow, in many cases also somewhat shady and full of annoying ads? Most of them are nearly impossible to navigate using a mobile browser and extremely annoying. App stores give us a tiny bit more security (through moderation) and UIs that will work for our device.

Making websites that work well both on desktop and mobile browsers is a PITA. We already have too many browser versions (and deficiencies) to take care of (yes, we really do not want 2-3% fewer users = customers = revenue), mobile browsers add a whole bunch of new issues to take care of (hover, selections etc. all work differently).

As long as we don't have a framework or set of widgets that works properly everywhere and is fast/small enough for mobile devices, Apps will have a Raison d'être. Now go write one or stop complaining!


Isn't the app-craze just a sign that websites are too complicated, slow, in many cases also somewhat shady and full of annoying ads?

1. Complicated? No, I don't think so. If anything the problem is that web sites aren't capable of being as complex as they ideally would be.

2. Slow - yes. But browsers keep getting better (iOS excepted, sadly - Apple appears to have lost a lot of interest)

3. Somewhat shady and full of ads - apps are worse in this regard, IMO. They also ask for access to your location, and all sort of other data access web sites don't have.

Making websites that work well both on desktop and mobile browsers is a PITA.

Yep. Making websites that work across all desktop browsers was a PITA a few years ago. Cross-platform web development has never really be that easy.


> Somewhat shady and full of ads - apps are worse in this regard, IMO. They also ask for access to your location, and all sort of other data access web sites don't have.

I disagree with that - App stores will reject many apps but search engines will happily index most shady websites as long as they don't serve obvious malware or try "black hat SEO". Websites can also ask for your location, store a multitude of tracking info (cookies, Flash cookies, local storage...) and while they cannot access contacts, SMS and similar information, they can get very sensitive information though phishing and possibly from browser history.

> Cross-platform web development has never really be that easy.

We could stick to the lowest common denominator (which is still simple HTML apparently), but people would complain about the obsolete UI.


Um, no. I won't install the facebook app for example because I don't want facebook to access my SMS, location, decide to pop up annoying notifications on my phone that may or may not be able to be disabled, perhaps poll in the background, etc.

I don't want to INSTALL every website I visit onto my device. I want to consume the content in a sandbox and just be able to leave. I could understand say if there was an actual need, like I have one to automatically upload photos to flickr, but WebMD? McDonalds? A site I visited once two years ago?


The problem with "apps" is fundamentally one of curation which IMHO is, in turn, a problem of centralization.

If you set out to build "the one big marketplace", you inevitably get to a place where mostly what your marketplace offers is crap, because you have optimized it towards providers putting stuff onto your marketplace.

Thus, in building "the big marketplace", you necessarily fail to optimize it towards users getting value out of the marketplace, because you kinda sorta hoped that would be taken care of by "free market" pressures. (And also because it's one of those "hard problems" that you would rather forget about and build some neat code instead.) But it's the users bearing the collateral damage.

I'm currently working on a package/application distribution system that is decentralized and the "app-pocalypse" is one of the reasons why I made it so. Being decentralized means that the value you are getting out of it depends mainly on the trust you invest in your immediate channel provider who in turn now has a responsibility to keep you happy. By splitting up the relationship and giving people proper roles instead of the delusion of a grand audience that is fit for whatever some app developers shovel into the system, I hope it will end up providing actual value instead of just a top-down revenue system.

Having worked on it for a while now, it always strikes me as weird how we are all on the Internet (which by its design is fault tolerant and decentralized), building these centralized, monolithic services that inevitably fail (either in a big way due to security reasons or in a slow way, like in the app-pocalypse) for the same reasons.


> Thus, in building "the big marketplace", you necessarily fail to optimize it towards users getting value out of the marketplace, because you kinda sorta hoped that would be taken care of by "free market" pressures.

In an open and free market most of the stuff sold "is crap", but people generally discover valuable things and will equalize to the right intersection of value and cost, all things equal.

The big problem with a big marketplace is when it obscures the value part of that balance. How do I determine which of these 30 applications has the best value/cost balance?

Isn't straight-up downloads, because who knows how many of those people still use the app. Isn't necessarily rating, because we know those responses don't really answer the big question.

A small curated market solves the hard question (which is most valuable for the price?) but short-cutting the question. The user doesn't need to ask or research, because by the nature of having a small, curated marketplace, the marketplace organizers rely on their own credibility as curators.

Like the news industry, whose job it was to curate the news, eventually a few small curators float to the top and then attract more quality curators, growing that marketplace.

But it's still inherently weak, because you're still not supporting the user answering their own question - which of these has the best value for the cost?


http://en.wikipedia.org/wiki/The_Market_for_Lemons

In a free market with asymmetric information, the presence of bad apps mixed in with the good drives down the price for everyone. People have far too much faith in the free market automatically delivering optimal outcomes. This is another case where it doesn't.


What it comes down to, for me, is the question of trust. If there are 30 messaging applications, I will use the one that somebody I trust uses or recommends. Otherwise, I would have to spend a lot of time searching through the options ("collateral damage", as mentioned before).

Managing trust on a large scale (or in terms of the big app-stores, ultimate scale) is very hard because people are very different in their needs and in which providers they would trust in the first place.

Funnily enough, even if you decentralize this process as I'm trying to do, you might end up serving all clients with 90% of the same product. But those 10% make all the difference in the world.

In a sense, what I'm trying to do is to make that dynamic of relationships and trust the main focus of how the network is built. It is a marketplace of marketplaces that rise or fall depending on how much value they provide and how much trust users put into them.


That first paragraph does it for me.

I think my question here would be, why do I want to go search out a bunch of smaller, federated, decentralized app stores, then build trust with each of their managing teams, and trust my payment info and PII with them, when I could go to a curated tech blog/info site and get recommendations, then go to one of the main app stores and buy the app?

I'm not sure that I understand what value a middle-man aggregator of smaller markets will provide that beats such a situation.


I, for one, am tired of the app-bubble. It will take a few more years, probably, but eventually will go away.

Am I the only one that looks at this whole app-crazy-run as something completely unsustainable?


And I'm tired of shoddily-coded webapps, which are also a dime-a-dozen.

Maybe the real issue here is that software has a serious quality problem. The public knows it, and perhaps its the reason programmers are not as respected as they could be.


Am I the only one that looks at this whole app-crazy-run as something completely unsustainable?

Why would it be unsustainable? Most apps that rely on REST APIs are fairly easy to write. And a few years ago, the experience was much better than web apps.

I do agree with the article that it is a user hostile experience, from the popups, to the inconsistent experience across platforms, and bad support for new platforms.


We are slowly transitioning into HTML5 bubble at the moment.


Explain?

I'm as curmudgeonly as they get. Other than DRM, I think I'm actually pretty happy with what I see in HTML5, though unfortunately there's still no way to actually force Web developers to use just a minimal markup set.

If I could force every last goddamned Web dev in the universe to stick with <html>, <body>, <header>, <article>, <aside>, and <footer> tags, along with <p>, <em>, <strong>, <a>, <blockquote>, <ul>, (and list items), form and text elements, and <img>, I think I wouldn't shed a tear. And I could then write my own goddamned CSS to render their pages in a sane and readable fashion. Once (as opposed to the 1000x I'm approaching now via Stylebot).

Table elements would be accessible for a fee, waivable for actual data presentation.


Don't forget <main>, <section>, <cite>, <dfn>, <i> and <b>, which, when used properly, can add significant value to the content. (There are a number of reasons why text might be default italic/oblique or bold, and emphasis is only one of them. HTML not only allows us to remove the ambiguity, it also allows us to tell the reader more, like what language that foreign phrase comes from, without interrupting the flow of reading.) I'm also rather a fan of <figure> when that's appropriate, since it provides a sane way to caption images that need non-optional captioning. <dl>, <dt> and <dd> have their uses as well. But yes, the idea that a document should be universally stylable based on the nature of its content should be at the top of the list.


Yeah, there are some additional tags you could toss in. I even thought of adding div and span, which have their occasional uses.

The issues I've seen tend to run the other way though: far too often sites abuse low-level elements (or higher level ones) to accomplish things the wrong way. Example time:

• Google+. They're too good for <i> or <em>. Italicized or bolded text gets its own CSS class. Which you can't reverse engineer. The entire CSS shitpile (thanks to minification) is a mess of utterly nonsemantic elements. Which I'm far, far, far too well aware of having written a very extensive personal stylesheet to fix its many, many, many UI/UX presentation issues. If you're exporting your G+ posts (which I have as I slowly exit the system), use the JSON export option which includes your original marked-up input. That is far, far, far more portable.

• Blogger's "dynamic" templates. There's something to be said about a design for a text-oriented web site that is so utterly broken as to make it impossible to actually read the text. It's so broken (and dynamic) that I can't get it to sit still long enough to actually fix it with Stylebot. I've actually written bloggers asking them to change their templates so I can read their content. Oh, and my usual fallback, Readability, fails miserably as well. Another Google property, whaddyaknow.

• Some Indian news journal site. A stunning cascade of intricately nested divs. Someone was clearly doing the needful ... to gin up consulting revenues. But I have a doubt.

• Some old-school Web 1.0 sites where ... all text is bolded (b, strong { font-style: normal }), or written inside <h4> tags (WTF?), or background images are used (more WTF, plus a plaintive "why?!!").

• Paragraphs separated by <br> elements. No <p> tags. Better: Long streams of <br> tags inserted into RSS feeds. These can be addressed with sibling rules: "br + br + br { display: none; }".

• Paragraph indents accomplished by consecutive &nbsp; entities. That's what CSS rules are for. Sigh.

• Mixing px and pts or px and ems for any character sizing / positioning. IF IT'S TEXT, USE PT OR EMS.

• Fucking with letter spacing.

• Random <span> elements with hardcoded, px-sized, fonts.

• Inline styles.

• Tables used for text layout. Yeah, pg, I'm looking at you.


Don't forget the divitis of responsive web design - one of my utter bugbears. Should people jump ahead of technology so much, or wait for Flexbox support to catch up and then do it? I know what I think...


I think I touched on that -- the Indian site I mentioned is the *.indiatimes.com as I recall, and yes, it does seem to be quite the mess.


HTML5 isn't just about the tags. It's an ecosystem of technologies that are breaking down the barriers of the browser to enable more native-like experiences over the web. Take for example how Google Maps in the browser can "access your phone's location". Think about what it's doing - there's a browser API that web developers can call that retrieves data sensed off the user's mobile device. This used to only be possible with native apps.

Also, the HTML5 ecosystem is more exciting because of the renaissance with javascript (nodeJS for server-side javascript, many JS libraries and frameworks) and the entire developer tooling that is making web development workflows much more productive than in the past.


> enable more native-like experiences over the web

Didn't user-facing Java (e.g. apps) on the desktop chase this unicorn it's entire existence? Will it be different this time?


"(nodeJS for server-side javascript, many JS libraries and frameworks)" - the saddest part, as if we don't need language innovation anymore... One to rule them all.


If JS is the x86 of the web, then we need to stop arguing about which macro syntax we prefer and move up a level of abstraction.


Let's just jump to the Wolfram Language! hehe, that would be awesome.


So long as I can turn off the privacy invasion stuff, I'm not horribly miffed.

I've switched to OpenStreetMap.org for my mapping uses these days.


There is no HTML5 bubble. Even if there is, on the long term it will be a mere blip on the radar.

The Web is the Borg. First there was the dotcom bubble, and now the Web is bigger than that. Then there was the Web 2.0 bubble, and now the Web is bigger than that. Now it's time for the HTML5 bubble to grow and burst, and in 10 years the Web will be even bigger still.


Yes, but I think the transition is happening rather fast (not relative to our newly wired brains perception of "web time", but like in normal human time measured in decades and life experiences).

It's actually pretty amazing to see new user behavior where they install the latest version of a web browser to keep up with the jones's. This is good for browser developers as there's a demand for improved functionality and performance, and it serves to move us all forward as a web community faster (so web developers don't need to support dinosaur-era browser quirks for backwards compatibility). It seems like web technologies have achieved a "virtuous cycle" of improvement that is propelling things forward very quickly.


Cross-posting my comment from his blog:

Since the app ecosystem is generally closed, why aren't apps available as Shareware, with 30/45/60 day trials, or with no-questions-asked refunds within 48 hours of buying?

What you said about coffee-vs apps is spot on. I've bought some totally rubbish apps and now it's a hard sell to get me to buy any. Competing apps in a field (e.g. PDF marking up on iPad)? I can't try before I buy, so I haven't bought...


At least the "It looks like you're writing a letter" era came with entertainment by Clippy. I avoid going to sites that don't remember my rejection of their "website-wannabe" apps ... Atwood is right about how annoying that is!


You call that entertainment?

Back when I had the misfortune to have to use Microsoft software, pretty much the first thing I learned to do on any fresh revision was how to nuke those damned tools with extreme prejudice.

The most gratuitously annoying aspect of the cartoons? The little dance they did when you told them to go to fucking hell and never come back. One more half second just to rub it all in.


I liked the cat, I still miss him. http://www.youtube.com/watch?v=ykGIcXKAXbI


I'm quite fond of cats.

Not that one though. They were all just so gratuitously annoying.

Actually, now that I think about it, Microsoft's tone-deafness on just how much people hated Clippy reminds me of Google's attitudes on G+, Real Names, and the Anschluss of all Google services.

Note that ZDNet (hardly a harsh Microsoft critic) noted when Clippy was finally killed (in 2001):

http://www.zdnet.com/microsoft-kills-off-clippy-3002085615/

Software giant Microsoft is laying off one of its most controversial employees: Clippy.

The software help system, a long-despised feature of Microsoft's popular Office suite of business software, is the star of a new Web marketing campaign launched on Wednesday. The campaign and a companion Web site trumpet Microsoft's forthcoming Office XP software as so easy to use that Clippy is out of a job.

And even that didn't take, they had to take out a second hit 9 years later: https://www.youtube.com/watch?v=VUawhjxLS2I


Calling it "Entertainment" was tongue-in-cheek ... WSYIWYG is overrated!


Seems it's less tongue-in-cheek than staple-into-roof-of-mouth, but yes.


Ouch! (It hurts to just consider that)


Can we stick to the web somehow instead and bypass the various proprietary walled gardens?


We can. Whenever I see "Would you like to install our app? Y/n", my answer has been Ctrl-w to close the tab. This strategy has worked flawlessly for years. It can work for you, too.


May I suggest the additional step of an /etc/hosts file entry for the site in question. I recommend '0.0.0.0'.


Just give it a few years (like five or ten), it'll come back to the web.

I think the APP-cycle will end and new Web 3.0 will be the new craze.


The web is Googles walled garden. Both Facebook and Apple realized this so made their own walled gardens to prevent Google taking over


Yes, just need a way of letting companies innovate on the web of pigeonholing into crappy HTML5 and JS. Maybe make PNaCl more mainstream.


He hits on some good points and misses on some others to me.

Most importantly, the question of why you are building an app in the first place is incredibly important. However, he's also got to consider each app maker is unique. McDonald's makes an app because they have a marketing budget so large that their strategy is to appear everywhere - including your phone. However, I generally agree with his point that not everyone needs an app, and they absolutely shouldn't be giving us the mobile equivalent of the Javascript popup every time we hit their website (personally, I like the sites that just have a header bar drop down asking if I'd like to install the app that is easy to scroll past).

I don't think the web is dead, but I do think mobile apps are the future. The best UX I can imagine based on what is around right now is something like what Facebook is trying to do - apps that deep link to each other without the user realizing they are moving between apps. The key here is that the apps must be specifically designed to maximize the user experience, not just to have an "app." We aren't at that point yet, but remembering where the mobile web was back in 2005 when I got my first data plan compared to now keeps me incredibly optimistic about its future, as does knowing that some of the smartest people out there are thinking about this problem all the time (like the guys at URX).


It sounds like someone soon will being reinventing OLE (Object linking and embedding)...which scares me a lot.

Maybe call it MOLE - mobile object linking and embedding?


The only good news: If the web is as dead as the PC or Lisp I won't have to care about these problems for a long time. Back to work ..


yep, but this kind of considerations define which projects get funded and get traction and excitement.

There is always money in legacy, but you don't read often a about a startup creating exiting products for COBOL refactoring...


Isn't that the definition of exiting? http://www.cobol-it.com/index.php?page=products

"Restructuring COBOL sources" "COBOL-IT is the first company offering an enterprise-class Open Source COBOL Compiler with a wide range of Premium Professional Services"


The web is not going to "win" because the average consumer has been trained to look for "apps" from the app store, not to use web apps. Web apps packaged in the app store might be a bigger thing moving forward, but the point remains - on a phone people expect an app. No amount of needing out over how things "should" be is going to change the basic behavior of millions of users. Instead of hoping the web will win, smart devs will accept reality and make the best of it.


So make the web look like apps, as Firefox OS does.


Which I don't believe will win any usable userbase.


You're right, nobody uses websites except for some guys @ CERN.


You have slipped a lot there: the difference between website and app is much much bigger than many would like to admit.


You might reasonably argue that Firefox OS will not get much traction, but denying it's existence as you're doing is foolish, because it obviously exists.

There is no difference between apps and webpages. None. Zero. That's the point of the original article as well: that most apps are just worse implementations of perfectly working webpages.


Actually I did work @ CERN. :)

What I mean is that I don't see a value in Firefox OS over the existing browsers on mobile OS. It is nothing more than a revamped WebOS.


I agree there's no point in getting a Firefox OS phone if you have a phone with a decently modern browser. Their pricing and hardware positioning appear to be squarely aimed at those places where those are not available.

However, that takes nothing away from, and even supports the assertion, that webapps (or generally, pages that behave like apps) seem more future-proof. They'll work on your "phones with decently modern browser" too, regardless of what happens with Firefox OS.


It seems that the line between native app and web will increasingly blur as HTML5 matures to the point it obviates whatever advantages remain with building native apps. I think this will mean a better end user experience as there will no longer be these walls between the web and mobile experience. It doesn't seem efficient for companies to have to build a website, a mobile version of the website (with responsive design), and native apps (for every platform).


  > It seems that the line between native app and web will
  > increasingly blur as HTML5 matures
Would you care to elaborate on that? Because I see no blurring. Building apps with webtech was a stupid idea to start with, and the current state is just incessant running in circles trying to invent a wheel. I am pretty sure that webdevs touting the victory of HTML5 have no idea what native offers and how many years behind even the best web-based offering is.

Why don't you first replace all the desktop apps with the browser and then talk about mobile? Why this obsession that web should win? Why not everything has it's place?


I am pretty sure that webdevs touting the victory of HTML5 have no idea what native offers and how many years behind even the best web-based offering is.

It's just an example of worse-is-better in action. Many webapps offer mediocre features compared to the real thing, but they have no install latency, better monetization features than pay-in-advance or messing with serials and unlocks, and offer enough features that you can get by with them. When the need to use or access them on mobile arises, they are available, and often the native solutions are not.

I like LibreOffice Calc (or Excel, for that matter) but they don't work on my Android tablet.


Many people misunderstand the proper boundary between apps and Web sites.

Web sites that should remain Web sites "go app" to get more eyes. That's the main fault found in the article. App makers that should be thinking "app first" or "app equal," including Google, often have apps that are not at feature-parity with Web sites. That's also pointless and very annoying.

There's a place for both. The Web is great for publishing hypertext information and when you tread that line with e-reader apps, you have to be very careful not to leave out Web functionality. And while Web versions of highly interactive applications offer an anywhere-accessible backstop, if you don't put more effort into the apps, you're missing the point of putting an app in a highly interactive touch device. Apps are inherently better at controlling presentation, direct manipulation, and inter-app cooperation. If you are not accessing these capabilities, you probably cross-trained a bunch of Web UI people to write your apps, gave them a smaller budget, and your product manager wasn't aware there are features that apps should have that are hard to duplicate in Web interfaces.


Literally yesterday I got an email to download the new Sallie Mae app. Now I can have my student loans with me wherever I go!

I wouldn't be surprised if the app had a button to "share this loan on Facebook".


And yet app revenues keep increasing every quarter (http://www.asymco.com/2014/02/10/fortune-130/).

First, I'm not sure poor marketing practices can be blamed on the App Store itself. It is up to those companies/sites to decide how to promote themselves. I'm also not sure it is the App Stores responsibility to provide many marketing channels.

Second, websites are free, that's why most people probably expect apps to be free, too. I think people like to pay for experiences. A coffee is an experience. And you get a friendly barista, a nice store with wi-fi, a whole table with extras to mix in, etc. Software in comparison is really abstract. Out bodies tell us they are hungry or sleepy, and pressure us to do something about it. Our bodies do not pressure us to try out a new calendar app.


I think this blog (and some other sentiments I've heard lately) is chaotic enough to be boiled down to: "Something's not right here!" I'm not sure that fragmentation, inconsistencies, nag screens, hamburger apps and a general refusal to pay $2.49 for an app are explainable in one easy way.

One insight (I think) is - "My son's iPad has more than 10 pages of apps now, we don't even bother with the pretense of scrolling through pages of icons, we just go straight to search every time."

If search turns out to be a game changer again, that's an interesting result.


One way to deal with app platform fragmentation is to develop your app using a technology that supports multiple platforms -- Sencha Touch comes to mind as one example. Not that it solves the problem entirely, but it does make it cheaper.

I'm not sure what makes the app ecosystem that much different from the web at large -- if anything, I think the amount of trite, junky apps mirrors the amount of useless noise found on the web in general.

He does make a good observation about there being an opportunity for some startup to come along and do to apps what google did to the web.


>Have you ever noticed that the people complaining about apps that cost $3.99 are the same people dropping five bucks on a cup of fancy coffee

Every single time there is a post like this we beat the same dead horse.


You can certainly be forgiven if you stopped reading the article at that sentence, because that is a frequently-beaten dead horse.

However, Atwood is actually making the exact opposite point: he goes on to say that people are justified to gripe about $3.99 apps because the quality of apps is so uneven and there's no real way to ascertain the quality of an app before you buy it.

He says we'd certainly be justified about complaining about $3.99 cups of coffee, too, if only 1 in 5 $3.99 cups of coffee was actually a decent cup of coffee!


"Would you like to subscribe to our Newsletter before you read this article?" is an equally poor, if not worse, way to welcome a visitor. Atleast give me a chance to evaluate that decision.


Reading this, I was left with the impression that iOS apps took off by offering high quality at low cost. However, the cost differential was wrong and eventually the developers figured it was a scam and changed up.

Some provided lame platforms for pump and dump html to apps. Others made their games free and played off their users addiction.

Each day app developers burn more and more consumer trust. Eventually we will get to a point where quality matches cost, we may be there already.


The app purchase process is definitely broken. You can't trust ratings, and it's hard to know what you get. In the end it's just "I'll toss a few dollars and roll the dice."

I really want high quality education software for kids. The only thing that works is word of mouth. App store reviews don't help. Googling the topic produces mostly reviews that may or may not be ads.

I'm waiting for Netflix of the App World.


Jeff is really talking about a very specific kind of app: one that provides an interface to a web service, and that has (or could have) a comparable service accessible through a browser.

There are a lot of apps that make the bulk of the "millions of apps" that do not fit this description: games, productivity apps, apps making use of mobile hardware (microphone, camera), that couldn't possibly have web alternatives.

It's totally true that App stores have pricing/quality/discovery problems, but I'm not sure that there is a duality with the web (which could be resolved by "product x"), just an intersection.


Meanwhile there are decent sites that run fine in the browser. E.g. I had no trouble with http://thrillbent.com adapting to my PC/phone screen size.


There should be some universally recognized icon, like RSS feed icon, which would be on sites offering app versions, and user could press it of he wants to.


Google Play and Apple App Store each have a "badge" graphic consisting of the logo and some white text on a black, rounded rectangle. Maybe Google wouldn't mind if you cut it down to just the Play logo. Apple says not to modify theirs or use the Apple logo alone. I'm surprised Apple doesn't use their normal pencil-paintbrush-ruler icon for the App Store, as the Apple logo alone doesn't necessarily make sense.


It's going that way. Hopefully not some annoying icon featured prominently on every page, but instead a subtle browser-based recognition that the site also has a web app and puts a tiny mobile icon in the browser bar that will launch you to the app's install page.


This functionality is actually built into the Metro side of IE 10/11 on Windows 8. Which sadly means that nobody (especially nobody who reads HN) will ever see it.


Cool, didn't know that. But HTML5 will enable this in a platform-indepedent manner which is good for the web.


One of the main reasons companies want people to download their free app is that it's a great marketing channel. Once enough people download the app, it goes up in the App Store rankings. When you are up in the rankings, you get free marketing for your product. Thousands/millions of users are seeing the app and by extension the product.


I think that the move from the web to apps the web brought on itself.

Fundementally the web is a linked document viewing system. Later it needed scripting and a bletcherous system was hastily added. But the web had huge momentum, the system stuck, and here we are with three+ major browers all interpreting the morass of HTML, DOM, CSS and Javascript slightly different. Yes, HTML5 tries to rectify some of that, but it's sadly too late.

As a developer of a mobile or tablet application you have a choice of the technology cesspool that is the web or the nice tidy mobile development tool of your choice (mostly) with sane UI tools and a language that probably didn't need a "good parts" book. You also get a better system for collecting payment, easy access to the customer's data, and when it's installed and then compromised it's on someone else's computer, not yours. And that computer is relatively easy to use. No calling nephews to figure out where the internet went ("It used to be right here on the screen..."). To view a usable 1024x768 web page you need one of those complicated general purpose computers, which really aren't practical or even understandable for 95% of the population.

It's so easy to make an app we now have a gajillion of them cranked out daily that no one cares about. Then they get thrown in the the cesspool that is the mobile app market and the suckage continues.

If you want to have the web continue to flourish (and I'm not aligning with the trolling and utterly stupid Mr. Rabois here) we should have better tools for creating applications for the web. I'm not sure what that would be (bytecode runtimes, mature HTML5, a new language?) nor how to wrest control from the oppressive JavaScript Empire. But unless that happens don't be surprised if the web turns a bit gray.


This is one reason why MS had significant developer mindshare ten years ago: they invested a ton of resources into creating great developer tools, be they IDEs, languages, or frameworks. While many have derided MS for their frantic pace with this, it does convey an attitude of "developers are important to us: have some new toys." While those tools weren't always the most advanced, they did build on each other.

The web today is still dominated by the same tech stack I learned in HS: HTML/CSS/JS. The DHTML of yesteryear has mainly had hordes of libraries built on it to make it more palatable. But accidental growth tends to spawn a lot of needless complexity. The web is a fantastic delivery mechanism, and I love that it's open. But it's just so painful for app development compared to the walled gardens that I don't blame developers for sticking with something that is more cohesive.


Imagine an environment that was not connected to the Internet but you still needed to deliver services through handheld and desktop platforms. Would you go native or a web (internal) based solution?

All devices would be the same and all users would have access to same services.


Funnily enough I've found ebay and similar stuck-in-the-90s websites are very easy to use on my phone. It's the ones from the late '00s fancy css and rounded corners era that are less usable.


This seems to me like a straightforward extension of Sturgeon's law: 90% of everything is crap. Should hardly be surprising.


Jeff Atwood is a horrible analyst and populist writer with mediocre knowledge. Noone should read his blog...


Jeff: sorry... who are you?


tl;dr. Jeff loves Apps and would like all of us to make more of them.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: