Web Development for iPhone

To quickly test your web applications you can use http://testiphone.com in a Safari browser as a starting point

If you come across any other info that would be developers for the iPhone please add them to http://iphone.wikidot.com/ and open Wiki on iPhone's missing SDK.

If you are talking about web development for the iPhone really should mention iUI (http://www.joehewitt.com/iui/).

I couldn't help but notice that Apple stresses the important of web standards in these guidelines ... Interesting, don't you think?"

Unsurprising, *I* think ... since you asked.

Breaking standards has some advantages when you're the incumbent, which is probably why Microsoft developed a habit of doing that in the first place. For those who are trying to break into markets a level playing field is more advantageous.

Apple could tell designers to work on a suck-it-and-see basis ... which is just what people used to do, what some probably still do so, with IE. That's to say, one could code by hand without looking at what one's really doing, or code in a sub-standard tool (with or without proprietary extensions to the W3C standards) and, as you go, see if your pages will display as you intended in the target browser. If it does, fine; if it doesn't, troubleshoot in desultory way till it does. Of course, it may only display thanks to the browser's error handling and other browsers may handle your errors differently ... but, hey, that's other people's problem, and besides it's time to get coffee.

Apple doesn't suggest that. It suggests the best starting point is to use valid HTML/CSS written in accordance with the W3C's specification documents and to get interactive functionality by using widely-supported JavaScript (preferably ECMA script). Apple is right.

That's what the concept of writing to web standards *means*.

What is TUAW's problem? Does TUAW consider it a problem that web developers might, and are encouraged by Apple, to consider the needs of the specific user-agent on the device (e.g., small screen, no ability to hover) if they wish to write web apps specifically for the device? I'm not sure why that should be thought to be a problem. And in any event that has nothing to do with "web standards".

I think TUAW is trolling.

The motive is presumably to attract comments; so TUAW wins after all, since I've been foolish enough to post this.

The guy talking sounds a lot like Elmer Fudd, or is that just me?

Joe: If you use semantic markup and media-specific CSS properly, there shouldn't BE a “low-bandwidth” version of a site.

Brady, in fairness, machine-generated HTML is always crap. Maybe there are some silly mistakes in there that were avoidable, but frankly what difference does it make when the whole lot's basically garbage anyway?

I don't see a problem with providing iPhone-specific sites, if it makes your content more accessible. But in the same way as the iPhone can happily browse to standard sites - they're just not so convenient to use - you shouldn't deny non-iPhone users access to your shiny new site.

The only time I agree with denying access is where the browser simply can't support what you're doing, and no access is better than crippled access. So, largely, if you're doing something complex you can block IE6 and down. That's it.

Actually, I think most of us agreed with your basic statement this morning... that developers shouldn't automatically redirect to mobile sites based on an iPhone user-agent. No need to back yourself up on that one.

What is this post for, then? We knew Apple advocates using full, desktop-style websites. Apple's chosen not to ackowledge the usefulness of low-bandwidth sites because their marketing stance is "full internet in your pocket."

Look, man... Low bandwidth sites are great for EDGE connections, whether Apple acknowledges them or not. Keep them optional (and we all agreed on that in your last post), but they're great tools when you need them... there's no shame in using them.

I think Apple's innovative approach to web browsing works quite well all things considered. There are sites however that are difficult to use and read on the iPhone. Old school approaches like redirection will fail. What I do think is going to happen, is that smart developers and designers will eventually learn how to take advantage of the iPhone's zoom ability and develop CSS techniques that work well with it. I have observed that certain layouts work better than others with the iPhone. So, rather than draconian tactics by lazy programmers, more subtle changes will be implemented to existing sites that will optimize the experience for smaller screens with the zooming feature.

I don't think any web professional would advocate browser sniffing by any means anymore; those are archaic days. Styling for your specific device is acceptable - just like we do for aural stylesheets, presentation stylesheets, print, etc. That's done by a CSS media request; but I would agree it's an unnecessary standard for websites to design specifically for the iphone - and I'm sure it's a trendy attack at the moment.

The alternative being full web applications - BeeJive and the like require device specific CSS because the user experience is a drastic change on a touch screen device, and needs to render with that in mind.

Nevertheless, it's funny to see Apple trumpet standards. Their new site is a huge improvement (though a bad case of divitis); but many of their applications are a joke. Aperture was spitting out XHTML Strict, but with all uppercase tags and most tags not closed - 101 errors for even a junior designer. iWeb chokes on functionality for design, with abundance of code trash just like most WYSIWYG editors. They have always 'slighted' perfection, whether by ego or by deadline.

Not to say their browser isn't fantastic - IE is trash by comparison. I just think there's a handful of web developers there, some know their stuff, some older crowds maybe still in the dark ages and not pushing the model.