Hello and welcome. Today we're going to talk about some of the new installation technologies in Leopard. We're going to split the session up into four different sections. If you went to the first session on Tuesday, you might be familiar with this setup. We're going to start by talking about easier ways and better ways to create software packages using Packagemaker, Packagemaker 3.0 we've introduced in Leopard. We're next going to talk about better ways to deliver your software and your package content to your customers with a new flat package format we're introducing in Leopard, downloadable packages, and certificate signing of your packages. Then we'll cover a well-asked-for feature, home directory installs.

And then go over some changes that are coming in upgrades, like better ways to find movable software and patch packages, and some changes in the way we do receipts in the Leopard Installer. So let's get started with creating the packages. In order to create great software packages to deliver your software to your customers, you need great tools. How many out there are familiar with PackageMaker? I see a lot of you have used Packagemaker.

Packagemaker is really hard to use, and we find that a lot of our customers use Packagemaker to get started and then edit the package by hand afterwards. And in Leopard, if you've checked out the Leopard Seed, we have a new Packagemaker 3.0, which makes this much easier to do than ever before. Instead of talking about this for a long time, let's show you a quick demo.

I'm sorry. Quickly about PackageMaker 3.0. PackageMaker 3.0 is workflow focused. It allows you to create your software packages the way you create your software. It picks the best package format for you. You don't need to worry about whether you need to make a meta package or a package or a distribution. You just create your software, you create your interface, and PackageMaker will take care of that detail for you.

And it even exposes almost all the installer features that we provide, including all the features we're going to talk about today throughout the session with Leopard. And our plan is for it to have it run on 10.4 as well, the Leopard seed version of PackageMaker. So the version in the seed today does not run on 10.4, but we plan to get out a version to you guys soon that will. So let's show you a quick demo of Packagemaker, Sean.

Good afternoon. My name is Sean Kelly, and I work on PackageMaker at Apple. In this demo, we'll use the new PackageMaker to create a simple package for one application with some interface resources. So let's get started. Today we're going to build a package for Sketch, which is one of the developer example applications. So we'll launch Package Maker. The Install Properties dialog will come down, and we'll call this the Sketch package, and we'll target Tiger.

To add Sketch to the package, we can just drag it in to the contents area. And we'll see that PackageMaker has figured out that this is an application, and it's filled in some default information for us. We're also going to add some interface resources. To do that, we click on the Sketch item in the upper left corner and then the Edit Interface button. This brings up the interface editor, which is a what you see is what you get interface. What you configure here is exactly what the user will see in the installer.

To add your resources, you just pick the item you want along the left and then drag your file in. So we'll add a background image. And it doesn't look too good up in the corner, so we'll move that into the center. And then we'll also add a license and a welcome or an introduction. So now we'll build our package and we'll save it on the desktop.

And if we open in the installer, we see that we have our background image with our welcome. If we click through, we'll have our license, which the user has to agree to to continue. And if we continue to click through the installer, Sketch would be installed into slash applications. And that's how easy it is to create a package in PackageMaker 3.0.

Chris? As you see with PackageMaker 3.0, it's much easier to create your software packages to deliver your software to your customers, and it's much fewer steps than ever before. And the PackageMaker you see here today is more of a preview as we're still working on it and hope to have even more features and better functionality when Leopard ships.

So that's better ways to create your software. Now how do we deliver our software better to our customers? Most of the ways to deliver software are via a store with media, a CD-ROM or DVD. But going forward, people have been starting to deliver their software over the internet with downloads and other things. And with installer packages, they're bundles and folders.

And to deliver your software, you need to wrap those bundles with a zip file or a disk image. And that makes it very difficult for your customers to use that because they need to download the zip file, unzip the file, launch the package, throw away the zip file. Also, with downloadable content on the internet, your customers have to download large pieces of software and they may only use parts of the options of your software, may not need the entire thing.

So in Leopard, we're really improving the way you can do this. We're doing that with a new flat package format. We're gonna go over more details in a couple minutes. Downloadable packages, you can download packages while you're installing, as well as certificate signed packages. So let's start by talking about flat packages.

To do that, I want to quickly go over again what the packages are like today in 10.4. Packages are bundles. These bundles are just, you know, the CFBundle, just like the CFBundle API or NSBundle. They contain files and folders. And when you want to distribute these packages to your customers, you need to wrap them up in an archive. And they really have poor performance when you have many packages. We're really moving for our software developers, and even Apple ourselves are trying to do this, by making our software more and more packages so we can deliver more and more options to our customers.

And when you have more and more packages, with the bundled packages, the performance is really starting to get to the limit. For example, the OS install Leopard was installed with has over 100 packages, and just reading those packages as bundles takes a long time. Also, our bundled packages contain both the presentation information as well as the actual package content, the software you want to deliver.

And in Tiger, we introduced distributions, and we're trying to remove the presentation and the content and separate them from each other. With iLife, for example, you have iLife contains a special interface for installing iLife, and it contains packages within it, like iTunes and iMovie. And that presentation and the actual package content is separate.

So the new flat packages in Leopard change this by having the entire package content in a single file. So you can easily distribute the software over the internet without wrapping it in bundles, et cetera, or wrapping it inside of a disk image or zip file. They also have much better performance when having many packages.

Maybe thousands of packages or even more don't take very long to open and actually install. And also, we're really starting to move away from having presentation information in the package. And so in the flat file package format, there's no presentation information in there. We expect you to put your presentation information in the distribution scripts.

So you're probably wondering, do you have to move to flat packages? And the answer is no. Your bundle packages will continue to work going forward. They'll work just fine. And we're going to continue to support them going forward. But in order to start moving ahead and utilizing the internet and utilizing some of the new features, we'd like you to start looking into these flat packages.

We really understand that most of you want to ship your software for an operating system that's actually out. And so we understand you're probably not going to be shipping with flat packages anytime soon. But we'd like you to start looking into this technology and see how it can change the way you deliver your software. And flat packages will give you some of these things we're showing up here. And we're going to talk about a lot of these today.

So let's quickly go over what one of these flat packages looks like. A flat package uses XAR file archive format. It's an open source format. You can get more information at the Open Darwin website. I know that's going away, some of you have heard, but they're looking at places to relocate it. And Apple contributes back to XAR and any changes we make we're going to bring back to the XAR community.

And XAR is similar to a zip format where it has a table of contents and the file content and it's done with XML so we can extend what we can put in our packages in the future. And these flat packages can compress their data, both the metadata and your actual application data using Gzip or Bzip2. And Bzip2 will give you smaller packages to distribute to your customers. And of course all of this is in a single file.

Now, I just spent a lot of time earlier talking about how we're going for the separation of presentation information and your package content. Well, we have this thing called flat distributions, and that allows you to put all of your software, your software product, in a single file to distribute to your customers. You may do this with iLife, or even maybe Apple Software Update might use this to distribute all of the software update in a single file. But we may want to actually separate the content and the concepts of the package into separate packages.

So we really are trying to keep the concept of packages and the thing that we use to distribute the packages separately here. Anyways, these flat distributions allow you to put all of your software in a single file. It uses a distribution script to drive the installation experience, and it can contain all the resources necessary. And this is a great way to distribute your software in a single file to your customers.

The good news is that Packagemaker makes this really easy and will do all this work for you. So let's have Sean come up here and give you a quick demo. Sean? Thanks, Chris. In this demo, we'll take the document we created before and turn it into a flat package.

So we'll go back to the main PackageMaker interface. As Chris mentioned, to create a flat package in PackageMaker 3.0, all you need to do is target Leopard. So we'll change our target using the Install Properties dialog, which can be found in the View menu. And we'll target Leopard. If we build our package, we'll put it on the desktop again.

And if we open in the installer, we see that we have the same install experience before. We have our background image with our welcome and our license. Now, because this is a flat package, you can no longer go into the finder and control click on the package and go in and edit files by hand. So in Package Maker, we've included a tool called the Flat Package Editor, which you can find in the Edit menu. So we'll launch that.

And if we bring in the Sketch package we just created, The Flat Package Editor will show us the package contents. We can add and remove them. We can see what's there. Now, because we had resources in this package, we can see that PackageMaker has automatically upgraded this into a flat distribution because flat packages can't have interface resources. So inside the package, we have the package info file with the BOM and the payload that Chris had mentioned. We have our distribution XML, and we have our interface resources, the background, the license, and the welcome.

In addition to the Flat Package Editor, you can also use the Czar command line tool to edit flat packages. So that's Flat Packages in PackageMaker 3.0. Chris? Thank you, Sean. As you can see, it's really easy to create these flat packages in PackageMaker. We'd like you guys to start trying them out and playing with them.

So let's dig a little deeper on what these flat packages look like underneath the scenes. As Sean pointed out, there's a package info file. This contains all the metadata about the package, size information, and other things the installer can use to install the file. This package info file looks like this. It's an XML file. The information up here is not really important because PackageMaker will take care of these details. But it contains information such as the identifier of the package, which is used for upgrades, the version, where the package is going to install by default, et cetera.

Obviously, all packages need a payload to deliver your software to your customers, and so flat packages have a payload, just like the bundled packages. And that's a CPIO archive, which contains the software. And of course, the CPIO archive is compressed using the XAR container. And these archives can, just like the bundled packages, properly archive resource forks, extended attributes, type creator, icons, etc.

So flat packages also have installer scripts. Installer scripts allow you to perform an action before and right after installing of a package. These are executables, either executables or shell scripts. And like I said, they can run right before or right after a package. And they have access to the location of the installation. And one of the new things we're going to talk about a little later is that the flat packages have a model for relocating software. If your software is a bundle, an application that can move on the disk, the flat packages can find that application as it's moved.

And the flat packages also have a way in your installer scripts to run a script specifically for that application that's moved and tell the script where the application's moved so that you can perform an action before and after that location. Also, these scripts have access to other resources and other scripts inside of this flat package.

Additionally, if some of you are familiar with the bundled packages, in the bundled packages there is a pre-flight script, a post-flight script, a pre-upgrade script, a post-upgrade script, and a pre-upgrade script. There's a post-upgrade script, a pre-install, and a post-install script. And in flat packages, we've really simplified that by just having a pre-install script and a post-install script.

There's no longer a pre-flight script, which can run at the very, very beginning of the installation of your product, or a post-flight script that runs at the very end rather than just before and after your package. So if you need to do that, flat packages allow you to create a script-only package that doesn't have a payload. And you can place that package at the very beginning of your install or the very end of your install.

In the package info file, you specify the scripts using the scripts elements. And here we have four scripts. And the four scripts, the first one is just a pre-install script. And the file attribute specifies the name of the script you want to run. And of course, PackageMaker will take care of these details. But also, you see the second item is a component script.

And a component is a way we represent sub-items of your package, such as bundles and things that could move independently. And there's a post-install script for our simple app component, as well as a post-install script for the overall package. You don't need all of these, but you can have these for your package.

So you may be wondering about requirement checks. Is there a way to say that my package can only install on this system or another system? And the answer is no. These packages are only a way to deliver your software and install your software. And those requirement checks belong in the distribution script. But PackageMaker will take care of that detail for you. So if you're creating a 10-4 package, it may put requirement checks inside of your individual packages. If you create a 10-5 package, PackageMaker will automatically make sure those go to the distribution script.

So to summarize the flat packages, it's a 10.5 only technology. It's going to be used going forward for new features, and it's really a platform we're going to use to continue to improve our installation technology. It allows you to download your software without wrapping your software in zip files or disk images.

And we really want you guys to start trying them out and playing with them. Again, we understand you probably can't use them for a while, as you won't be shipping software that requires 10.5 only for quite a while. And PackageMaker 3.0 makes it very easy to use this.

So now that we have this great way to download your content from the internet using our flat packages, there's some other things we can do with downloadable packages. In Leopard, with these flat packages, we had something called a Quick Start package. And if you went to the first session on Tuesday, we kind of started to allude to this package type.

What this allows you to do, it allows you to have your software on the internet, just the distribution of your software. Your customer can download the distribution. They get to make the choices. They can see the license agreement. They can see the custom install panel, custom background, et cetera.

And once they make the choice of what they want to install, the installer will go to the internet and download only the pieces that your software needs to install with the way your customer expects. This will really save time and money for both you and your customers. And it's really bringing our install technology back to where we were, I guess, in QuickTime. A QuickTime installer back in the day used to do a similar thing.

So hopefully this will help a lot of you out. So the way this is done is by specifying a URL inside the distribution script of your package that points to a server. And Packagemaker 3.0 makes it very easy to do. So let's quickly show you a demo, quick start package.

Thank you, Chris. On this demo, we'll create a quick start package to install Sketch. So I have a PackageMaker document that I've created ahead of time that just defines some interface resources so that we don't have to do that again. To create a quick start package using PackageMaker 3.0, you drag in an existing flat package.

Now by default, if you add a package into PackageMaker 3.0, it'll read the package and it'll present it all in the PackageMaker interface. You can then make changes and PackageMaker will rebuild the package. However, what we want to do is we want to point it to a URL where the package will live. So we'll use this menu and we'll change it to downloadable package. And we have a web server running on this machine, so I'll give it a local host URL.

And then I'll build the package and save it on the desktop. Now if we get info on the package we just created, we'll see that it's only 32 kilobytes. And if we open it in the installer, We see we have our interface resources there. We have our background image and our README and our license. And if we click through and install, during the installation, the installer will go to the web server, download the package, and install it.

So the user only has to download the small 32 kilobytes to quick start their install. So that's downloadable packages in PackageMaker 3.0. Chris? Thank you, Sean. As you can see, it's really easy to use Packagemaker 3.0 to create downloadable and quick start packages. And I'm sure you guys can imagine different ways to distribute your software using this technology in the future.

So how does it do this behind the scenes? What Packagemaker is doing is placing a URL inside the package ref element inside your distribution script. Those of you who are familiar with distribution scripts and how this works, usually it's a file URL. It also places a hash of the package inside the distribution script, and that way the installer can ensure that the package it downloads and installs is the one that the author of the original software expected.

So to summarize downloadable packages, it's a flat file package format only for 10, 5 packages and going forward. But we really want you to start embracing the internet. Your customers are embracing the internet. They're probably even downloading your software via the internet now. It should be even easier going forward in the future. And it will save time and money for everybody.

So now that we have ways to package your software in easier ways and download that software from the internet, start to get into places where identifying where the software comes from is very important. And so our flat package format supports certificate signing. Those of you who are familiar with Software Update know that Apple Software Update only installs software from Apple Computer. And our customers expect that the software it gets from Software Update is the software update that Apple expects to give you.

It does that by signing its packages and ensuring the package does come from Apple Computer. This signing doesn't say anything about whether the software is good or whether it's secure, but mostly just says that it's from Apple Computer, and it's really all about identity. So certificate signing packages is all about where the package comes from and ensuring that a piece of software is the software you expect.

So in Leopard, this is more of kind of a preview technology. It's something that our flat package format is going to support, but we're still working out better ways to utilize the certificate signing of the packages to deliver your software better. It's a work in progress, and you sign your packages using a standard X.509 cert. You can use a certificate assistant to do that, and we're going to show you a demo in a minute. And the UI we have in the installer is just for testing at this point.

One of the things you can do going forward and something that we plan on doing for Leopard is possibly downloading your software, updating software from the installer. The way this would work is you might deliver your software today at 1.0 and know that you might have a 1.1 going down the line. But you don't know what the hash of that package is going to be, so you can't use the quick start package technology. So you sign your package now and you specify that there may be software down the line at a specific URL.

When that time comes where the software is on that server and your customers install that software, it will check the server, download the package, and match the certificate signing to make sure that the same person who signed the original software is the same person who signed the update.

And if that's the case, it can safely install the software. In this case, the certificate doesn't even have to be a certificate that goes to a root authority. It can be a self-signed package. But we can ensure that the software is from the original author we saw before. Again, this is something that we're looking forward to doing.

And we're going to do many more things down the line. And really, the certificate signing of packages is more of a technology we're introducing as part of the flat packages. So let's show you a quick demo of signing packages. Sean? Thank you, Chris. In this demo, we'll create a signed package for Sketch.

So to get started, we'll use the Certificate Assistant to create a self-signed certificate using the Keychain Access application, which can be found in Applications Utilities. So we'll go into the Keychain Access menu and the Certificate Assistant item and create a certificate. We'll call this the WWDC Demo Certificate, which will be a self-signed root certificate.

So we have our WWDC demo certificate. And if we go into Package Maker, we'll create a signed sketch. and Target Leopard because otherwise certificates won't work. And we'll add Sketch again. To set our certificate, we can use the Set Certificate item in the Project menu. Packagemaker will scan and find all the certificates that are valid for signing. So we have our WWDC demo certificate. And we'll set that. We'll build our package onto the desktop.

And when it gets ready to sign, PackageMaker will ask you if it's allowed to use the certificate. So we'll allow that. And if we open it in the installer, we'll see there's a little lock icon up in the upper right corner. If we click on that, we'll see which certificate was used to sign the package. And that's really all there is to it for certificate signing in PackageMaker. Chris? Thank you, Sean. As you can see, there's a theme here. We're really trying to make sure that all the features that we're exposing and giving you developers with installers are all available in PackageMaker.

So now we've talked about new ways to deliver your software using Leopard. Let's talk about a new feature in Leopard's installer to help you install your software better. And that's home directory installs. This is -- This is something that's been asked for and requested by many developers. Many customers are looking for a way to install in their home directory, and so we're finally doing this as part of Leopard. It's really about giving your customers the choice, and sometimes they only have the ability to install their software in certain locations. Not every customer uses their machine as an administrator, for example, and so they want to be able to install their software in their home directory.

It's very simple to do in Packagemaker. It's as simple as selecting a checkbox. Packagemaker has a new set of checkboxes that specify the domain that you're allowed to install the software in. And the domains allow you to specify how the user experience looks. It's very simple to do in Packagemaker. It's as simple as selecting a checkbox. Packagemaker has a new set of checkboxes that specify the domain that you're allowed to install the software in.

So behind the scenes, what PackageMaker does for you is it creates a domains element inside your distribution script. That domains element tells the installer which domains you'd like to present to your user for installation. There are three main domains, the home directory domain, the active system volume, which is your running system, and any other volume domain.

And that really drives what the installer is going to show when it brings the installer to your customer. And these domains are specified using JavaScript, and they really boil down to true or false. So you can determine at runtime which domains to show to your customers. And of course, PackageMaker takes care of these details for you.

So when you actually specify an install to allow for home directory or for the system, what actually happens? Well, the installer is taking your package, and if your user selects their home directory, it installs the entire package root in the home directory. If the user selects the system, it will install the entire package route at the system. And if you do any searching inside of your package, it will restrict all the search to the domain that your customer specified so you don't install your software in another location if your customer specified installing in their home directory.

To summarize, it's all about giving your customers the choice. And with PackageMaker 3.0, it's very easy to create packages that will install your software in the home directory or on the system, or whatever choices you feel necessary for your software. And of course, these are really the things you need to decide before designing your packages, whether your package is appropriate for installing in the home directory or not.

If you have software that requires kernel extensions, for example, you probably don't want to allow installation in the home directory. It may not make very much sense to have a kernel extension installed in the system and an application that uses that kernel extension only accessible to one single user.

Another thing is, this interface is available in both the installer application as well as the installer command line tool. So if you have software that has domains turned on, you can specify which domain to install by using the installer command line tool or the installer application. So that's a quick update on better ways to install using the Leopard installer. Now I want to cover better ways to do upgrades using the Leopard installer.

Upgrades are all about planning ahead. You really need to start looking at how you're going to ship your software in the future before you ship your software to start. Of course, that's not always possible, but you really want to give your users the best experience. And to do that, you want to be able to find your software that your customers have moved on the disk properly and also possibly have more efficient ways of installing your software over the internet.

So the three things we're going to talk about today to make that better today is better ways of finding your software. The Leopard installer has new ways to help relocate software on the disk or find relocated software. It also has a new patching technology that allows you to distribute your upgrades of your software in much smaller pieces. And there's also some changes to how receipts are done, and we'll talk about that in a bit.

So let's talk about better ways to relocate software. It's really a Mac thing to move your software on the disk. As your 1.0 software installer does, it installs the software maybe in /applications. But your customers are free to move that software anywhere on the disk. They'll probably organize the software however they feel fit.

And it's important that the installer is created in a way that allows your 2.0 of your software to find that software while doing upgrades. And it's really what's expected on a Mac environment. The good news is this is really easy with PackageMaker. With PackageMaker, it's as simple as a simple checkbox. And this will work for 10.3 and 10.4 packages as well as the new 10.5 packages.

But what's new in Leopard is ways to do searching as part of the flat packages, as part of distribution scripts. And searching inside of distribution scripts allow you to do your searches in a way that you haven't been able to do in the past. So let's say you're shipping iWork, for example. iWork comes with two applications, Pages and Keynote.

And you want to make sure that when you upgrade iWork, you install both Pages and Keynote in the same folder. So if you have two independent searches, they may find a copy of Pages in one location and Keynote in another location. And by doing your searches in the distribution script, you can use search results from one search and key off of that. You may find Pages and install Keynote in the same folder as Pages.

And to do that, we have three basic search types we're going to talk about today. We're going to start with component searches. Component searches are the fastest way to search for bundles inside of your package. They're really the recommended way of doing searches. And we use both Launch Services and Spotlight to find your software as fast as possible.

What's happening with component searches is there's a locator element in both your distribution script or your package. And that element contains search elements. Each search element is a single search that finds a list of results. Each search element has an ID attribute that specifies a name to the search you're doing. And you can use that ID later on to look up the results of the search. They have a type attribute that specifies the type of search. And I said before that we have three search types. That's the way you specify searches.

So the first search type we're talking about is component searches. Component searches are the way to find bundles on your disk. You specify component search by specifying a component element inside the component search element. That component element represents a bundle you're looking for on disk. It's the metadata about that bundle that you want to find. In this example, we have the ID attribute, and that specifies the bundle identifier for the bundle we're looking for. In this case, we're looking for iTunes.

We also have a path attribute, and that specifies a default location to search for that application, so you don't need to go through the entire system. Most cases, your application hasn't moved, so this is the quickest way to find that application. And we also have any other attributes as part of your bundle you would like to put in your search, and that lets you more finely tune your search so that it only finds, in this example, iTunes 6.04 instead of all the other iTunes that may be on your disk.

So another type of search which is much more powerful is the JavaScript script search. The script search allows you to use JavaScript to view results of previous searches and return results of a current search. These results are returned either using an array of paths, a single path, or false specifying that your search found nothing. These are a very powerful way to do searches like the iWork search I talked about earlier.

So let's show you a quick demo of what these searches look like. Sean? Thank you, Chris. Now, the most common type of search is when you want to find something to replace. Like, for example, you shipped 1.0 of your app and you want to find it and replace it with 2.0 of your app. PackageMaker can handle that for you. But let's say you have a plug-in that you've written for another application and you want to find that application and put the plug-in in a plug-ins directory that sits next to the application.

PackageMaker can't quite handle that for you yet. We're hoping to have that support for the final version. But in this demo, we'll show you how to edit your package info file by hand to set up that search. So we have an application called ispend, which is currently in an ispend directory in /applications. And it has a plug-ins directory that sits next to it, where you want to install your plug-ins.

Now, let's say the user has renamed the ispend directory. They've organized all of their finance applications together. The installer can still find this. So I have a flat package that I've created ahead of time that contains my plug-in. So I'll open that in the flat package editor that we saw earlier. And we want to edit the package info file. So we'll just drag that to a text editor.

Before we make some changes, a couple things to note. We have a component section that defines one component for the iSpend plugin bundle. It defines which file in the package this component represents. It has the bundle identifier and a search ID. What that means is that this file will be installed at the path found by this search. If no search is found, it will be installed in the default location. This ispend search is defined in this locator section.

It's a component search that looks for the iSpend application. It looks in the default location. If it's not there, it'll search for the bundle identifier. So what we want to do is we want to add a script search that uses the results of the iSpend search to find that plug-in's directory.

So we'll create a new search element and we'll give it an identifier of demo. And the type will be a script search. And then we give it a script attribute, which is a JavaScript function that we want to call to perform the search. Inside of the search, we can add a script element section. And inside of that, we can put our function.

So what we want to do is access the my.search.results global variable, which will be an array of the results found by the search you specify with an identifier. So in this case, the iSpend search. We'll check to make sure that it's not null or false. If it is, then we'll also return false, meaning that the search has failed so that the plugin will go in the default location. If results were found, we want to grab the first one because it'll be an array, and then we'll append a relative path to put it into the plugin's directory.

So then, now that we've defined our search, we'll update the search ID of the component to point to the new search we've created. We'll save our package info file, and we'll replace it using the flat package editor. And then we'll save a copy onto the desktop. And if we open this in the installer and click through, The installer will find the application and put-- it actually didn't do it this time. So-- . Ah, yes. Thank you. Try this one more time.

Click through again. And now that our JavaScript is correct, it did find the application and put our plug-in in the right place. So that is searching. Back to you, Chris. Thank you, Sean. How many of you out here have used searching in Mac OS X packages before? A couple of you. It's pretty complicated. This is going to make it much easier to do. And even if you're using 10.4 and earlier, just a simple checkbox in Package Maker will make this much easier to do.

But those of you who are familiar with this searching might recognize the token definitions plist file. And so for those people who have already fine-tuned their searches for their software, we have a new searching mechanism in the flat packages called the token definition search, which let you leverage the searches you've already created and place them inside of your flat package. These are a little less efficient and not the recommended way of doing things, but it's a good way to bridge your package to the new technology.

So we've sort of started to touch on how you can use some of these searches. Sean showed you how you can use a search to find the plugins folder of an application and install your software in that folder. You can also, as Sean showed you, you can access results of other searches within any of your individual searches. But you can also access these results as part of a requirement check. And more importantly, you can use these results to set where your software is installed inside of your package.

So to specify where your software is installed, as Sean showed you, you specify the search ID of the component of your package. A component is a representation of a subpart of your package, usually bundles. So if you have separate bundles inside of your package, Packagemaker will create a component for you and allow you to specify what search results will be used to set the target location for your installation.

Also, as Sean showed you, you can use the My Search Results object to access the searches within any JavaScript inside of your package. And that will let you access even inside of requirement checks. So let's say you have an Adobe Photoshop plugin. You may not want to actually install the software if you can't find Adobe Photoshop. Regardless of where Adobe Photoshop is installed, the installer will be able to search for Adobe Photoshop. And if it's not available, you can return that you don't want to allow the installation on that software. Again, it does this using the mySearchResults object.

So to summarize searching, there's new methods of searching in Leopard. They'll make it even easier to use, and they're much less confusing than the token definitions P-list you guys might be familiar with. They're much quicker because they use launch services and Spotlight to help find your software. And the new searching mechanisms are only available as part of 10.5 and later. Although, like I said, PackageMaker 3.0 will allow you to create the old search syntax if you need to for 10.4 and earlier packages.

So that's searching. Now that we have these downloadable packages, you can download your software from the internet, there must be a better way to download smaller parts of your package while doing an upgrade. And that's what patch packages are for. Many of you are familiar, again, with Software Update. And what Software Update does behind the scenes is it checks your system and sees if it can find the right diffs of files and install only those files so you can only download a smaller part of Mac OS X while doing an upgrade.

We've been using this technology at Apple for a while, and now we're ready to give it to you guys through patched packages in the flat package format. So they allow you to have packages that contain only updates of packages, only files that are updated in your software, as well as carry diffs of files in your software.

And it really saves on download time. This enables you to have a package that might be your first version of the OS, the first version of your software may be 10 megabytes, and the second version may be 20 megabytes. And instead of shipping all 20 megabytes, you can possibly ship 10 megabytes or even less of your software. It does this by using bsdiff to diff the files in the package or in your software. And for the leopard seed, it only diffs MacO binaries. But for the final release of Mac OS X Leopard, Packagemaker will diff all the files inside your package.

Also, Packagemaker will automatically create search requirements that will ensure that the software that your patch requires is actually located on the disk that you're installing onto. And let's show you a quick demo of that. Sean? Thank you, Chris. In this demo, we'll create a patch package that will upgrade the 10.4 version of Sketch to the 10.5 version of Sketch. So I'll launch Package Maker, and this will be the Sketch patch package, which will target Leopard so that patching will be enabled. And we want to create a package for the 10.5 version of Sketch.

And to configure patching, we'll click on the sketch item and go to the components tab, which will scan the contents of your package and bring up all of the bundles it finds. And to turn on patching, we'll click the patching checkbox, which will bring down this dialog. And with this dialog, you give PackageMaker the old version of your application that you want to patch. Now, it's very important that the version you give here be the version that will be on the user system. Because if the old version is not found, the installation will not be allowed to proceed. So we'll point this at the 10.4 version of Sketch.

The Package Maker will scan through the applications. It'll find files that are found in both, and it'll generate packages for the Mako binaries. In this case, it found one Mako binary to patch, which will save us 189 kilobytes. So we'll save our patch, and we'll build the package onto the desktop.

If we do a get info on the patch, we can see that the package is 176 kilobytes. If we had generated a full package for Sketch, it would have been 340 kilobytes. So we've saved some file space there. If we launch the patch package in the installer and click through to the destination select pane, we've seen that some of the volumes have a stop sign on them. That's because those volumes don't have the 10.4 version of Sketch on them, so the installation is not allowed to proceed. So that's patching in PackageMaker 3.0.

Thank you, Sean. As you see, patch packages are going to enable you to deliver upgrades to your software in even faster and better ways over the internet in the future.

And to make it easier for you guys to look into these packages or look into these receipts, because before you could go into library receipts and see what was happening, we have a tool called Package Util that lets you query the system for what packages are installed, query the system for what files are installed as part of that package, and even remove receipts or even remove files from those receipts.

And this isn't a full uninstall, rather more a debugging tool for developers and other people to work with this receipt database. But as you can see, we're really working on some technology that will make some of these more future things happen even quicker going forward. So please check out Package Util.

So to summarize, we really want you to start utilizing searching in your packages to ensure that if your software can be moved and your customers move your software, your upgrades will find that software and upgrade them properly. Also, patching will allow you to upgrade your software faster by having smaller downloads for your customers over the internet.

And library receipts is changing. So if you depend on changing receipts in library receipts, or deleting receipts, or reading out of receipts, you're going to have to find new ways to do this going forward. And if you really depend on that, we'd really like to hear from you so we can understand what you're doing with library receipts and make some changes to help make it easier for you going forward.

So that's upgrades. As you can see, we're really starting to move in a direction to allow for more advanced things going forward. With our new flat packages and downloadable packages and patch packages and our new receipts mechanism, we're really moving in that direction to do even more advanced things that we haven't shown you here today. So this is just a preview of what we're doing going forward. Also, all the things we've talked about today are going to continue to improve as we develop Leopard going forward.

So we've talked about creating packages using PackageMaker 3.0, better ways to deliver your software with a new flat package format, a new install feature with home directory installs, and better ways to do upgrades with better searching and patching. So to learn more about this, about installers, we have a lab at 5 o'clock in Lab C. Come by. The entire installer team will be there to answer any of your questions.

We have a new software delivery guide online which will help you create simple packages. It doesn't cover PackageMaker 3.0, but it's a great document on how to create your software and develop them and distribute them to your customers using PackageMaker. Also we have a release note on the web as well as inside the seed, which mostly covers 10.4 technology, but it's a really good reference. And we also have an installer development list that's public that you guys can get on. And it's a really great way to communicate with developers, other developers that are creating packages, as well as the Apple developers. We can help you out and work through your problems online.