Good afternoon and welcome to the developer tools State of the Union. Since Apple started shipping Mac OS X, we have been building up a fantastic set of tools for you guys to develop innovative Mac applications. And as all of you know, with our upcoming Xcode 3.1 release, we're going to extend that same set of mature tools, so that you can not only develop applications for the Mac, but also for the iPhone.

And boy, are we engineers here at Apple excited about the iPhone SDK. To be here from the beginning for the creation of a new development platform, to see the first applications from you guys springing to life on these devices, is really an opportunity of a lifetime, and we've been working very hard on it.

In this session, we're going to go over the entire development process for both the Mac and the iPhone. And what you will see is that our tools cover the entire development process, from the creation of your projects, to writing your code, to optimizing them and getting them ready for deployment.

Let me start out by giving you a quick overview of the major components of our tool suite. At the center of your development process is our primary IDE, Xcode. Xcode really is the hub of your entire development experience. It does everything you need from a great IDE. It is fast, it is scalable, it is customizable, and it's easy to use.

Now for designing the user interfaces of your applications, you will use Interface Builder, which is one of the tools that really distinguishes our development platform from others. In Interface Builder, you can quickly pull together UIs by just dragging objects out of the library, arranging them just the way you want, and hooking them up to the application logic you wrote in Xcode. You can even test your interfaces right from within Interface Builder without building your projects in between, which gives you truly fantastic turnaround times.

Instruments is a fantastic performance tool that is also unique in the industry. It uses a gorgeous, very clear way of visualizing performance data. With Instruments, you can look in great detail into different aspects and the different behaviors of your applications at the same time, which really allows you to understand how different parts of your application work together, how they interact with each other, and with the system.

Now, Xcode, Interface Builder, and Instruments are used to develop native applications for both the Mac and the iPhone. But we're also shipping a tool that is dedicated to the creation of Web 2.0 apps. And it's called Dashcode. In Xcode, you create widgets for Mac OS X, and going forward, also full-featured iPhone web applications that run directly in the Safari web browser on your iPhones. So Xcode is a full-featured web IDE. It's very easy to use. And it covers the entire process for creating widgets and web applications, including the deployment.

And these four applications I just described to you are just four of the many applications that form our entire tool suite. We ship tools to you that cover graphics, automation, package building, more performance tools, and dedicated file comparison tools. And this entire suite of applications is included with every Mac.

The Apple developer tools are free to every user of Mac OS X. Now let's not just talk about them, let's actually see them live and in action. And for our first demo of today, I'd like to ask Todd Fernandez to come up on stage and give you a demo for how to build a Mac application.

Thank you, Andreas, and good afternoon, developers. I'm very pleased to be here to show you how Xcode, Interface Builder, and Instruments can work together to help you build great-looking Mac applications with excellent performance, while keeping your focus on your application and not the tools. To show you how, I'm going to build a simple game called Baffle.

We'll see if some of you may recognize it. To get started, I'm going to create a new Xcode project. So I'll use Xcode's new project chooser to get started. And since the easiest way to create a great Mac application is to use Cocoa, I'm going to use the Cocoa application template.

So I've created my project on the desktop. And let me give you a little tour of the Xcode window. I have my source editor here on the right. And on the left side, the Groups and Files view shows me the organization of my project, my source code, my resources, including my user interface file and any artwork or sound I might need. and the target, which are the instructions that Xcode uses to turn my source code and resources into my built application.

So I'm going to cheat a little bit and drag in some code that I've already prepared, and some resources, and some more code. I have nothing up my sleeves, really. So now I have the skeleton of my application laid out in Xcode. I want to edit my user interface file in Interface Builder.

So here in Interface Builder, I have the file view, which contains all the objects that I currently have in my user interface. I have my main window, which I'm going to make a little bit bigger. And I can use the inspector to rename my window to match the name of my game. I seem to be having troubles with A's today.

and Interface Builder's library, which contains dozens of objects, different user interface elements that make it really easy for me to make a great-looking Mac application. But more importantly, Xcode and Interface Builder work very closely together, and Interface Builder now knows all about those classes and resources that I've already added to my project. So if I switch to the Media tab of the library, I can easily access those resources, including the background of my game. So I'll go ahead and line that up in my window, and resize the window to match.

All right, well, the next thing I need to do is lay out the actual views of my game. So I'm going to add two custom views. One for my game board, and if you look closely, you'll see the blue guidelines that Interface Builder provides to help me conform to Apple's human interface guidelines.

That looks about right. And drag out a second one for my scratchpad view. Again, using the guides to line things up and maintain the right margins and spacing. So those are the views I need, but I also need a controller object to keep everything tied together. So I'm going to drag in.

An object. And again, use the inspector, but now I'm going to set the identity of that class. What class do I really want that controller object to be? And again, Interface Builder knows all about the classes that I've already added to my project. So I can just get type completion, For my game controller object, and similarly for my two views, my game board view and my scratch pad view. That's great. I'm almost done laying out my user interface, but I still need a way to start a new game. So I'm going to add a toolbar.

And once again, take advantage of the access to the artwork that I've added to my project to add some new toolbar items. So as I drag each image-- Interface Builder is creating a new toolbar item for me. So now I have all the elements in my user interface I need, but I still need to wire them up so I get the right behavior at runtime.

And Interface Builder makes it really easy to connect each user interface element to my source code, which actually implements its behavior. So I can just Control-drag from my new game toolbar item down to the game controller and connect it up to my new game method, which will create the new game. And while I'm here, I'll go ahead and configure my default toolbar. And then connect up my views.

That's our user interface. So let's switch back to Xcode. And one more item of housekeeping I need to do, I want to actually set the icon for my application, which I can use Xcode's inspector to do. And again, this was one of those shared resources I dragged in at the beginning.

All right, well, let's go ahead and build and run our game. So Xcode compiles all of my source files and copies all the resources into the app bundle, and-- Uh-oh. You might notice down here in the bottom that Xcode now has a scary red 1 badge. I've got a build error in my project. Fortunately for me, since I'm on stage, Xcode makes it really easy for me to get right to the bug that's in my source code. I can just do Command-Equals, and Xcode takes me right to the line of source.

And I can also hover over the gutter here and focus in on just that block of code to see what the problem is, which Xcode makes even easier by providing the actual text of the error message in a message bubble right there next to the line of source with the problem, where it's pretty easy to see where the blame lies.

So let's use code completion to fix the name of that variable, and let's compile to make sure we've fixed that. So this is just a very quick demonstration of how Xcode makes it really easy for me to do the work I need to do with my source code, fix build errors, typos, and others more difficult to track down.

What's also great is Xcode makes it easy to do the work I want to do with my source code. For example, Now that I'm looking at this method, I really don't like that argument, game controller. It's so pedestrian. I think we can do something a little bit more interesting. Perhaps something that would be more interesting to my boss, Andreas.

But one of the things about making changes like that, even in the small scope like this, especially if your method is longer, is you have to make sure you get every instance and change them together, or you'll break your application. Well, Xcode 3.1 has a great new feature called Edit All in Scope that makes it trivial to make these kinds of changes safely. I can just click on one of them. You can see they're indicated right away. And then we can rename this.

Clearly a vast improvement to my program. So yeah, I'd like to pause also. I think many of you are like me. We write code because we love to do it. But when the tools make it fun, it's even that much better. So now that I'm in here and kind of playing around with my code, making it just the way I want without breaking my application, I want to get a higher level view of my class. So I'm going to go ahead and fold all the methods in the class.

And when I do that, I notice Scratchpad View. I've never really thought that was the right name for this class. But changing the name of a class is a much wider-ranging, project-wide scope change that I need to make. And of course, if I want to change it, I want to do so without breaking my application.

Well, Xcode makes that easy, too, by supporting refactoring. So I'm going to refactor that class. Bring up the refactoring window where I can see that I have a number of different types of refactorings I can do, but I want to rename. And I think that really should be score pad view.

So when I preview, Xcode analyzes all of the source and resources in my project and finds all the instances of references to that class. and then presents me with a handy before and after, which I can quickly scan through to make sure that these are the changes I want.

And in fact, if you'll notice, not only did Xcode find the references to this class in my class's declaration and implementation, as you'd expect, including changing the names of those source files to match, it also found the reference to that class in my user interface file, again, making it very easy for you to be playful and experimental with your code without breaking your application. So I'll go ahead and apply those changes to my program, and let's see if we're a little more successful building and running.

So here, I again want to pause and point out to some of you who may not have seen a game like this before that I need to connect the letters in various ways to spell words and score points. Now, you may think that I'm doing this demo for all of you, but in fact, this is just part of a very serious competition. So please, no help from the audience. So I'll start a new game, and an important part of this game is you must shake up the board very well to distribute the letters. And let's see what we can find. I like this board.

All right, 18. OK, I guess I'm relatively satisfied with that. We'll see how that does in the competition later. And that was a lot of fun, and I'm sure fun for you to watch me play. So we're done, right? We're ready to ship our game, baffle? Well, of course not. We need to optimize it and make sure it's making the best use of the system resources, from memory to CPU to the file system. And to do that, we have a great tool, Instruments.

So I'm going to quit my application, return to Xcode, and point out that I've just been running my application, which I could do again from the Run menu, but I can also choose to start with Performance Tool. And there are a number of different Instruments templates that I can choose to analyze different aspects of my program's behavior. Right now, what I would like to do is analyze it to find any memory leaks to fix those.

So when I choose the Leaks template, Instruments will launch my application again and begin gathering data about the object allocations. So we can start a new game and shake it out. It looks like we've got a leak already. That's trouble. So let's see what I've got here. Feeling very logical right now.

And don't worry, I won't keep playing this forever. So I think that's enough data. So I can stop recording, my program quits, and now I can analyze the data in Instruments. And you can now see that on the left side, you can have as many instruments as you want to gather different types of data. Instruments library has dozens.

And then along to the right, each instrument captures data along the timeline, allowing you to very easily visually correlate how different events affect your programs and the system's behavior. Right now, what I want to do is focus in on this leak peak. And we can see down here in the detail view, each block that was leaked. And I can further explore, see what exactly has happened there, and get the malloc history.

Furthermore, I can actually get a stack trace for that allocation and look through to see if any of my code is involved in that block being allocated where I might be able to fix a leak. And sure enough, down here I see BG Sandglass View, which is the class that handles the timer.

And if I double-click on that stack frame, Instruments sends me right back to that line of source in Xcode, again, making it very easy for me to see that now I've unfortunately made a common error in Cocoa programming, where I've copied an object but failed to auto-release it. So I will fix that bug.

Again, using code completion. And let's build and go again. Xcode is smart enough to know that since the previous run, I ran with the leaks template, it ran with the leaks template again. So I can easily compare before and after I made that source change. I promise this is the last time I'll play the game for you.

So we can see it looks like we fixed our leak. Excellent. Yes, thank you. I do accept applause. But even more, Instruments makes it really easy for me to compare one run against another to see how the behavior of my application changed once I made that change in my source. So this has been a quick demonstration of how our developer tools can help you build great-looking, well-optimized applications for your Mac. Thanks very much.

Thank you, Todd. So I think this is a great demo because it really shows how well these three tools, Xcode, Interface Builder, and Instruments, are integrated and work together to create a really great experience for you guys. Our tools use a very mature foundation that we've built up over nearly a decade of shipping Macros 10, and they also use a unique approach to the development process that really make our tools stand out.

Let me explain that a little bit more, starting with our source editor. The source editor is probably the part of the developer tools where you will spend most of your time, and so we in turn spend a lot of time every release to making it better and better. We really put your code at center stage.

Xcode does everything you would expect from a great source editor. For example, it has code completion that knows everything about the Cocoa and Cocoa Touch APIs. It also has conveniences like code folding. And the editor hooks right into the refactoring engine, which really is a huge productivity feature. Refactoring allows you to make large-scale structural changes, like renaming a class, to your entire project at once in an assisted and safe way.

Now, as I said, we really believe that your code deserves to be at center stage. And so instead of creating workflows that take you away from the source code, or workflows that minimize the amount of screen real estate you can allocate to your editor, we bring the right information to you inside the editor. As you saw in the demo, when you get bit errors and warnings, we will show them to you in the form of message bubbles right in the source code next to the line that they actually occurred.

You also bring the debugging experience into the editor. When we start debugging, we roll down the debugger strip at the top of the editor, which contains all the essential controls that you need for most of the common debugging tasks, like stepping and looking at stack traces. And also while debugging, you can simply hover with your mouse over a variable or data structure to get what we call a data tip that shows you their values.

You can drill down deeply into the data structures, and you can even edit the values in the data tips without ever leaving the context of your editor. So these center stage features really mean that you can focus on your source code. You can really allocate a lot of space on the screen to your editor and not clutter the screen with additional views in Windows just to see some auxiliary data.

So Xcode is a great source editor, and Interface Builder is a great UI editor. What really makes Interface Builder stand out is that it manipulates real objects instead of generating code. Avoiding code generation means that your source stays a lot cleaner, and it also means that you can test your interfaces right from within Interface Builder without building your projects in between. Gives you great prototyping experience and very rapid turnaround times.

Now, Interface Builder works very closely with Xcode, and it accesses the same class information. So if you go into Xcode and you add a class, a method, or a variable, they would show up immediately in the design tool as well. So you can hook up your UI elements to the application logic you just wrote.

Now, one of the primary reasons why we're able to implement a great tool like Interface Builder is that we chose Objective-C as our programming language for both the Cocoa and the Cocoa Touch frameworks. Objective-C really is the engine behind Apple's frameworks and applications. Objective-C is one of the reasons why we can very quickly ship new releases of Mac OS X and the iPhone OS. The highly dynamic nature of the Objective-C language is what enables Interface Builder to work with live objects, and to have those same objects be loaded at runtime into your applications, but they get stitched together with your compiled code.

Recently in Leopard, we've begun to aggressively evolve the Objective-C language. We added mechanisms and constructs that allow you to read and write code more easily, to actually use fewer lines of code, And at the same time, benefit from faster execution time and runtime. So Objective-C2 really was a giant step forward to modernize the language. And most importantly, we added Garbage Collection. In addition to Garbage Collection, we implemented a number of features with a special focus on performance and robustness. We're going to continue this trend with Objective-C2.1 and Snow Leopard.

On top of the-- So on top of the lightweight blocks construct that Bertrand already introduced you to in the previous session, which will be very helpful when you're tackling mighty core problems going forward. We're again adding a number of features with a special focus on performance, like faster method dispatch and faster startup times for your applications.

All the Objective-C code you write will end up in a compiler at some point in time. And with Xcode 3.1, we have some fantastic news in this space as well. Because in Xcode 3.1, you get the choice of multiple great compilers. Our current default compiler for both Leopard and the iPhone OS is GCC 4.0. And in Snow Leopard, we're going to replace it with a newer version, GCC 4.2. But we're already making 4.2 available to you now so that you can get ready for a smooth transition.

The focus of GCC 4.2 is performance. It adds support for OpenMP and also implements a long list of new optimizations and improvements to the auto vectorization engine. The detailed feature set of GCC 4.2 is flying by here in the background. And if you actually know what any of that means, then you know how great the feature set of 4.2 is. And if not, that's fine. It does a lot of geeky stuff that is very good for you.

So also in Xcode 3.1, we're going to add a brand new compiler technology that we've been working on for a number of years. And it's called LLVM, which stands for-- So LLVM stands for low-level virtual machine, and the reason why we've been investing into it is speed. LLVM has a very modern, very modular code base that allows us to innovate very quickly.

It allows us to make changes very swiftly to the compiler, much more than we've been able to do with traditional compilers. So the advantages of LLVM are that it compiles code faster, that it generates code that runs faster, and it can apply strong optimizations across multiple files. So let's take a look at some numbers.

This graph shows a build time comparison between LLVM and GCC for a number of select projects in Mac OS X. What you can see from this graph is that already in this first release of LLVM, we're achieving build time improvements between 20% and 40%. And not only do we compile the code a lot faster, LLVM also runs the code faster. To test LLVM, just-- We ran a few benchmarks of some performance-sensitive areas that we know in Mac OS X. In one case, we measured the number of frames per second for video playback. In the other case, we measured the number of signing operations that OpenSSA can perform per second.

And what we found is that LLVM runs the same source, in one case 15, in the other case 25% faster. So gains like this, 15 to 25%, are very hard to achieve with a compiler. So I really think it speaks for the potential of LLVM, the high quality of code that it generates.

Now these numbers look very promising, but one thing that's important to notice is that LLVM is still an early adopter technology. LLVM simply has not seen the huge masses of code that GCC has compiled over the last several decades. And so the optimizations we implemented in LLVM might not apply evenly to all areas of your code. It's likely that you will see different results with different kind of projects. And so while we very highly encourage you to try out LLVM, just notice that mileage may vary.

We already used GCC 4.2 to build all of Snow Leopard today. So GCC 4.2 is definitely ready for you to be used. And most of your projects will make the transition to GCC 4.2 very soon when Snow Leopard comes along. So once your projects have made this transition, it's very easy for you to try out LLVM as well. We've made it exceptionally easy for you.

If you look at an architecture diagram for a compiler, We typically distinguish between what we call the front end, which is pretty much the pass of the compiler that reads in your source code, and the back end that contains different code generators for all the architectures that you're developing for.

And what we are doing in Xcode 3.1 is that we are simply sliding in LLVM as an alternative back end behind the GCC 4.2 front end. So we are reusing the parser of GCC 4.2 with LLVM. And that, of course, means for you that LLVM is fully source code compatible with GCC.

And of course, the code we generated with LLVM There's also fully binary compatible. So if you have code that is fully source code and binary compatible between LLVM and GCC, you can very easily try out LLVM and actually mix and match different pieces of code that are compiled with the two different back ends.

So we've been working quite hard on LLVM the last several years, but so have many other engineers outside of Apple, because LLVM is open source. And you find the community website here at llvm.org. And so we regularly contribute our version of the compiler to the community, but we would very much appreciate your help as well. In fact, I believe that LLVM is a tremendous opportunity for you as the Apple developer community to really shape the future of our compiler technologies and to make the compiler exactly into what you want it to be.

If you go and visit this website, you will also find that we've begun work on another project, which we call Clang. Clang is intended to be our future LLVM front-end for C languages, for C, Objective-C, and C++. And Clang is going to open the door to a bright future for us. Clang is designed from the ground up to be extremely lightweight and to run inside the Xcode application. And not only will that give us dramatically improved compile times, it will also allow us to create a brand new light-speed indexing and refactoring engine.

So the compilers in Xcode 3.1 are GCC 4.0, GCC 4.2, and LLVM. And all of them are, of course, driven by the Xcode Build System, which has proven to be very flexible and scalable. But if you want to build a small project like TextEdit, your own suite of applications, or an entire OS like Mac OS X or the iPhone OS, the Xcode Build System will stitch them together just fine. It is really designed to make great use of modern hardware, most importantly, multiple processor cores.

This graph shows you how build time decreases with the number of processor cores you have available in your machine. So as you can see, we make great use of every core there is, and it usually pays off nicely to get your boss to buy you this fully loaded Mac Pro.

Here's a different view at build time. This graph shows how build time has decreased over the last several years when measured on the latest and greatest version of the hardware and the OS and the tools. So through a combination of improvements to the hardware and the software, we've been able to decrease build time by a factor of 15. We've literally gone from hours of compile time to minutes. Now, these graphs illustrate another very important point that I'd like to make, and that is that well-performing applications need to make best use of modern hardware and OS capabilities.

What that means for you is dealing with multiple threats and multiple processor cores. It means also to reach low power consumption goals, and it means to interact very carefully with the more and more processes running in a modern OS nowadays. There are many new and exciting capabilities that new OSes and new hardware have, but you as developers need to be aware of them, and you need to do your part in playing nice. So it's not good enough anymore to just measure the raw CPU performance of your own process when you're analyzing performance. You really need to take a holistic approach to the entire performance picture in the entire system. And that's precisely why we created Instruments.

Instruments allows you to combine multiple different types of data sources together and really monitor multiple aspects, multiple types of behaviors in your applications at the same time. You can look at CPU usage, graphics, memory, network, file system activity, and there are even instruments that are specific to individual frameworks like Core Data.

The most unique feature of Instruments is that it uses a great, very intuitive, garage-band-like UI. It uses a timeline view that allows you to visually correlate the different events and to find dependencies and interactions between subsystems in your applications that would otherwise be hidden if you would measure them individually.

And Instruments gets complemented by another fantastic performance tool that we have, which is called Shark. Shark is a very powerful profiling tool. It is great at taking CPU samples with a very, very low overhead, which makes it ideal for fine-grained performance analysis. And you can run both Instruments and Shark against the production versions of your applications.

There's no need to rebuild your projects with special build settings, no need to link in special libraries just to enable the performance tool. They work against any version of your program. They're very easy to apply against your code, and you will be surprised what they can show you once you start running them.

So that was a quick tour through our tools. And I hope it became clear that just like the consumer product space, the users benefit tremendously from Apple being the single source that delivers the entire experience of hardware, software, and services. You, the developer community, benefit tremendously from us being the single source that delivers the entire development experience. Our tools, our frameworks, our programming languages, and our hardware work together very closely to deliver a truly outstanding experience.

Now we've taken everything we've learned with the Mac about being a great platform company, and we applied it to our new platform, the iPhone OS. The iPhone SDK comes loaded with a ton of iPhone-specific tools extensions that get activated when you choose the iPhone SDK for one of your projects. Those of you that have developed Mac applications in the past are already familiar with the term SDK.

Using an SDK means that you're using the latest version of the OS and the latest version of the tools, but you're targeting the behaviors and APIs of a different version of Mac OS X. So an SDK essentially is a snapshot of headers and libraries of a different version of Mac OS X. And with Xcode 3.1, you've extended the meaning of what an SDK is.

And now if you select the iPhone OS, you not only select a set of headers and libraries, but also a completely parallel low-level tool chain. So the iPhone SDK comes with an iPhone OS, comes with a set of ARM build tools, ARM is the processor used on the iPhone, comes with a simulator application, and it comes with a number of other utilities that actually really make it fun to develop for the iPhone. So let's show that to you, too. For our second demo, I'd like to ask Matt Furtick to come up on stage and show us how to build an iPhone application.

Thank you, Andreas. One of the most amazing and exciting things about developing with Apple technologies is the fact that skills and techniques you learn for one platform translate directly to the other, because of the commonality of the system, the frameworks, and the underlying tools. So just a show of hands, how many people are actually here to build an iPhone application?

That's pretty much everyone. That's going to be a really big application store. So many of you may be sitting in the audience wondering, all right, how do I take my application and build a version for the iPhone? And to demonstrate how easy that is, what we're going to do is take the game that Todd built, and we're going to build a version for the phone. So let's build Baffle Touch.

So I'll go to my machine here, and we'll bring up Xcode, and we will create a new project. But this time, I'm going to pick from one of the iPhone OS templates. We'll choose this one, and we'll call it Baffle Touch. I also have problems with the letter A and O.

So we'll save that to the desktop. Now you'll see that the project looks pretty much the same as it did for our Cocoa project. And in fact, I'm going to use some of the elements that Todd used to start with. So because the shared code, because the core of our application is written in just pure Objective-C, I can use that in my Cocoa Touch application. And the same thing is true for the shared resources.

So we'll drag in the shared code, and we'll drag in those same images and audio files. But instead of using the Cocoa views that Todd built, I'm going to use the Cocoa Touch views that I built to put together our interface. So there we go. Our project is all set up. Let's design our interface.

So I'll open the main window here in Interface Builder, and we'll hide Xcode to make that a little more visible. And you'll see that now we're back in Interface Builder. And it may look pretty much the same as it did for Cocoa. The important element to note is that on the left here, the library is now full of Cocoa Touch views.

These are views that we can use to design our iPhone applications. We have access to all the same media that we used for our other game. In this case, we're going to use a slightly different background image, because you'll note that the iPhone window here is a little bit smaller than a Cocoa window.

So we'll drag that in, place it where we want, and now we'll design the rest of our interface. Now, for the iPhone version of this application, we used subclasses of image views rather than just regular views. So what this means is I can actually use images to lay out my interface.

So I'll drag in the same board view that Todd did. We'll put that down. I'll drag out the same image Todd used for the scratch pad. You'll note that it's much bigger than I want for my particular interface here, but Interface Builder lets me resize that down and put it exactly where I want.

So now we've got our two main views. We want to put in a toolbar. Now, for Cocoa Touch, the toolbars go at the bottom instead of the top. I'm going to use one of the features of Interface Builder, which is the ability to design views and put them back in the library for use later. So I can just drag out my pre-configured toolbar and just drop that in place. So now I have the basics of my interface.

Like Todd, we're going to put in a game controller. This is the core application logic. We'll drop that into our document here. And we need to set the custom class so that it is one of our game controllers. So now what I need to do is set the custom classes of my interface. We do that in the same way that Todd did. I'll select each view. So this becomes my game board view. This becomes my scratch pad view. And we're actually going to put in a custom toolbar as well.

So now I just need to connect stuff up. We'll connect the game board to the game controller so that we know how to get our pieces, connect our scratchpad view, the name which I don't mind, up to our game controller so that we can get our words and our score.

We're also going to connect up our toolbar to our game controller so that we can move the toolbar out of the way, since we're dealing with a smaller geometry here. And we'll also connect up one of the buttons in our toolbar to make sure that we can build a new game or run a new game. So there we go. We've designed our interface. Let's go back to Xcode and take a look and see how it works.

So here we are back in Xcode, and I want to test my application. Now I have two options to do this. I can use the simulator, or I can use the phone. To pick between those two, we would use the overview pop-up here in the upper left of the window. You can see it's already set on simulator, so I will just build and go with that.

So Xcode's going to compile my application and launch it. And here we are. Here's my game in the simulator. Don't worry, the views actually come in when we click the New button. So there it is. And of course, we do the same thing. We'll shake up our game and just start to play. Now, unlike Todd, I think we're in this presentation together.

So if you see any large words, feel free to shout them out. Anything long, like rhinoceros, or anything particularly large. But you can see, now we're going to use the Cocoa Touch interface and just start to play our game. And we can start to build more and more into our application using both Xcode and the simulator.

Now, as part of the development process, I happen to know that there is a bug in this code somewhere that I want to root out. And you may be asking me, how do I know that? Well, as Todd and I have been working on these demos and putting stuff together, we've been comparing notes.

And by and large, Todd's scores are better than mine. Clearly a bug. So, we'll go into our source code here. We'll go into the core game controller by selecting it in the Groups and Files view. And I'm going to look for a particular method. In this case, the one I'm looking for is Advanced Progress. This is a method that gets fired as the game is running, as the hourglass kind of goes down and keeps track of things.

So, our game is still running in the simulator. I'm going to take a look at some debugging information by just clicking in the gutter here and setting a breakpoint. So, you can see the little blue chevron here appears in my code. We'll now go back into the simulator and click New, start to play our game.

And you'll note that as the game starts to run, we instantly hit our breakpoint. So, now I can start looking at some information about my app. I could hover over any of the instance variables and start to use the debugging tool tips. And here's the information about my game.

Now I can go and use the debugging strip up here at the top of the editor to advance and click continue, and you'll note that my breakpoint gets hit again. Well, it's because the game keeps advancing. This is going to make it really difficult for me to figure out why my scores aren't as good as Todd's if it keeps hitting this breakpoint over and over.

But Xcode provides a feature for me to make that a little bit easier. I'm going to show the message bubble here under my breakpoint, and I'm going to set a breakpoint condition. In this case, I happen to know that the variable that's right here, current progress, is a variable that goes between zero and one as the game progresses.

So what I want to do is I want to stop the execution of my app just before it's done. So we'll say that this breakpoint should fire when the current progress is greater than 0.95. So now you'll note that when I click continue, the game should continue to run.

Three Rs, two As, one O. Thank you. See, help from the audience is a good thing. And so now we can actually go and continue to play our game. We can start to pick words. Come on, guys, you need to help me out here. I'm never going to beat Todd this way.

said. So now-- I want good help, come on. But now you know that as we get to the end of our game here, just about the time the hourglass is going to get to the bottom, we hit our break point. Now, OK, 3 is certainly not going to beat Todd's score here. What we can do, though, is go and inspect the value. And yep, here it is. Current progress is greater than 0.95.

But if I change that value in the tool tip to 0, and I continue, you'll note that the hourglass is now back up to 0. And we can start continuing on to pick some more words and to try and beat Todd. OK, yeah, yeah, we can beat Todd, we know.

So you can see it's very easy to set up debugging and work with the simulator to rapidly work with your application and to test out your interface. But I can tell you from personal experience, running the simulator is great. But running it on an iPhone is amazing. There's something really, really special about having your app running in the palm of your hand. And the tools make it really, really easy to do that.

I'm going to quit the application in the simulator here for just a second, and we're going to go back to the overview pop-up and pick device. So we'll pick this and click build and go. So just like that, we are now going to bring up two displays here, and I have this iPhone connected to this machine. So Xcode is now building this application, signing it, transmitting it over to the device. It's installing it. It's going to run it, then set up some debugging services and connect Xcode to my running app. And so here we go. Here's baffle touch on the device.

So we'll click New. Of course, you want to put in great features. So to shake, what would you do? Shake the device. And so there, the device starts up. And now we can start playing the game. So we can get great words like the, set, net. So you can start to test how your interface functions responding to touch events.

and the rest of the team. - And set a break point here. I know, you can see where this is going. So we'll hover over the score here and let's see. Size of audience, lights, performing in front of audience. 237. So now you watch on the right hand side as we continue. Our game ends and there's our high score of 237.

So albeit that this demonstration is somewhat whimsical, there's a very, very important takeaway here, which is in a very few short number of minutes, I took some source code I already had from a previous project, created an iPhone project, put together an interface, connected it up to the underlying source code, I tested it in the simulator, set up some debugging, deployed it to the phone, and then also interacted live with it on the phone to get and set different values without ever leaving my source code editor. And it's that kind of power of allowing the tools to focus on the process and allowing you guys to focus on the product that makes the solution really, really great.

But wait, there's more. If we go back to our tools for a moment, in addition to using the debugger with the iPhone, we can also use some additional tools to get some information. So I'm going to go up under the window menu and pull down the organizer. Now, the organizer is the window and the element of Xcode that provides you access to the device that's connected to this machine. We can see I have the device here selected on the left, and the summary tab shows me some basic information. Serial number, name of the unit, stuff like that. Also down here, we can see the application I've installed. There's baffle touch already installed.

Across the top are some tabs that provide useful features. For example, here's console, which is analogous to the system console on Mac OS X. We can see any output that we might need there. Crash logs, not that these ever happen, would appear here if you wanted to take a look at them.

But the fourth tab over here is screenshot. And screenshot is a really, really great feature that allows you to do exactly that. Take a screenshot of what's ever running on your phone at any moment in time. So this is great for documentation, adding stuff to user guides, taking screenshots of pictures to show to QA or engineering when stuff's not going right.

In this case, I can click capture, and I can preserve in perpetuity my wonderful score for this particular game. And even better, I can click the save as default image and select my current image. So I can save my current project. And you'll see that Xcode automatically adds it to my project and sets that as the default image for my application on startup. So now every time Todd runs this application, he will know who's the best.

So let's go back to the organizer for a second. And I mentioned before there's the application section down here at the bottom. If I expand the application, we can see that there's an element beneath it called application data. Now because we're deploying our application to the device, it means it's kind of at arm's length. And for things like output and stuff, you may have your application generate while it's on the phone. Those are really important elements for your debugging.

And Xcode allows you to get access to those. So I can select this item here, and we'll call this baffle-content. And Xcode is going to download that content from the iPhone onto my desktop here. We also handily put it in the organizer. And if I expand this, we can see here's my documents, and here's the game history file.

So this is the history that's been generated by the game as we're playing all along. Now you may actually note the scroller for this is pretty small. This file is actually pretty big, and it looks like we're logging a lot of stuff. And on the iPhone, this may be causing a performance problem while I'm running my app. map. Let's figure out if it is by running instruments.

So I will quit the running app. I'll go under the Run menu and select Start with Performance Tool. And this time, I'm going to pick System Usage. So by selecting this, Instruments will come up on my Mac here, and it's going to launch my application on the iPhone.

Now I'm just going to play this for you, and I'm not going to worry about beating Todd's score anymore. I'm just going to start selecting words. But if you watch the track view at the very top of the screen, you'll note that as I select different words here, you'll start to see different kinds of output. And this is outputs that Instruments is checking and recording while my application is running here on the device.

So as I pick here, pick some more and more words, that should be enough for now. We can stop this. And you may be sitting there in the back going, yeah, that doesn't look like that's all that much. Well, what we can do is give ourselves a little more real estate and expand this. And you can start to see that although the peaks aren't as high as you might expect for a really, really bad problem, the trough is actually pretty wide. And there's actually a lot of reads and writes going on.

I can scrub through, just like Todd did, and pick any particular event. And we see down here at the bottom, for those who are close enough, there's a lot of opens and closes. It looks like we're actually opening and closing the log file every time rather than opening and appending to it.

I can expose my stack frame view. I can go back to my view here and look at it. And sure enough, I can pick an element. And we see, yep, here it is. We are logging to the file, in fact, quite a bit in this method. So the solution here would probably be to make this a debug flag or turn down the logging until we know we have a problem. But just like that, all the same techniques that Todd used for building a Cocoa application, you guys can use for building an iPhone application. And whether you test it in the simulator or you test it on an iPhone, I bet you'll have fun doing it.

Thank you, Matt. So what you saw in this demo is that developing a Cocoa Touch application for the iPhone is just like developing a Cocoa application for the Mac. Use the same tools, the same workflows, the same concepts and paradigms. And often, you can even share code between applications.

Now we have added one tool that is specific to the iPhone, and that's the iPhone Simulator. The iPhone Simulator runs natively on your Mac. It is an application that runs the iPhone OS frameworks compiled for your Mac. So it is not an emulator, but it is a Mac-specific, fast implementation of the Cocoa Touch frameworks that give you access to the same APIs that you have available on the device.

It makes it a very convenient testing and debugging tool, with very fast turnaround times. Now, while the iPhone simulator is a huge convenience and a great time saver, we've also made it as easy to run your applications natively on the iPhone, so that you can experience them on the touchscreen, and so that you can study performance in a real-world scenario.

The Mac and the iPhone really have a lot in common. In fact, if you bring up this diagram that we had on the slides a few minutes ago, then we will see that much of the software stack is actually the same. The tools are the same. Many of the underlying frameworks in both OSs are the same. The programming languages are the same. Pretty much the entire programming model is the same.

The one thing that's different is the hardware underneath. And that, of course, has some implications for you that I'd like to go over. Let me start out by pointing out a few capabilities that are specific to the iPhone. The iPhone is always connected. It's always live in the Internet.

It's also location-aware. And it has a few sensors that a Mac doesn't necessarily have. It has an accelerometer, and it's guaranteed to have a camera. So new capabilities always means new opportunities for you guys to come up with new creative ideas. And we are very much looking forward to seeing your applications.

Of course, the iPhone also has a touchscreen and a very small form factor. That's something that you need to design for explicitly. You need to design user interfaces that use few controls at a time, and that are easily operated by a human finger instead of the precise tip of a mouse pointer. You will also want to consider supporting two form factors for the two different rotation angles of the iPhone.

Now the iPhone is really a very compact device. It is designed to fit in your pocket. And in fact, if you hold it side by side with a Mac, you will find that an iPhone is smaller than some of the graphics cards you can put in a Mac nowadays.

So while the iPhone is an exceptionally powerful device for a small mobile phone, a Mac clearly has more power to burn. And what that means for you is that you need to become good friends with instruments and shark. It is very important that you spend a lot of time tuning your applications.

You need to monitor your CPU usage, your memory usage. You need to make sure you don't use up too much storage space. And also very important on the iPhone, you need to monitor power consumption. You don't want to burn through the battery life of your users too quickly.

Now there's one more aspect that's going to impact development, and that is security. So that malicious, anonymous malicious software can't run on the iPhone. The iPhone OS will require every application to be code signed, and that's why we created the iPhone Developer Program. In addition to the actual tools, you need two more things from Apple before you can start developing natively for the iPhone.

One is a signing certificate, which will clearly identify you as the author of your own applications. The other one is what we call a provisioning profile, which you will install on your iPhones with the help of Xcode. The provisioning profile authorizes you to run pre-release versions of your applications on your own devices during development.

So let's look at that in a little more detail. Let's take a look behind the scenes. And a good way to do that is to actually take a look at the actions and events that take place when you press the Build and Go button in Xcode. So as the name kind of implies, there are two parts to this action. The first part, Xcode will build your project, will compile all your sources, and will build your application bundle. The second part, it will ask the OS to launch your application for you. And if you would be developing a Mac application, that's really all there is to it.

But if you develop an application for the iPhone and you want to run it natively on the iPhone, well, then you pretty much have to start your application on a remote computer. There are also these security considerations I just mentioned. So when we launch an application on the iPhone, there are a few steps in between.

And while the tools conveniently hide all these steps for you and make it very easy for you, it's still important to understand what's going on. So let's say we open a project in Xcode and we build it. Then Xcode will create your application bundle locally on your Mac.

And at the end of the build process, it will immediately sign your application. For that, it will take a look in your key chain and find the signing certificate that we provided you with. And it will use that certificate to apply your signature to the application bundle. And then Xcode will find your device on the USB bus.

Now the iPhone is the home of a very important kind of guy. And for the purposes of this presentation, we call him the bouncer. So the role of the bouncer is to watch over security and make sure that nothing goes wrong during the installation process. So what will happen is that Xcode will knock on the door of the bouncer in a friendly way. It will ask it for some help with the heavy lifting, which is to copy the application over from your Mac to the iPhone, just like iTunes would upload a song over the USB cable.

And the bouncer will then do what every good bouncer does, which is check your ID. So it will compare your application signature with what's specified in the provisioning profile that you installed on your phone. And assuming that it matches, the bouncer will let the application come in. It will allow the installation to proceed. Now he's a smart kind of guy, and he knows if your application has been run on your device before. If it has, it would be so kind to preserve the application's user data. So while uploading an application, we will preserve the user state of a previous run.

And then Xcode will ask the bouncer for one more favor, which is to launch a bunch of device-side services that Xcode needs to control your application. And once that's done, you fortunately don't have to talk to the bouncer anymore, but Xcode can launch your application and it can attach to the bugger.

So by launching an application on a remote secure device, it's relatively involved. The tools that we ship make it very easy for use. That for you, it's just build and go, just like you saw in the demo that Matt gave you. So that's the iPhone SDK. It contains everything that you need to develop great applications for your iPhones. But there's one thing that we haven't talked about yet, and that is the web.

So while the iPhone SDK clearly is the best way to get the most out of your iPhones, we do realize that sometimes it makes sense for you to develop a web application. Web applications have a few advantages. Among other things, they don't have any client-side installation requirements. They also make it very easy to hook into back-end enterprise servers. And so we wanted to support creation of web applications as well.

And that's why we extended Xcode, so that you can not only develop widgets that run on Mac S10, but also full-featured web applications that run directly in Safari on your iPhone. Let's show you that, too. For our last demo for today, I'd like to ask Max Drukman to come up on stage and show you how to build an iPhone web application.

Thank you, Andreas. Good afternoon, everybody. Now, can we switch the demo machine, please? Before I get started with my demo, I want to answer a question that's been on a lot of people's minds these days, and that is, who's that guy? That, my friends, is WWDC superstar Dave Payne.

Yeah, that's right. Let it out. Now, Dave Payne knows everything there is to know about WWDC. He practically invented it. In fact, when I find myself towards the end of a session, like now-ish, wondering which session I'm going to go to next, and I'm confused by all the great choices, I stop and I ask myself, where would Dave go? And that helps me make my decision. Now, I need a little bit more than that, though. I need to know what's next. So I thought I'd create a dashcode iPhone web app to show me exactly that, what's next. Let's have a look at it.

So now as Andreas mentioned, Dash Code 2 now does for iPhone web apps what it's always done for widgets. In other words, make them fun and easy to build. So in addition to all of the widget templates you expect, we now have web application templates as well. I'm going to choose the browser template and create a new project.

Now, one of the great things about Dashcode templates is that they come ready to run. That means you can put them through their paces, see how they look, feel, and behave before you customize them. And that's exactly what I'm going to do. This is probably going to start looking familiar, but I'm going to hit the Run button, and up comes, of course, the iPhone simulator. Now, in this case, we're running in the Safari browser, and you'll see we have a single list browser that is U.S. National Parks.

Each row is one park. If I click on one of the rows, the browser navigates down to a detail level. That's pretty simple. It's the basics of a browser. There's a Back button to take me back. That's pretty much it. And that's great, because that's exactly what I want to start with for my web app.

I'm going to close the iPhone simulator now. And before I delve in, I just want to orient you to the Dashcode interface. It's pretty simple. Right up here, front and center, is the canvas where you lay out the user interface of your projects. To the left of the canvas is the Navigator, which allows you access to the hierarchy of objects, or the DOM in web parlance, of your project.

And there are some important editing contexts there as well. Immediately below the Navigator is the Workflow Steps view. Now, the Workflow Steps view provides you template-specific workflow guidance and help. It's built right into Dashcode. It's really useful. But you've got me today, so I'm going to close it. We're not going to need it.

So now, if you remember when we ran my project, each row of our list was a national park. When I'm done with it, though, I want each row to be a WWDC session so that I can make my choice about exactly where Dave's going. So, session title names get a little long. So the first thing I want to do is just start working with this list, and I'm going to make sure that each row can display two lines of text.

So I'm going to just grab it in the canvas and start moving around. So you'll notice now that as I edit the one in the top row, all of the other rows are changing, too. That's because the top row is acting as a template, and any design changes I make to the top row will be reflected in the other rows.

Now, I'm also going to change the type around a little bit by bringing up the inspector. I'm going to make the text a little bit smaller, 16 pixels seems good. And because it's two lines, I want to make sure that text wrapping is on. There, I'm pretty much good to go. Now, you'll notice I left myself some space to the left of that text, and that's because I want to add an icon. Every session here at WWDC has a track, and I want to use an icon to portray that.

So I have an icon right here. This represents the Mac-specific sessions. Now, again, I dragged it into the top row, and it's reflected in all the others. Now, I've also just dragged in a static image. If I don't do anything in code with that, it's going to display a Mac icon next to every row in the list, but my code's going to know where to find it, so it can change it out for the exact right icon when I run.

So I'm pretty much done with this level. Let me have a look at the detail level. So we saw this running again. It's pretty simple. There's title, location, and description. That's exactly what I need for my project. But I want to highlight the location a little bit. Because remember, we're trying to figure out where to go here at WWDC. And it's very important to know exactly where Dave's going. So I'm going to highlight that location by adding another element. I'm going to do that by bringing up the library.

And Finding a rounded box. And I'm simply going to add it to this level and position it. Dashcode gives me guidelines to put it exactly where I want it. And now what I want to do is grab this location type, and I want to put it in the box. And I can do that simply by dragging it in the navigator. And now I've reparented it.

So now whenever that box moves around, the type's going to move with it. Pretty simple. Now I'll just style it exactly as I want, make sure it's not right up against the edge. And I don't know, I'll make it bold. So now it stands out a little bit better. So I've customized the two levels that came with my browser, but now I want to go the extra mile and add some more stuff.

And the way I do that is here in the stack layout. Now, the stack layout is a powerful new part in Dashcode that allows you to have multiple views that you can swap between with animations. So that's really the driver of the browser that we saw working in the simulator.

I'm going to go now to the attributes inspector, and we see here are my levels that already exist, list and detail. And I'm going to add two more. I want to add a home level. This will be the level that I see when I first run my web application. And I want to add a map level, because I have some Moscone Center floor maps that I want to be able to look at so I can really track Dave down.

Now, next thing I'm going to do is simply drag the home level to the top of the list, and that means it's first. As I said, I want it to be first, and now I'm going to customize it a little bit. So in the home level, I'm going to go to the Fill and Stroke Inspector now, and I'm going to make it black so it's all kind of iPhone shiny. And now I'm going to add a graphic. After all, it's all about Dave.

So I just position Dave exactly where I want him. And while I'm here, I guess I'll probably change the name of this browser. Browser's pretty descriptive, but not very exciting. I'm going to call this Hey Dave. Now, one last thing I want to do this level, I want to add a button, because I want my iPhone web app to come up just like that and give me a button that I can press on to see the list of the next sessions. That's easy enough to do by going back to the library, and this time I'm going to grab a push button.

Now I can lay this out just like I do any other element in Dashcode, and I'm going to change the text here as well. I'm going to call this "Where To." So now I've got my button. It doesn't do anything yet because I haven't told Dashcode what I want it to do, but that's pretty easy to do too.

I'm going to go now to the Behaviors Inspector. Now in the Behaviors Inspector, I can wire up JavaScript events that this object can listen to and create code that will make it do what I want it to. In this case, I'm going to give it a handler, go to list, because that's exactly what I want it to do.

Now when I hit return, Dashcode is going to create that for me because it doesn't exist yet. And not only that, it brings up the source code view, scrolls it down, and shows me exactly where I need to start adding my code to make this work. Now, you don't want to watch me type. I don't want to type either. So I'm going to show off another feature of the Dashcode library, and that is code snippets.

Dashcode comes with dozens and dozens of code snippets. And you can add little bits of JavaScript that you can add to your projects to extend their functionality. Plus, you can save your own. I just happen to have one right here called go to list, and that's the body of that function.

Now, while I'm hearing the code, I think I'll do a little bit more. Let's see. So I'm going to get rid of that and maybe change this a little bit. And well, all right, I'm going to get rid of all of it. Because I have a big old snippet that I'll just drag in right there. Now, just because I swapped in all the code doesn't mean that I didn't stay with the pattern that the template brought with me. It's just going to take too long for me to show you everything I did.

One thing I do want to point out, though, my very first function here, list controller, for you Cocoa programmers, this might be familiar to you, Dashcode is bringing the MVC code pattern to JavaScript. So we want to be able to get everybody into the way of thinking that views have controllers just like in Cocoa.

So now I'm getting pretty darn close here. I've got my button. Now, you'll remember I created a map level, but I don't have anything on there yet. I'm going to do just like I did on the list. I'm going to drag in an image. Here's a Moscone floor map that highlights the Haight-Ashbury room, which is downstairs, I believe. And again, it's a static image, but my code is going to know where to find it, and it'll swap it out.

Now, the one thing I don't have yet is a way to get to the map level. You'll remember that on the detail level, I called out the location. So I figure as long as that box is telling me what the location is, I might as well be able to poke on it and see the map, right?

So I'm going to turn that box into a button as well. And that's easy enough to do by simply wiring up the onClick event. In this case, I'm going to call it GoToMap. Now, if you notice, Dashcode is now auto-completing GoToMap. Now, GoToMap was part of that big hunk of code that I dragged in. But as soon as it was there, Dashcode made it immediately available for me to wire up to, and code completes to it. So now when I hit return, instead of creating a new function, it's simply wiring up to that existing function.

All right, I swear we're getting close here. Dave must be around here somewhere. So what I need to do now is, you remember I dragged in one icon and one map. Now I just need all the rest of those so I don't get any missing images. I have those right here. Here are the rest of my icons and all my maps. I'm going to simply drag them from the Finder into the Images view.

Now, the images view is in the files view, and that shows all of the files of your project. There's one more file I need, and that is my data source. And it's a JSON file, which is a type of XML pretty common on the web these days, and that just has all of the sessions in it. So my code knows where to go to find that, and we're going to display our sessions. So, who wants to bet that this will work? Anybody? Probably not. Let's hit run, see what happens.

So there we go. Now I'm running in the simulator again. There's Dave. I'm going to ask the age-old question. There we go. Here are our sessions. Those are the sessions that are coming up immediately after this one. Now, I know that Dave is secretly an IT guy. And so I think he's going to want to go to the getting started with Mac OS X administration. Sorry, Dave, if you're here. I didn't mean to out you, but what are you going to do? So that's in the Nob Hill room, and there's my map to it. OK, so you know-- There, it works.

Now, I have to say, though, that was too easy. I don't think I even had to ask where Dave would go, since I know he's a closet IT guy. But what happens tomorrow or the rest of the week when there are a lot more sessions going on? I have my work cut out for me. I'm not sure if I'm going to be able to do it. Luckily, I can test it in Dashcode. I don't have to wait till tomorrow to see it.

I'm going to use a feature of the Dashcode Debugger now to change the date so I can see what things will look like tomorrow. Now, the Dashcode Debugger is a full-on JavaScript debugger, lets you set breakpoints, pause and resume your code. You can evaluate your variables, check your stack frames, all kinds of interesting stuff, including use a JavaScript evaluator. Now, the evaluator is a full-running console that allows you to interact with your code while it's running.

Now, I'm going to drag one last thing now from the library, and that is my reload sessions. Now, reload sessions is my function that goes and fetches the data and populates the list. But now I'm just going to pass it a parameter of tomorrow so I can see what I've got cut out for me.

Hit return, and now you see, well, that's going to-- That's not going to be easy at all. There's two IT sessions, for one thing. That's going to be tricky. Now, even more tricky is, well, how am I even going to do this tomorrow? I've got my iPhone web app here running in the simulator, but I want to have it in my phone with me.

That means what I want to do is I want to take this project, I want to deploy it to a web server so that I can hit it over the air no matter where I am. Now, luckily, of course, I'll bet you can guess, Dashcode makes that easy, too.

So now if I go to share, I can tell Dashcode where I want this project deployed. So I'm going to send it over to a web server that is going to know where to pick up the files and send them to my phone so I can hit them in the browser. Now, Dashcode allows you to save them to servers that use the WebDAV protocol. You can save it to your .mac, or is it .me now? I don't know.

You can save it to your .mac account. Or in this case, I'm just saving it to local host. So that's the web server that runs on this machine. It's the web server that comes with every Mac. I'm just going to make sure it's named the right thing, WWDG, and I'm going to click the deploy button. So that went by really quick.

There's not much data in my project, and of course, I'm deploying it locally. So that went really probably faster than many of you could see. Let's see if it made it. So now on my device, when I bring up the Safari browser, Let's make sure that we have a nice clean page.

And I have a bookmark right here that I made earlier, just a bookmark, and let's see it live and running. All right, there's Dave. So now tomorrow I'll be able to ask. It's, of course, telling us what's going on today. There's my detail. There's my map. All working right over the air.

So there you saw it. Dash code from end to end, getting you started with great templates, allowing you to very easily extend the user interface and the code of your projects, and even going as far as deploying it to your web server. So the whole thing from Dash code. Thank you.

Andreas? Thank you, Max. So Dashcode allows you to build some great web applications for your iPhone that feel just like native applications. It covers the entire process-- design, simulation, debugging, and even deployment. The new Dashcode also knows everything there is to know about Safari on the iPhone. When you actually simulate an application from within Dashcode, it will start the iPhone simulator, so that you can test your application in the mobile version of Safari.

It also knows how to hook into the hardware-accelerated transitions and animations that we saw in the demo. It knows about viewport options that determine the scaling factor when you rotate the device, and it has a home screen icon editor. Dashcode really is a full-featured web IDE, and as you kind of saw, it's a lot of fun to use. Thank you.

So here are our four major tools one more time. All of these tools now support creating applications for both the Mac and the iPhone. And that's, of course, a huge opportunity for you guys. Learning about the tools and APIs of one of the platforms means that you automatically learn about the tools and APIs of the other platform as well, which enables you to develop for two of the fastest growing and two of the most exciting platforms in the world.