Hacker News Reader

Comment by downandout | Hacker News Reader

I agree for the most part with this article. I think the major problem is that apps are being developed that offer absolutely no advantage over viewing the website in a browser - in fact many offer disadvantages. This is what happens when a market crowded with some shockingly bad app developers is combined with ignorant executive mandates that companies must have apps simply to be able to say that they have them.

View on HN

We've been conditioned to want apps. Or... many people have. iPhone is synonymous with 'apps'. My grandmother understands 'apps' (well, mostly!)

I was on a project last year, and we built a mobile website (could work in iPhone/Android and probably winphone, but we didn't test). Got a lot of immediate "yeah that's great" from some people. Partners reached out for potential customers/sales - every single one returned with "where do I get the app".

Us: "http://foobarsite.com.

Them: "Cool, but I can't see where to download the app!"

Us: "You don't - you just go to the website"

Them: "But I need an app!"

They don't necessarily know what they need. Perhaps all they need is a bookmark for your site, exposed as a big button choice. You'd have to follow up with some testing to find out what this really meant.

Those people don't know what an app is. The people going "where's the app" will also look at your site on your phone and think it is an app. They just need a way to bookmark your site and see a little icon for it with their apps.

I'm continually disappointed by the non-proliferation of webapps. The iPhone has hooks enabling you to make it fullscreen, have an app icon, work offline, even control the colour of the status bar... but no-one knows how to use them. And Android doesn't even support them- I thought Google was supposed to be a friend of the web?!

In theory you're right. Unfortunately in practice most webapps better stay in the browser on iOS. The Javascript engine on full-screen webapps is slower than the one in Safari (that's why the previous Facebook app was slow as hell).

Aside from that, offline app cache is a PITA to implement.

Things have got better though. Web audio works on iOS 6, and Chrome on Android finally delivers a proper browser. I hope in a few years time we'll actually be able to serve games in WebGL to the browsers on both platforms.

The Javascript engine on full-screen webapps is slower than the one in Safari (that's why the previous Facebook app was slow as hell).

Not true[0]. Home-screen web apps use the Nitro engine as of iOS 5. It's only embedded web views (i.e. the Facebook app, Google Chrome on iOS) that don't. FWIW Chrome is my favorite browser on iOS, despite the speed loss.

[0] http://arstechnica.com/apple/2011/06/ios-5-brings-nitro-spee...

We're solving that by actually having an app "installer" on the web page. It looks and feels like the App Store, and you "tap to install" just like you would a normal app.

We do actually download and stash most web resources, to speed up load times, so it's not completely window dressing. Our app is designed to be added to the Home Screen, but it also runs inside Safari or Chrome just fine.

In most cases, I find the apps are actually worse than using the browser. A lot of them are little more than branded Webkit wrappers, with $SITENAME in a coloured bar across the top. If you're going to force me to use an app, it needs to offer some really concrete advantages over the site, and should actually act like an app. One simple win would be a global text resize setting -- give me the option to increase, or decrease, text size throughout your app and then remember it.

One mobile app that I do think `does it right' is eBay's. It's not spectacular, but it's much better than their mobile site and feels like I'm using a real app. It really needs to improve upon its caching behaviour, though.

There's actually a submission rule for iOS that says an app shouldn't be just a web view for one site and no extra features. It's frustrating that the AppStore rules are often not enforced consistently.

They're popular with people who take the subway. Think about it, you're sitting there for half an hour with no service. An app that pre-downloads all of a newspaper's stories is handy and easy to use.

As long as it isn't a single application for each and every source you'd read things from.

Yes, but that market is covered by Instapaper and Pocket, among others.

Sure it is, so long as you've remembered to fill Instapaper or Pocket with stories from the newspaper's website that you wanted to read. If you ran out the door without having time to peruse the stories on the internet this morning Instapaper won't do you any good.

Neither will having an app that you didn't launch and sync before getting on the subway. Seems like the same amount of effort to me.

There's an advantage to Instapaper and company in that it's centralized and you only have to launch the one app to pull down all of your content regardless of the source.

> Neither will having an app that you didn't launch and sync before getting on the subway. Seems like the same amount of effort to me.

And here I thought in 2013 apps could download their content in background when phone is idle. Maybe when the owner is sleeping at home with fast wifi all around. Might make too much sense though.

I can't tell if you're being purposefully obtuse or not.

iOS does not allow background downloading, unless your app is part of Newsstand. While it would seem to make sense to make your news delivery app appear in Newsstand, it does come with some trade-offs, most significantly that your app is locked inside the Newsstand shelf and can't be placed in a primary app slot.

And, even if your app is in Newsstand, you have to actively go into Settings and turn on background download on an app-by-app basis.

Finally, even then, the app will only background-download if you're on a WiFi connection. I agree, this makes sense in this age of metered WAN bandwidth.

So, if you're using iOS, there's a really good chance that you will not have that content before getting on the subway, unless you remember to click into it on the walk over to the station.

I'm not being purposefully obtuse. I was not aware of this particular limitation of iOS (and probably numerous others). Permission-controlled background downloading would seem like a reasonable solution to this particular problem to me.

OK, good -- thought I might be taking troll-bait, but in that case, glad I could provide information.

In principle, you're exactly right -- but iOS in particular has been notoriously picky about app sandboxing, and there is a very short list of permissions that apps are allowed to ask for: location, push notification, and I believe now address book access.

Perhaps not with iOS, but Android allows such things in their SDK. Guess iOS is just more restrictive in that manner.

I've never tried this feature as it requires location services, but doesn't Instapaper offer exactly that? Location-based automatic downloading of new articles?

Most of the time the app does not predownload all of the content in advance though.

The Reuters app _used_ to download all the content and then was changed not to. Who does that?

The bloke in charge of the server budget.

Someone who can see the bandwidth cost, but not the utility.

It's static content, how much could it cost?

the cost of the bandwidth

I mean, if the content is cached in a CDN the bandwidth is going to be negligible.

What? No coverage in subway? You must live in Sahara.

Or London six months ago...

or DC

or NYC

So, modern infrastructure Sahara then :)

Offtopic, but I prefer it that way. I hear enough people yammering away all day, I don't need it on my commute as well (I'd be fine with it if they just instituted data, but since when has the MTA ever done anything intelligently?)

Actually, London has data on the Underground (wifi) but no mobile signal.

(Okay, you could use Skype or whatever, but I'd expect the latency and reliability of the connection is too shitty for that.)

well, at least in Lisbon (Portugal) we have GMS/UMTS coverage inside the subway (Metro) since 2006 :)

What I really really don't like about the Android app model is that an app will come along and demand over a dozen permissions. And I either accept them all or don't download the app.

I have seen an app (probably root-only) that can restrict specific permissions on applications. There are no promises if it will break the app or not, though.

Currently, removing an individual permission from an app will almost certainly cause an unhandled exception, since having that permission makes security exceptions for the corresponding API calls unexpected.

This could be changed without breaking existing apps.

Google could modify Android's app model just slightly, to enable apps to declare in their manifest that they support "a la carte" permissions and then enable users to select individual permissions. To work under this new permission model, apps would have to test for permissions, or handle security exceptions - small modifications.

I think this kind of change would be well worth it. For example, I prefer to trust the OS is preventing location tracking than that the app developer is being honest about turning it off in a setting.

I really hate it when some apps require unnecessary permissions. Why would a game require access to my contacts or my personal photos and videos? Flicks me into the paranoid mode, especially since the news about Facebook and other major companies exporting your contact list and personal information to their servers.

"ignorant executive mandates that companies must have apps simply to be able to say that they have them"

This seems to be the case more often than not. Company executives feel pressured to release an app, any app, because "that's the future" according to whatever self-styled expert they listened to at XYZ Conference. So they crank out a useless app or two, and they get to tell their colleagues, peers, ad agencies, and Wall Street that they are forward thinking.

Such a strategy completely ignores the customer and his/her needs, of course. Publishing an app just to publish an app is pointless at best, and damaging to one's brand at worst. A company without a solid app strategy would be far better served just not releasing one at all. There is a negative ROI associated with a bad app, and not just in terms of the development and marketing dollars burned.

I think the main problem is that companies have their website designed for large screens only. Since it sucks on mobile screens, they then build an app instead of redesigning their website so that it works on little screens. The most famous example for that is Twitter.

> This is what happens when a market crowded with some shockingly bad app developers is combined with ignorant executive mandates

You may be a clueless pointy-haired boss if...

I continue to believe that most of these completely unnecessary apps are by internal devs who want to hone their skills in what they see is the great new lottery ticket, so they convince their hapless managers that they have to get on the app train. I've dealt with this enough.

Reply on news.ycombinator.com