I have a friend who was an accountant, found that he liked writing VBA scripts in Excel, and eventually wound up at a company big enough to need an IT department but small enough not to afford a big one, and now he's basically got a dual CFO/CIO role. Every six months or so he tells me about the new mobile app he's got in development for the salesmen to place orders, or for manufacturing line inspectors to check inventory, or something. I always point out that it would be cheaper, faster, and more general to just build a wep application, and he always rolls his eyes and tells me I don't understand the marketing power of mobile apps.

Which is true, I don't. But it got me thinking about all the "browser is the new OS" and "the Internet is OS-agnostic" and "this is the end of Microsoft" talk from the late 90s. Anyone else remember those days? Because Steve Jobs and the IPhone pretty much undid it all. It's 15 years later and everyone cares about the OS again. Weird.

> Because Steve Jobs and the IPhone pretty much undid it all.

It's funny that you pin it on Jobs, who didn't want apps in the first place. Indeed, in 2007, Apple was telling developers to make web apps - http://www.apple.com/pr/library/2007/06/11iPhone-to-Support-...

It was user demand that drove the creation of third party native app development.

Jobs didn't want apps or Jobs said he didn't want apps?

If the native SDK wasn't ready yet, I would have been promoting Web apps, too.

He really didn't want apps:

http://www.nbclosangeles.com/blogs/press-here/Steve-Jobs-Did...

Did Apple write any of the iPhone 1.0's system apps as non-native web apps?

IIRC Jobs specifically mentioned that the built-in apps couldn't have been built to the same quality if they were Web apps. But then he told developers to write Web apps. So either he had a "native for us, Web for you" policy or he was just stalling until the App Store was ready. I'm inclined to take him at his word, but considering RDF we may never know for sure.

Or door #3: steve jobs thought 3rd party apps would do more to ruin the experience than to improve it, and all-in-all users were better off without them. Given his control freak tendencies, I'm inclined to believe that last option.

At the time that he said that, did Jobs indicate that web apps on iOS would ever be given hooks into the accelerometers, or GPS, or mic? Because if not, what would the point be?

I remember reading somewhere that they /did/ try to build some of the iphone 1.0 apps as something akin to dashboard widgets and found that the hardware just wasn't quite up to the task, and they were forced to build them as native apps for performance reasons. This says to me that ideologically, they were convinced that the osx dashboard widget method of development was the way to go, but the reality of mobile hardware, combined with their even stronger ideology of responsive user experience made them go native.

Given Apple's counter-intelligence tactics...you still don't know that.

Just like we don't know whether those iPhones were actually "lost" in a bar...both times.

As a web developer who has to implement stupid stuff like the OP's link every single day, for a large corporation that refuses to listen to anything the IT team says... I tend to agree with you.

Web developers aren't always altruistic and some even have some business sense. Not that I agree with the what the 60 minutes site did (at least provide a link to go to the full site!), but pushing a mobile app will give them the opportunity to make money off of app fees (or app subscription services, or ads, or better data, or whatever).

... and slurp up your address book.

> In fact, when presented with the mandate that they needed a mobile app, the web developer probably just wanted to create a nice HTML5 site that could be served up in any tablet or mobile browser without the need to install a special app for their particular device. Know why? Because that is what web developers do.

That's what we did, the first time. We carefully constructed a responsive design that would scale to an iPad resolution and make good use of the screen space, and that would scale again to a smartphone, taking into account single-handed use, UI guidelines for the size of controls so they could be tapped reliably on a high-res screen, and all that jazz.

And we learned in the process how many different ways Apple deliberately break the web browsers in their mobile devices.

They pretend they're on a different size of screen that has no relationship to physical reality, and scale your page accordingly. I'm sure that's great if you really want to see an entire web site squeezed into a few square inches with text too small to read, but it completely breaks the usual CSS tools for building a responsive design.

You can fix that by forcing the viewport size. However, if you do then as soon as the user rotates their iPad the browser zooms the page to show the same content at a different scale instead of actually letting the responsive design do its work by reflowing the layout to take advantage of the new page dimensions while keeping everything at the same size.

You can fix that by setting a maximum zoom level, and a lot of developers stop here, but if you do then you'll sacrifice accessibility for users who genuinely want to zoom because they have imperfect vision and have difficulty enjoying a site at a size that is aimed at a typical visitor.

You can fix that by setting the default zoom instead, detecting an orientation change event, and resetting your overrides each time the page rotates, as long as you can get all the proprietary hooks right and you don't mind either browser sniffing on your server or shoving the extra code to all your users even though most won't benefit.

And so on, and so on.

If Apple want usability for web sites on their iOS devices, they need to stop making it actively difficult for web developers to support their users. A single, simple option that says "make 1px = 1 physical pixel" would be sufficient to fix almost everything they get wrong as far as responsive design goes. Is that really so much to ask?

<cynic> But maybe they don't, because after all they take a hefty cut of the profits on anything you make via an app, so they have a vested interest in pretending to support web standards but actually screwing them up to make app development more attractive. </cynic>

If users don't like the experience they get as a result, there is an easy solution: don't buy Apple products that are shiny but broken, buy something else that works instead. There's no shortage of either good smartphones or good tablets from other sources today.

(Edit: FAOD, the "we" above refers to my team and me, developing our own products. We're not connected to the site linked at the top of this discussion.)

While these decisions all sound stupid in principle, when you actually think about it they make a great deal of sense. They all stem from one root requirement:

Regular websites should work with minimum problems on an iOS device.

This is a requirement that made sense when iOS came out years ago, and honestly still makes sense today. It's why browsing on an iOS device is so damn awesome.

That explains the different reported size. Once you have a different reported size, you enter the viewport and zoom issues. But at that point, all the decisions intertwine and make sense amongst themselves.

Now, why isn't there a 1px=1 physical pixel setting? That's a different question. By which I kind of mean, “the retina display is probably the reason there is no such setting”. Regardless, that's a missing feature. The ones that are there all make sense, and aren't nearly as foolish as they sound at first glance.

I agree that the viewport-based rendering makes a lot of sense if you assume that all web sites are not designed for your device. Arguably, it even makes sense as the default behaviour.

My objection is only that if you have a team who are actually willing to go the extra mile and provide a customised UI that plays to each device's specific strengths, it's absurdly difficult for them to get it right.

CSS media queries actually aren't bad for this sort of work in either design or device support these days, give or take some absurdities involving scrollbars. All I want is for all those juicy features to actually tell me about real pixels. Then I can fix my font sizes and icon spacings and graphic dimensions to look pixel-perfect and still remain accessible and draw at a similar physical size on all devices.

I wondered for a long time how it would be handled when screen pixel densities got high enough. There are a couple ways to handle it, and apple took the only one that seems completely backwards compatible: they abstracted the notion of "1px". I guess it couldn't have really evolved any other way, but damn that is messy.

A CSS pixel has never been an actual pixel- it's 1 pixel at 96 dpi

Oh. Thank you. I hadn't known that.

You honestly think they "deliberately break the web browsers in their mobile devices" and are "making it actively difficult for web developers"?

Most of my professional work over the last two years has been targeted at mobile webkit, usually Safari, and while I have frequently felt the urge to defenestrate an iPad due to some weird quirk, I never reached the conclusion that someone had consciously crippled them. Mobile Safari's DOM rendering is all sorts of wacky and requires a frustrating amount of non-intuitive workarounds, but with regards to the orientation issues you mention, browsers haven't really had to deal with rotating displays until fairly recently. So, I can understand not liking the implementation decisions someone made, but attributing it to malice seems a bit absurd.

.. and unless there are some undocumented tricks I haven't come across, I've found web development for Android devices to be a truly unholy mess, significantly worse than Safari.

> You honestly think they "deliberately break the web browsers in their mobile devices" and are "making it actively difficult for web developers"?

In the sense that they have broken stuff because of decisions they consciously made, yes.

I doubt their motivation was to do that. I'm 90% sure that it was just an unintended (or worse than expected) side effect of trying to do something sensible with sites that weren't designed with mobile browsing in mind.

I do, however, reserve a 10% skepticism allowance for any potentially hostile policy adopted by certain big companies, including Apple and Google, that do have form when it comes to adopting (or turning a blind eye to) ethically shady practices that conveniently help the business model that actually makes them money.

And making an actual app is easier and cheaper than all of this?

That depends on your point of view.

There is a wealth of documentation available on the APIs for programming native apps. In contrast, finding robust, comprehensive documentation for making your web app compatible with any given mobile platform is not so easy, and you need to find it for all platforms that you want to support and then reconcile all the differences.

At least with native apps, you're mostly aiming for clear, stationary targets. Writing an app for a major platform like iOS or Android isn't that hard if you have a programming background. It's the extra hassle of distribution, particularly where App stores and external approvals are involved, that makes it such a chore compared to a web app.

I completely agree that web sites should be accessible to all visitors. The problem seems to be that the developers on many sites have infrastructure that is half a decade old and they are only making minor tweaks. It's easier for them to create a new dev group to build an app than to disturb their delicate website house of cards.

Then there is the issue of privileges available to apps vs. web sites; until the browser supports webkitUploadAddressBook({ stealthy: true }) there will be a strong incentive to develop an app.

so web developers are bad at convincing/advising their peers?

You know, since we're over generalizing to empty statements anyways.