I'm Richard Williamson, and this is Getting Started with Development for Safari on iPhone. So just about one year ago, we introduced the iPhone. And along with the iPhone, Safari, the best mobile browser. Since then, you all have been really busy. In fact, there are now over 1,700 web apps for the iPhone. This is really amazing. So I want to remind you that Safari is a multi-platform browser. It runs on Windows, OS X, as well as the iPhone and iPod touch. And behind Safari is a shared web engine. That's WebKit.

With iPhone OS 2.0, we're bringing Safari up to a compatibility level with Safari 3.1 on the desktop. That means if your content works well in a 3.1 browser on the desktop, it will work well on the iPhone, too. In this session today we're going to talk about two things. We're going to talk about what you can do to enhance and optimize your web content for the iPhone, and we're also going to talk about what's new for Safari in iPhone OS 2.0.

So let's get started. But first I want to point you at developer.apple.com/iphone. This site has a great dedicated web app development section, and I encourage you to take a look at that site. There's a lot of really great video tutorials and other material available. So what can you do to enhance and optimize for iPhone? There's a lot of things, and I'm going to run through several here today. First, let's focus on the screen size. It's pretty obvious, but the iPhone has a much smaller screen than a desktop or laptop, and that has some consequences.

Typically on the desktop, you can resize a window, and that will cause a document to reflow. So the appearance of the document is very much dependent on the width of the window. Another issue that we have to be concerned about is the scale of the document. Document scale doesn't change on the desktop, but it does on the iPhone. So in fact what we do on the iPhone is by default we'll scale your content to a width of 980 and then scale it down to fit on the iPhone.

You can control both of these properties, the layout size as well as the scale, using the viewport meta property. The most important thing to set here is the width. And usually the height of your document is dictated by the layout width as the document flows. So typically, you only need to specify the width and not the height, and the height will be calculated.

Additionally, you can set the initial scale of your document. By default, as I said, will scale to fit, but you can choose to set the scale to 100%, 200%, or even smaller than 100%. And you do that with the initial scale property. You can also specify a minimum and a maximum scale that will be used for the pinch and expand gesture. And finally, you can turn off scaling entirely using the user scalable property.

Here's a couple of examples. The first example is a typical viewport property that you'd use for the iPhone or the iPod touch, and it looks like this. Here we're setting the content width to device width. Device width is a special keyword that will be the width of the targeted device. Now on the iPhone today, that typically is 320 pixels in the portrait orientation and 480 in the landscape orientation, but that could change.

Here's another example. Here we're setting the width to be hard-coded at 320. And we're turning off user scaling, and we're setting an initial scale of 1.0. That's 100%. If you have a typical website but not a web app, you want to set the width, the layout width, to be the width that you designed your document to fit. So that's commonly like 1024. Okay, so that's screen size. Setting the viewport probably is the most important and also the easiest thing you can do to enhance your content for iPhone. Now I'd like to talk about text scaling.

So by default, when we render content on the iPhone, we'll scale up the text size beyond what CSS specifies, such that the text is legible after the double-tap gesture. So what that means is when you double tap on an element, it will zoom in, and we want to make sure that you can actually read the text at that size.

This works really well. In fact, most people don't even notice it. But sometimes it can perturb the layout of your content, so you want to turn it off. And you can do that with the WebKit text size adjust property. One of the most common things to do is to set this value to none.

In this example, we're turning it off for the body element, which means the entire document will have text scaling turned off. The default is the auto value, and as I said, we'll do this automatically by default when you load web content. Finally, you can specify a fixed percentage to scale up all of the text on the page.

Here are some examples. In this case we've loaded the Apple.com news site and we've zoomed in to a couple of paragraphs of text. And you can see here on the left that the text is barely legible. So the default behavior is to scale up that text so that you can actually read it.

And finally, you can specify a fixed percentage to scale up. It's pretty rare to use this property or this value, but you can if you so desire. While on the subject of text scaling in DoubleTap, I just want to make a note about design. The way DoubleTap works is to select an element on your page and zoom in on the element to magnify the contents.

In this case, we have a layout where the text fills the entire width of the page, so there isn't really anything we can zoom in on. If we did zoom in, you'd have to be scrolling left and right. So an alternate design is to do something like this: break your content up into smaller blocks, and this enables much better DoubleTap experience.

Okay, that's text scaling. Next up are media queries. Media queries A powerful mechanism that lets you select alternate style sheets based on device properties. So you can specify or you can load a single HTML source file using a media query. Offer up alternate style sheets, in this case desktop.css or mobile.css.

So again, media queries allow you to select distinct CSS based on device properties. The most common of which is the media type. Media types are things like screen, print, or handheld. The iPhone supports the screen media type. We don't support print or handheld. A lot of people ask us why we don't support the handheld media type.

The reason is that a lot of existing content out there assumes that a handheld device doesn't have a desktop caliber browser. The assumption is that it's going to be a dumbed-down browser. So we decided early on that we would support the screen media type and not the handheld media type.

Some other properties that you can query are things like the device width and the device height. So here's an example of a media query. I'm not going to go into a lot of detail about media queries, but here's one example. In this case, we're selecting for the screen media type and for a device that has a maximum width of 480. That happens to be the width of the iPhone in landscape orientation. So only if this expression is matched will we load the small device.css stylesheet.

Here's an example of a page that's loaded on the desktop with one style, an example on the iPhone, the same HTML with a different style sheet. There's a lot of really good documentation in the specification for this at W3, and I encourage you to take a look at everything you can do with CSS media queries.

Okay, we've talked about media queries. Now I'd like to go on a little bit of a religious tangent and talk about feature detection. It really is the case today that even with standards-compliant browsers like Safari, sometimes you want to do something which is specific to a certain platform.

And what people often tend to do is they'll look at the user agent string, and they'll parse the user agent string, and based on that, they'll have conditional content. And this works, but it's really fragile. User agent strings vary from platform to platform with each release they can change. And often the code that parses the user agent string is wrong, and it'll fail when a new version of a browser comes out.

So at all possible costs, avoid parsing the user agent string, and instead, check for a feature directly. This is really easy to do in JavaScript. For example, here I'm checking for the scroll top property. And only if that property exists would I execute some JavaScript code. Here's another example. And we're checking for the type of a particular JavaScript property. And based on that, we'll again do something conditionally.

I'm going to show you the user agent string because we often get asked about this. This is the user agent string for Safari on the iPhone. Again, you don't want to use this. You don't want to parse this. But one thing to point out is that we have the iPhone platform.

The user agent string on the iPod touch is similar, but the platform is called iPod and not iPhone. And if you really must, these are two properties that you can look at in the user agent string, the WebKit version number and the mobile build version number. These are often useful for detecting subtle differences from release to release, but you shouldn't really have to do this.

Over on WebKit.org we have a great article about detecting WebKit using the user agent string. And that site includes some JavaScript that we use to dissect the various components of the user agent string. And you can use that on your sites. There's also two great articles about how to use object detection rather than the user agent string. And I encourage you to take a look at those two.

Okay, we're moving pretty quickly here. We're just going to go through these, and then we can talk about what's new in iPhone 2.0. There are some resource limits that Safari imposes on your web apps and your web content. And Safari does this to protect itself. Resources are limited on the iPhone. We have a limited amount of RAM, and we have a somewhat limited CPU.

So Safari imposes certain limits on the content that you can load. If those limits are exceeded, the iPhone also attempts to protect itself. And this is not just Safari, this is for all applications as well as native applications. The iPhone monitors memory usage, and if an application exceeds a certain threshold, the iPhone will shut it down. So even though you're not writing a native application, you still need to be mindful of memory usage. It is possible to write a page that will cause Safari to consume too much memory, and then Safari will shut down.

So what you can do to be mindful of memory usage is to load your content in the simulator on the desktop, and then use a tool like Top or the Activity Monitor to monitor memory usage of the Safari application itself. Now be sure just to load your page, not other pages when you're monitoring memory usage.

And if the memory exceeds about 40 megabytes or so, you're getting into the danger zone on the iPhone. That might be too much memory. So the ultimate test is to run your web app and your web content on the iPhone itself. And when you do this, make sure that you have all of the other background applications running, like Mail and like the music player iPod.

So what exactly are the limits? Well, we restrict text resources, that's HTML, CSS, and JavaScript to about 10 megabytes. You can have multiple style sheets and multiple JavaScript files, but it's all about 10 megabytes a piece. Images are restricted to 8 megabytes. Now that's the decoded size, not the encoded size.

So not the file size, but the size of the pixel size, which is calculated by multiplying the height times the width times 4. 4 because we have 32 bits per pixel on the iPhone. You can still use pretty big images. 1024 by 2048 is the maximum image size. That's pretty big.

If you use the JPEG image format, we can render even bigger images using JPEG subsampling. So JPEG subsampling allows you to take multiple pixels and collapse them down into a single pixel. Animated GIFs are limited to 2 megabytes. So here again the calculation is height times width times 4 times the number of frames in the animated GIF. So this, for example, would be a 32-frame animated GIF that's 128 by 128. Pretty big. And finally, the Canvas element is limited to 8 megabytes for its backing store. So again, that's 1024 by 2048, a pretty big Canvas element.

So in addition to those memory limits, we have execution limits. And that's because the iPhone is all about direct manipulation and trying to maintain as much as possible the experience of the user interface being very fluid. And if you execute a lot of JavaScript, that takes away from the fluidity of the user interface. So for each entry point into JavaScript, that means for each event that you receive or each timer that's fired, you get 10 seconds to execute. And beyond that, you'll receive an exception and your JavaScript code will stop executing. This is up from five seconds in 1.0.

Additionally, your scripts may be paused, meaning that you may stop receiving events, stop receiving time events, and this happens in a couple of scenarios. First, when your window becomes inactive because it's placed in a background tab. And second, when Safari is not active. So if the user hits the home button, it goes to the home screen and switches to another application, even though Safari still runs in the background, your JavaScript execution is paused.

However, JavaScript execution is not paused during media playback. So you need to be sure that if you do have a website or a web app that's playing media, that you don't do too much activity in the background with your JavaScript code. Okay, that's resource limits. And again, the best thing to do is actually run your content on the phone with other applications running, and be sure that Safari doesn't get shut down because of memory consumption.

Safari supports all of the standard dialogs and windows. Windows are open. You can target these by name. You can have a maximum of eight windows open at any one time. We support the alert JavaScript dialogue, the confirmation dialogue, and the prompt dialogue. They look like this. We don't, however, support the show modal dialog function yet on the iPhone. We also don't support printing, because we don't have printing on the iPhone yet.

In addition to HTML, we support the Microsoft Office document type, so that means Word, Excel, and new for 2.0 is PowerPoint. These render like this. Alternatively, and I think much better, we support iWork, and these look beautiful. Here's pages, numbers, and keynote. In fact, the keynote presentation there is this very presentation, and it looks great on the iPhone. Additionally, Safari on iPhone has great support for PDF documents, including paginated PDF documents like this one.

Okay, so we've talked about Windows and Dialogs, the supported content types. Now I'd like to mention a little-known feature of Safari on iPhone, and that is the debugging console. If you go to the Settings application and select Safari, right at the bottom there is a Developer tab. You click on that, and it takes you to this panel, and there's a single switch to turn on the debugging console. When you turn that on, the debugging console will be available in Safari, and it'll look something like this. It will show you HTML parsing errors, as well as JavaScript syntax errors, as well as exceptions.

Additionally, you can log to the console using the console object. You can use console.log, which is equivalent to console.info. Console.Warn and Console.Error. And for each of these logging types, they'll be badged with a different icon in the console. Sometimes this is a really useful debugging technique for the iPhone. Okay, next up I'd like to talk about events. And this is the last topic before we get on to what's new in iPhone OS 2.0.

So on the desktop you have a mouse or you have a trackpad, and along with that you get a cursor. And the cursor is used for things like moving the scroll bar up and down, for resizing the window, for moving the window. That's great. It's really useful. But on the iPhone, you don't get a cursor. Instead, all input is touch input. And Safari uses touch input to provide an experience of direct manipulation, meaning that you can pan the page around and you can zoom in or zoom out.

So how do we deal with mouse events? Well, Mouse events are sent to your content, and we want to send mouse events to your content because there's a lot of existing content out there that assumes they're going to receive mouse events. Mouse events are sent when you tap and release your finger, but they're not sent until you actually release your finger. When you do release your finger, you'll get a mouse down, followed by a mouse move, followed by a mouse up, or a corresponding click event. So again, these events aren't sent until the user stops interacting with the page.

Similarly, scroll events are sent to your content, but not until the user stops interacting with the page. So as the user is panning around, you don't receive scroll events. But when the user releases his finger, you'll get a scroll event. The reason for this is, again, that we want to maintain that experience of direct manipulation.

There's a little-known event that we send, the mouse wheel event, and there's a gesture that is used for the mouse wheel event, and that's a two-finger scroll. So if you have a scrollable region like an overflow region, and you scroll with two fingers, you can move just the scrollable region, not the entire page, and that will generate a mouse wheel event.

We also send an orientation change event. This is something which is specific to the iPhone, and we send this event when you rotate the device from portrait to landscape, or any orientation for that matter. And of course we also support all of the typical form and document event types: blur, focus, load, unload, reset, submit, change, and abort. The iPhone doesn't currently have copy and paste, so we don't send those events, nor does it have selection, so obviously we don't send those events.

One bonus topic before we talk about what's new. That is link handling. The iPhone obviously is a telephone, so your web content can include a tel link, and they look like this. One thing to point out about telephone links is that if you don't include a telephone link around something that looks like a telephone number, Safari will detect that and add a tel link on your behalf. So existing content will actually support tel links.

If you embed a mail link in Safari, we'll actually bring a sheet up inside Safari rather than going to the mail application. So the user can create a mail message and go directly back to Safari. And finally, if there is a Maps.google link in your content that is a form like this, we will send that to the native map application rather than loading the page.

Okay. So we've gone over the essentials that you need to know to enhance and optimize your content for the iPhone. It's a relatively small number of things that you can do to make your content work really well. But for iPhone 2.0, we've added a lot of new capabilities that I think are going to take web apps to the next level.

So I'm going to talk about four topics: improved performance, touch and gesture events, CSS visual effects, and the toolset with the iPhone SDK. So first up is improved performance. We heard pretty loud and clear that JavaScript performance in iPhone 1.0 wasn't as good as it could be. So we put a lot of effort into improving the speed of JavaScript.

And I can tell you, it's much better. We also heard that you wanted better bandwidth, so we have 3G that was announced yesterday. And also, we thought about what other resources we could bring to bear in rendering web content on the iPhone. So we added hardware acceleration, and I'll talk about that in detail in a few slides.

So here's some benchmarking numbers. A lot of numbers, but suffice it to say, shorter is better, green is better, and these bars are really short. This compares iPhone 1.0 to iPhone 2.0. This is astounding. We're six times faster on average for the SunSpider benchmark. This is a benchmark that you can access at webkit.org. Now, unfortunately, you can't run this benchmark because, remember a few slides ago I talked about the 10-second JavaScript execution limit? Some of these benchmarks take longer than 10 seconds. So we disabled that limit to run this benchmark. But trust me, it really is six times faster.

There's another benchmark out there that you can run on your iPhone. This is Craig Hockenberry's Furbo.org. It's called Benchmarking in Your Pants. And he specifically designed this for the iPhone. And again, shorter means better. And these short green bars are really short. So from 1.0 to 2.0, on average -- or not on average, these results vary from 4 to 15 times faster. This is really astonishing. Fantastic improvement.

So you don't have to take my word for this. I thought that these results were so astounding that we could do a bake-off live comparing iPhone 1.0 with iPhone 2.0. I'd like to ask Chris to come up and show you that. Can you hear me? So what I'd like to do is run two side-by-side performance tests to show how much faster we've made Safari on iPhone OS 2.0 than 1.0. So the first test is a modification of a page that Craig Hockenberry set up at Furbo.org. This is one of the sites that Richard just mentioned.

And this test basically runs through a set of JavaScript operations, and it times it, and we'll see who finishes first. So on the left is 1.0, and on the right is 2.0. Now these are original iPhones. There's no difference in the hardware. This is solely a software comparison. So let's see who finishes first. Ready? I gotta just do this at the same time here. One, two, three. So as you can see 2.0 is done in 2.5 seconds, which is pretty amazing. And 1.0 is still chugging away. Still working. And it's done.

So as you can see, we're five times faster in this particular test, which is huge. Imagine what this will do for your web apps. So let me load this next test, which is more graphical. This test is more graphical. It basically uses the Canvas element and JavaScript and takes a set of complex equations and graphs them out. And let's see who finishes first. So 2.0 is chugging away and 1.0 is visibly behind already. 2.0 is 75% done. 1.0 is done in 17, 18 seconds, basically. 1.0 is trying to make it through its way.

Almost. Almost. Done. Almost. In 37 seconds. So in this particular test we're twice as fast. So I want to stress that your web apps don't have to do anything to take advantage of these performance improvements that we've made. So the number one feedback we got when the iPhone first came out was that JavaScript performance wasn't good enough. And I think we heard your feedback, and we've delivered. Thanks.

It's astonishing. It's really great. And we haven't finished. Okay, what about page load? Well, the big news yesterday was 3G. and 3G is great. It's a big improvement over Edge. Here's an example of two sites, Page Load Times, Apple.com and Microsoft.com. And again, the shorter bar is better. We're pretty good here. We're about two to three times faster. But the observant people out in the audience might notice that there's a big delta for Apple.com and a smaller delta for Microsoft.com. And why is that? and was optimized for the iPhone, not at all.

and it's not because Microsoft.com doesn't know how to build a website. But let's take a look at it in more detail. To explain this difference, I need to talk about the interfaces that are available on the iPhone. The Edge interface is moderately fast, but has high latency. The 3G interface is much faster, but it still has high latency. and the Wi-Fi interface of course is really fast and has low latency. These tubes are not to scale.

But the important thing to note here is both of the cell technologies have high latency. What that means is from the moment you initiate a request to getting back the first data, there's a significant lag time. With 3G, once you initiate that request and start getting data, it comes in much more quickly than Edge, but there's still a lag time before you get the first data. This has implications for how you build your websites.

So if we go back and look at Apple.com and Microsoft.com, the total amount of resources loaded by Apple.com is 610K, whereas for Microsoft.com it's 494K. So Apple.com is actually bigger than Microsoft.com. But that's not so interesting. The next two lines are more interesting. The number of resources at Apple.com is 31 compared to 55 at Microsoft.com.

And the average size of each of those resources is 20K at Apple.com versus 9K at Microsoft.com. So Microsoft.com has many more smaller resources. And what that means is much more latency. And you add all that latency up, and it makes the page load times worse over cell networks.

Now, Safari does an awful lot to try and preload content to keep the pipe stuffed, and this works pretty well. But sometimes you can write content that thwarts that preloading mechanism. In particular, if you write JavaScript that does a lot of dynamic loading,

creates sites with fewer resources that are larger, and trying to avoid dynamically doing things like document.write that will in turn then load another resource.

With the developer preview of Safari 4 on the desktop, we're giving you some tools that will help you analyze your site and how it behaves on a cell network. In particular, there's a network tab in the Web Inspector, and that will let you sort the resources that are loaded by latency. This is a really powerful tool. It'll show you for each of the resources when the request was initiated and when the load first begins.

So by looking at this graph, you can see that some of these things take an awful long time to load, to actually begin loading. The Web Inspector also has the ability to sort by start time, which is also useful. And there are several other ways you can sort the data, so you can slice and dice it and really get a sense of how your site is performing.

There's a whole session dedicated just to performance, and I strongly recommend you go see this. It's on Friday at 2:00. Okay. So that's performance. We have improved JavaScript performance dramatically, and we now have support for 3G, and you can create content that really takes advantage of 3G. I mentioned hardware acceleration, and I'm not going to talk about that just yet, but we'll get to that in a future slide. Now I'd like to talk about touch and gesture events.

What are touch events? Well, UIKit, the native user interface framework, supports touch events. So we thought, well, why shouldn't web content be able to support touch events? So we added a new event model.

Touch events, because they send immediately, allow you to create interactive rich content.

In addition to touch events, we support gesture events. Gesture events allow you to do things like pinch and expand as well as a rotation event. These gesture events combine both scale and rotation, so in the same event you could rotate an element and expand it. The scale property is sent as a percent change from the start of the gesture, and the rotate property is a delta angle from the start of the gesture.

And as I said, both properties are sent with every gesture. So the best way to get to know how to use touch and gesture really is with a demo. So I'd like to ask Chris to come back up and show us a demo of touch and gesture events.

So the first thing I want to do is compare dragging within a web page with mouse events versus touch events. So what we have here is a really, really simple web page, and this web page has a box, and tapping on the box -- well, not tapping, but rather clicking on the mouse and dragging the box around basically drags it within the web page. Pretty darn simple. So let's try to load this page on iPhone.

So this page uses mouse events to drag something on the page. As you can see, you can't drag it. Basically dragging pans the page and clicking this box highlights it, brings out the callout, which is not what the author intended. So let's load a version of this page that uses touch events. So now I can drag it within the page. As you can see, the frame rate is pretty awesome. And this page uses gesture events, too, so I can take two fingers to scale it, and I can rotate to twist it. And everything is pretty darn smooth.

So imagine how you can use dragging events -- excuse me, imagine how you can use touch events to drag and use gestures within your Web page. It will be pretty awesome. So let me do something that's a little more interesting than just, you know, dragging a box within a page.

And here's this guy. He looks maybe familiar to you, I don't know. He's kind of sweaty, looks like he's been yelling and dancing around a lot, I guess. So let's take his clothes off, of course. We can actually independently move two pieces of clothing. And I hope this doesn't make you uncomfortable here. And this top looks kind of nice, so let's put that on here. Some nice tights. and there's a little tutu here. This tutu looks like it doesn't really fit so I can actually use gesture events to scale it and put it on him nicely.

Isn't that nice? So I hope that wasn't too weird, and I hope this encourages you to use touch events and gesture events in your web app. Thanks. That's awesome. Great fashion sense, Chris. So you may have noticed that the frame rate was really good. How was that achieved? Actually, before I move on, there is a session coming up talking entirely about touch and gesture events, and that's Wednesday at 10:30. And I encourage you to take a look at that.

We're getting back to the demo. How did Chris achieve that amazing frame rate? Well, In addition to the CPU on the phone, there's a graphics processing unit, a GPU. And up until now, it's been impossible to take advantage of the GPU in your web content. We take heavy advantage of the GPU for native applications and UI kit. Every UI view is a layer that can be animated and manipulated by the GPU. But your DOM elements on a Web page up until now, it hasn't been possible to accelerate those with the GPU. Well, that's what CSS visual effects is all about.

So let's take this very simple example. The white page represents a web page, and the orange rectangle represents a div. A very common operation is to animate this element from one position to another. And the way you would typically do this is with JavaScript event handlers, maybe based on a timer, and for every frame in the animation you would modify CSS properties.

This works quite well. It's a little bit tedious to program, and on the iPhone the performance isn't so great. So what if we could eliminate JavaScript entirely from this animation? And what if we could describe the animation entirely with CSS? Well, that's what CSS visual effects are all about. There are three components of CSS visual effects that I'd like to talk about. First are transforms.

For any element on your page, you can apply a transform. So a 2D transform is scale, a translate, or perhaps a rotate. Here we've rotated an element. You can also imagine translating an element. But on the iPhone, we're not limited just to 2D transforms. You can apply a 3D transform to any HTML element. Now this is mind-blowing. This is fantastic. It opens up a whole new set of possibilities for web applications.

In addition to transforms, CSS visual effects gives you the ability to transition between many CSS properties. So, for example, I could apply a transition Oops, that's a transition, yeah, between capacity values to make an element appear and disappear. I can also apply transition to transforms, effectively animating an element. So thinking back to that original orange square that we moved across the page, that is achievable entirely with CSS transitions and transforms.

Additionally, CSS visual effects support animations. Animations are transforms across a more complex path with keyframes. So, for example, I might want to animate this element along a path like this. So we think that these capabilities are going to allow you to create web apps that have never been seen before on a mobile device with high performance, in fact, performance that's as good as a native application.

Transforms, Transitions, and Animations. And most of these behaviors are hardware accelerated. So that means once you set up the CSS, you don't have to execute any JavaScript. and the GPU will animate the element across the page. And when you combine CSS visual effects with touch events, you can create highly interactive DHTML. So I'd like to ask Chris to come back up again and give you a few demos of what we did with CSS Visual Effects on the iPhone.

So the first thing I'd like to do is show a practical example of using CSS Visual Effects. And then I'm going to show you four example pages that use CSS Visual Effects from simplest to most complex. So you may be familiar with this page. It's the iPhone version of dig.com. It's a great Web site. They're actually one of the pioneers in creating Web apps for the iPhone.

And what they've implemented on this site is a browser-like view, a sort of hierarchical browsing view. But the issue here is the frame rate. As you can tell, it's kind of suffering. It's maybe getting three or four frames going from one place to another. This page basically needs to use CSS Visual Effects to get the frame rate up. So let me load another page which is a little It does the same sort of browser-like UI.

This is a page that, you know, just shows Apple's products. And clicking through here basically gets that awesome framework that we all want in our web apps. And let me stress that this is not a native application. This is all inside of a web page. So now you can get this sort of native UI look, but also the native UI performance in your web app, which is pretty cool. Okay, so the next thing I want to do is show four different example pages that use CSS visual effects from simplest to most complex.

And this page is really simple, it just displays this card, but tapping on the card, gives that sort of dashboard-like 3D rotation effect. So you could imagine doing this in your web app for something like a dashboard widget or perhaps something like the track list in the iPod app. Okay, the next thing is a slideshow. And this slideshow uses a bunch of CSS visual effects transitions. So I'm just going to tap through these really quickly. As you can see, they're pretty cool. Try to think about how you could use these in your app.

Let's go to the next one. The next page is something called Text Tower. And what you see here is basically four divs with text, and each div is rotated from each other. And there's also two animations going on here. There's one animation which makes the whole tower rotate a little bit, and then there's another animation which makes the whole tower sort of fly around within the page.

Now, I'm not encouraging using this type of UI, but I think it's a good example of using CSS visual effects. And again, this is not like a plug-in or anything. This is all done inside of a web page with CSS visual effects. I can even double tap. And that works as well. It's all HTML and CSS visual effects.

It's pretty cool. The last thing I want to show is a page that you could see at Apple.com. It's not actually from Apple.com. It's just an example page. But this is an example of using CSS visual effects within the context of a normal web page. And on this web page is a section which uses CSS visual effects to do a sort of QuickTime VR-like thing. This is not a plug-in. This is all done with CSS Visual Effects. What you actually see here is a set of images that create a 3D cube, and our perspective is with inside of that cube, and I'm just simply modifying that perspective.

So basically you can get the performance and behaviors in native apps in your web apps as well. Thanks a lot. Thanks Chris. This stuff really is amazingly powerful. There are several sessions that I'd like to refer you to. One coming up, Enhancing Your iPhone Web Applications with CSS Transforms and Animations. It's a fantastic session. It goes down deep into CSS visual effects. It's a great session. There's another good session coming up, Building an Advanced iPhone Web Application. It's a hands-on session, and during that session we'll build a very sophisticated app, and you can follow along.

Okay, we've talked about performance, we've talked about touch and gesture events, and CSS visual effects. For iPhone 2.0 and the iPhone SDK, we're also introducing some great new tools. The simulator in particular. The simulator isn't just for simulating native applications. It's great for that, but it also includes Safari on iPhone.

This is the same engine that runs on the iPhone. It's exactly the same code, just compiled for OS X. So the rendering you get in Safari in a simulator will be exactly the same as the rendering you get with Safari on the iPhone. It's a great way to test your layout, to test your content.

The simulator also lets you support or lets you test gestures. So, for example, you can do the pinch and expand gesture. You can also do double tap. However, the simulator doesn't simulate speed, doesn't simulate view speed, and it doesn't simulate bandwidth. But there is something we can do to simulate bandwidth. Imagine if this is your big fat T1 pipe or your DSL pipe.

What if we can shrink it down and simulate a cell interface? Well, you can. There's a tool that's been included with OS X for a while called IPFW, and this is a firewall and traffic shaping tool. And using this tool, you can add latency, and you can also limit bandwidth so you could simulate different interfaces.

Here's an example of a setup of IPFW to restrict all IP traffic to 50K upload, 200K download, and to add 150 milliseconds of latency to each request. So in this particular example, I'm restricting all traffic on the machine. So mail is going to be slow as well as Safari. So to reset the configuration, you use IPFW. Flush. And that will remove any pipes that you've added. You can also use IPFW to restrict based on port type, so you could restrict just HTTP traffic.

There's some really good documentation on IPFW. It's got many bells and whistles. I'm not going to go into a lot of detail, but there's a website that describes DummyNet. DummyNet is a configuration of IPFW. There's also man pages that are included in OS X for both DummyNet and IPFW.

So if you combine IPFW with the Web Inspector, with the simulator, you can really get a good sense of how your applications are going to behave on the iPhone. Another tool that we've added, or enhanced I should say, is Dash Code. Dash Code has been significantly enhanced and tuned for iPhone web applications.

And included with Dash Code is JavaScript debugging, much like debugging for Dash Code widgets. But you can debug your content inside the simulator on the desktop. It also adds support for the Web Clip icon. In a recent release we added support for Web Clips that let you bookmark your web app right on the desktop, right on the desktop or the home screen of the iPhone. You can easily add that icon with Dash Code. You can also configure the viewport. This is probably one of the most important things that you want to do for your web apps, and you can do that right in Dash Code.

Additionally, Dash Code adds support for built-in pods. These are prepackaged interface components. For example, buttons, lists, A Stack Layout. A Stack Layout allows you to have two different elements and use CSS visual effects to transition between those elements. and finally there's a browser component, very much like the browser component that Chris demoed, that's included in Dash Code.

So you can simply drag and drop it and create a web application that uses that component. I encourage you to go to a session that's coming up on Wednesday at 5:00 that goes into some detail about how to use Dashcode to develop a web app. And they'll take you through building a web app from start to finish.

So in some way we've talked about a lot of things that you can do to enhance and optimize your web apps and your web content for the iPhone. You can set the viewport to control how things layout and how things scale. You can control text scaling. You can use media queries to supply alternate style sheets.

We talked about feature detection, how to use that instead of using the user agent string. We've talked about the resource limits of Safari. And we've talked about the supported Windows and Dialogues, as well as support for Microsoft Office, as well as new in iPhone 2.0 support for iWork.

and we also talked about the debugging console. And we talked about events, both the emulated mouse events and now the new touch and gesture events. and CSS Visual Effects. We think that CSS Visual Effects is going to enable a whole new class of web content for iPhone. And finally, we've talked about tools. For more information about these technologies, you can talk to Mark Malone or Vicki Murley, our Internet Technologies Evangelists, and I've also included links here to documentation that was referred to throughout the slides.