Greetings Xcode fans. So we are here together, thank you for coming to this presentation to talk about device management and app submission with Xcode 4. I should add Xcode 4.2. What you will see right now is done using Xcode 4.2. Don't try this with 4.1, you can try it at home.

So, we will go through a few steps. We want to take you from start to finish. From I have nothing and I'm creating a new project, to I have an old project and I want to make something out of it. But ultimately, I want to go to the store. So we'll go to templates, we'll go through project settings, summary pane, a lot of things.

We'll go through building and running on the simulator and on the device. We'll show you how to better test your application. And we'll discuss how to do a submission to the store through an archive. Then, we would like to take you through a few tips and tricks that you might find useful.

So how do we start? As usual, templates. We re-sorted, we rearranged a little bit the templates. You will find a few difference compared with the previous version. We tried to match, sorry, and you still have the same format for Mac OS X, of course, but we'll stay focused on iOS right now. So we tried to match the common classes of application. Master detail, like message or mail. Page-based application, like iBook or Contact.

OpenGL application, you're all familiar with that. Tab apps, utilities, stock, all the things. And you can, of course, start with all close to nothing, a single view application or an empty application, when in fact already has a window. So the first thing you will see when you create a new project with, or a new workspace with Xcode will be the setup of the template.

There are a few things that you can set from start. You can pick the product name. You can pick the company identifier. Combined, they will create the bundle identifier. More on that later. You can then pick the device family you will want to target. All the templates now are targeting iPhone, iPod, iPad, and Universal, which means combination of the two. You can change that later. You can then elect to use the new storyboard feature, which we highly recommend. You can use code data. And we can set up for you everything for unit testing. Highly recommended, as you know.

Once you do that, you end up in the summary pane. The summary pane is a simplified version of all your settings. We did our best to try to put there 99% of what you will use in the normal life of your project. So you see again here the identifier. This is quite important because this is the one you will use in iTunes Connect to identify your application. So when later you will want to upload to the store, you will need to have this matching something on an iTunes Connect site.

You then define the version number. Version number, very important. Same thing, that's the one you will specify in the iTunes Connect portal. Again, the device family, you can change it from here. You can reverse a choice you made before. If you move from iPhone to iPad or Universal, we will help you set up a few things like modifying the zip file if that's still what you're using, and create one or two things to help you create the framework for a Universal application.

And of course, the usual things like the deployment target, very important. You all know that you have to use the latest SDK available, but you might want to elect to deploy to earlier version of the iOS. In that case, this is what you will do. You will pick the deployment target. Then it will be up to you to be sure in your source code that when you use a newer feature, you really check that it exists on the device you're running on.

Here you have to specify the name of the storyboard you want to be loaded at first, or the first zip file you want to use. The orientations that your application will support. The icons. The icons are added by drag and drop. Don't be afraid to do the wrong thing. As long as it's a ping file and the correct size, we will accept it.

If the size is incorrect, we will reject. So not too many risks of mistakes here. For the initial launch images, we will accept about any size. But we will display a warning if the size is not optimal for the device you target. This is for the iPhone/iPad. You have the same thing for the iPad if your app is universal.

In case there is something that's missing for your needs in the summary pane, you still have access to the build settings by config file, target, config file for the project, project, and the resolved values for all your settings. You can do all these changes here. You have several ways to customize the way you want to see your settings. Simplified, accumulated, enjoy.

Now that you have set up everything you want to build and run. To do that, you click on the Run button. Xcode will build, launch the simulator, launch your app. From a template, it will work. Later, it's up to you. Once this is done, I'm sure you will want to then do the same on a device.

For that, I will ask Jacob Xiao to come on stage, the master of the provisioning profile, the keeper of, well, the keys, and he will explain to you how to set up a device to be able to run. Jacob? Thanks, Marc. So I'd like to tell you how you can set up your device to run and test your iOS apps. Now, let's get started.

So here I have a basic photo album application. And I'll start by just running it in the simulator. The great thing about running in the simulator is that there's no setup required. So here's my app, and I can flip through photos and also view those photos' location on a map. Okay, that works, but I also have a feature in this app that's triggered by a pinch gesture. And it's really better to test multi-touch kinds of things on a real device, because you want to see how the gesture feels with your fingers.

So how many of you have had problems in the past with provisioning profiles and signing certificates and getting all of that set up? Yeah, me too. Well, I have good news for you. Xcode will now do all of this setup automatically. All you have to do is plug in your device.

And when it appears in the Xcode organizer, just click Use for Development. Then sign in to the provisioning portal. And since this is my first time setting things up, Xcode will even offer to create a signing identity for me. So I'll go ahead and do that. And Xcode is now adding my device to the portal and creating a new provisioning profile for me.

This profile will include all of my team's devices and also all of our signing identities. And it will use a wildcard app ID, which means it can be used with any application, regardless of the app's bundle ID. And you can see here now that it's downloaded the profile and even copied it over to my device. And that's all I have to do. I'm ready to run.

So I just choose my application, my device here, and build and run. And now, my app's running on the device. It's just starting up here. And I can flip through my photos and view the map just the same. And now I'll try my pinch gesture. Cool, now I can tweet my photo. But I'm not sure if the pinch gesture is really the right gesture here, so I'm glad that I tested it.

Now, there are some services for iOS that require an exact bundle identifier in your provisioning profile. This includes GameKit, push notifications, and in-app purchase. And you have to create a custom profile to use any of those. Formally, you'd have to do this on the provisioning portal site. But as of Xcode 4.2, you can now do this in the organizer as well. Just click on Provisioning Profiles and click New here. You can enter all of the information that it asks for, including which of your app IDs you want to use.

Then, Xcode will communicate with the portal and create your new custom provisioning profile. Another thing that you have to do with provisioning profiles is renew them after they've expired in a few months. And this is also something you can do right from within the Xcode organizer. I don't have any expiring profiles here, but you just click on the profile and click renew. So now that you've seen how to run your application and also how to manage profiles from within Xcode, let's talk about unit testing.

When I created this project, I clicked the Include Unit Tests checkbox that you just saw. And that created this unit test target. Now, the type of unit tests created by that checkbox are application unit tests. And this means that the unit tests are actually injected into your application and then run from there. This can be useful because you can test the model, view, and controller parts of your application, since you're just running in the real application.

So in the test that I've set up here, we're getting the app delegate and testing some of its properties. I also have a test that will tell the app delegate to run an action method. And then we'll test that the map view was actually shown. So application unit tests can be run both on the device and on the simulator. So that it's easier for you to see what's going on, I'll run on the simulator. Now to run the test, just choose Product and Test.

And you'll see that our application is started up to run the tests and then terminated as soon as tests are finished. Great. Now all of our tests have passed. The alternative to application unit tests are logic tests. And these are actually run independently of your application and without a user interface. This can be useful for testing the model parts of your code because you'll be running these tests independently of your application so there's no interference. Now to create a logic test, just go to New Target and choose Unit Testing Bundle from the Other category.

Now, I've created these new logic tests. And first of all, I'll turn off this automatic failure because we don't want that. Then, I'll drag in some tests that I have prepared and add them to my logic tests. So these tests test the photo class, which is part of my model.

And since logic tests are run independently of the application, I'll have to include any classes that I use in the unit tests. I can do that for the photo class in the utilities. And my unit tests also use Core Location. So I'll just add the Core Location framework to my link phase.

Okay, now we're ready to run the tests. And Xcode has created this separate scheme that includes just those logic tests that I just created, but I'd really like to add them to my main photo album scheme. I can edit the scheme to do that and go to the test section. Now you can see that my application unit tests are already here. I'll add the logic tests.

And now both of these sets of tests will be run whenever I test this scheme. This section of the edit scheme editor is also where you can turn on and off individual tests. And here's a quick tip for you. You can hold the option key to turn all tests on or off. Okay, now let's test all of our combined tests. Again, the application tests will run. Let's try with the iPhone simulator.

It's going a little slowly this time. But while it's going, I'll tell you about another new feature in Xcode 4 for unit tests. You can now run all of your unit tests right from the debugger, just like you run your application tests. And this means you can add breakpoints, just like you do to your application. In fact, for unit tests, you can also add a breakpoint that will fire whenever your unit tests fail. To do so, just click Add Symbolic Breakpoint. and enter send test case, fail with exception.

Now this breakpoint will be triggered whenever one of my unit tests fail. So let's see if we can get the simulator up. This is a beta after all. And we'll try to test again. Okay, now our application tests have run, and our logic tests will run after that.

Now all of our tests have run. Okay. Now I'll switch back to slides and summarize what we just saw. So, I just showed you how you can set up your device to run your application, how you can manage provisioning profiles right from within Xcode, including some new features in Xcode 4.2, and also how you can set up and debug your unit tests from Xcode for your iOS apps. Now, I'd like to turn things over to my colleague, Itai Rom.

Good afternoon everybody. So today I'd like to talk to you about two new features in Xcode 4.2 that will make it really easy to test your iOS apps. The first one of these is application data. Until today, testing your apps using real application data was a tedious endeavor.

You either had to write custom code to generate data whenever your app ran, and then of course remember to disable or remove that code before you release your app. Or you could come up with complex schemes to transfer data into your app sandbox. But with Xcode 4.2, we'll do all of that for you automatically, and it's really easy. The other major feature is location simulation.

If you've ever had to cram your Mac Pro into the backseat of your buddy's hatchback while he drove you around town just so you could test your app, those days are over. Xcode 4.2 makes it really easy to test your app in any location on the planet right from the comfort of your own office. So let's take a look at how these features work.

So here we are in Xcode 4.2 looking at the photo album project that Jacob just showed you. Now, first we'll take a look at how we can test with application data. If I click on the Organizer button here, and then on the Applications tab in the Source List, you'll see that we now have a new section in the Organizer that shows you all of the data inside of your app sandbox. And in here you can see a couple of the images that you saw in Jacob's demo, some other files, some metadata files, things like that.

So what I'd really like to do is to test our app using a few additional images, because two is really not a lot. And the next step in doing that is to download this data onto my Mac so I can edit it. So I'll click the Download button and just save this to the desktop as appdata-sf.

Now when I click save, Xcode's actually going to download all of the data out of my application sandbox onto my desktop, and it's going to save it in this new bundle format. I hide Xcode, and I can edit it just like I would any other bundle. I can right click and show package contents in the finder, and you'll see when I look inside that I see all of the same files I just saw in the organizer. And I can just drag in additional data if I want, or delete things, rename things, whatever I want to do.

I haven't gotten to the good part yet. So I happen to have a few additional images. I'm just going to drag them right in here and I'll replace what's already there. So you can see now we've got seven images from San Francisco. Great, let's go back to Xcode and see how we can upload this back onto my device. I can just click the upload button here in the organizer.

And that's going to upload the data one time so that every time I launch my app thereafter it's using the same data set. If I delete things within my app or create new things, Xcode's never going to touch the data set again until I click upload. But I'd rather do something more automatic. So if I go back, close the organizer window, and go back into Xcode. I'm going to import the app data bundle I just created into my project. And I'll do that by right-clicking in the project navigator and choosing Add Files.

I'll select the bundle I created, and I don't need to check any targets here. This file is not really part of building my application at all, so I don't want to add it to any target. I'll just click Add, and now the data was imported into my project. I can click on the Scheme Editor up here, and Edit Scheme, so that I can now make Xcode always upload my data every time my app launches.

When I select the Run Scheme Action, you'll see a new options tab in the Scheme Editor. And this is where you can control the new testing features in Xcode 4.2. We'll get back to the location pop-up in a minute. Let's take a look at this application data pop-up.

You'll see it lists all of the app data bundles in my project, and I can just choose one. And now, every time I run this scheme, Xcode's going to upload my app data to the device or to the simulator fresh. So if I modify anything while I'm testing, it'll re-upload everything from scratch. So it's always in a known state.

Hooray! Now that's not all you can do. You could also go to the test scheme action. And you might have noticed when Jacob demoed this earlier that we have a couple of new columns in here. You can actually associate app data with each of your tests. And you can associate a different bundle with each test suite so that you can use different app data for all of your different tests and actually test different things really easily that way. You can do the same thing with locations.

So I'm not going to do that now. I'm just going to click OK and keep my fingers crossed because I'm going to run in the simulator again. Let's see if this works. So there's our app. Now if you recall before, we only had two photos. Now we have seven. So our app data was uploaded correctly.

Now that's wonderful. The next thing I'd like to test is another feature of our application. In addition to showing you a map showing your current location, the Photo Album app will also filter the photos that it displays to just those that were taken within a certain distance of the user's current location. Now, since we're in San Francisco and all the photos we've been looking at were from San Francisco, we haven't really been testing that. And I'd like to test some other locations to make sure it works properly. Let's take a look at how to do that.

The first thing I'll need is an app data bundle containing some photos from other locations. Now, I'll hide Xcode and take a look here in the finder. I just so happen to have one already prepared. And you'll see that it's got images from New York, Paris, Rome, San Francisco, and Sydney. So we can actually want to make sure that we can view all these photos properly in our app. I'll go back to Xcode and import that app data into my project.

Okay, so now I've got it in my project. I need to edit my scheme again to add it to the run action. So I'll select my new app data. Okay, now, how will we actually test photos taken from New York or Sydney without going there? That's always been sort of problematic until Xcode 4.2.

If I click on this location pop-up, you'll see that Xcode comes with a few built-in locations that you can choose from. Now, whenever, if I select one of these, whenever I run my application, the simulator or the device is going to think that I'm actually in London or Moscow or Sydney, and my application is going to behave as it would in a different way. It would for a user who's actually in that location. So let's go ahead and choose Sydney. And we'll click OK and run.

The simulator will launch. It's going to transfer over our app data. And you'll see, as soon as our app's launched, we're in Sydney, as you can tell by these photos of the Opera House in the background. I can even click over to the map, and you'll see that the map shows that we're in Sydney. So just like that, I was able to test my app in Australia without hopping on a 17-hour flight.

So that's really useful. How can I now test photos from other locations like New York? I could quit out of my app, go back to the scheme editor, change that location pop-up to New York, relaunch, verify that it works. But it would be really nice if I could do this on the fly while my app is running.

So in Xcode 4.2, that's also really easy to do. We've added a new control here in the debug bar, which is kind of small for some of you guys. But it looks just like the location services icon from the status bar in an iOS device. And when you click on it while your app's running, you'll see that it lists all of the same items that you saw in the scheme editor. And I can just click on one of these to be instantly transported to these locations. So let's click on New York. and our map moves over to New York. I can click done and we've got photos from New York. It's that easy.

So hopefully you guys can see how useful this feature will be for testing all your location-aware apps in the future. Now, the next thing to take a look at is how you might simulate a custom location. The earth is a pretty big place, as I'm sure you're aware, and pop-up menus tend to be pretty small.

So we think we've selected a pretty good list of built-in locations in Xcode, but you might want to test a different location. So how could you do that? Well, in Xcode 4.2, we support the GPX file format. And I've got a few GPX files here that I'll import into my project.

and Shouyu. So here's one for Paris. And you can see this is a really simple file format. There are a whole bunch of ways you can generate these on web-based navigation services. GPS devices can export them. GPS tracking apps on iOS can export them. Or you could just create one yourself in a text editor. It's pretty simple.

There are two elements in this file, an outer GPX element and one waypoint element containing the latitude and longitude of the Eiffel Tower in Paris. This name here is optional. Here's another one for Rome. This is the location of the Roman Colosseum. So to use these, now that I've imported them into my project, all I have to do is build my app again, run it in the simulator. This works on the device as well.

We'll default to Sydney, as you'll recall. That's the location we selected in the scheme editor. But now when I pop open the location services pop-up, we've got some additional GPX files that we can select from. And I can just click on Paris. Now we're in Paris. As you can tell from these Eiffel Tower photos. I can click on Rome. and now we're testing our application in Rome. As you can tell from this lovely t-shirt, which we could never have faked. So.

It's that simple to test your app in any location that you need to test on the planet. If you get a bug report from a user who's located somewhere you'd never want to travel to, you can easily do it in Xcode now. Finally, you may also want to test situations where your user is changing location over time. And the GPX format can handle that as well, and so can Xcode. Let's take a look at another GPX file that I imported.

This one's called train sj-sf. Now, you'll see this looks very similar to the other GPX files, but it contains a few more waypoints. I actually recorded this on my iPhone while riding Caltrain up to San Francisco earlier this week. So it's really actually pretty easy to generate these just using your iPhone.

The only difference between a GPX file that simulates a path and one that just simulates a single location is the number of waypoints. You only need to specify two, but you can specify more if you want to. And Xcode will automatically interpolate all of the locations in between the waypoints that you specify.

So I could have created this file with just the location of San Francisco and a location from San Jose, and Xcode would automatically generate a path between the two. But if I provide additional waypoints, that gives me finer-grained control over the path that Xcode simulates. So let's see how this works. I'll run my app again.

Let's go to the map view. Again, we're starting out in Sydney, but I can. Pop open the pop-up button here and choose Train SJ to SF. And now you'll see we start out in San Jose, and our location slowly moves up the peninsula up towards San Francisco. So this makes it really-- This makes it really easy to test applications where you're relying on the user's position actually changing over time, like navigation apps.

Let's go back to the slides, please. So what did we just see? We just saw how Xcode 4.2 makes it really, really simple to test our applications using real application data and simulated locations. These were really difficult things to do before. And now it's a breeze to do this right from the comfort of your own office. At this point, we've learned how to create and test our app. The next step is archiving. And to show you how to do that, I'd like to invite my colleague, Clark Cox, up on stage.

Thanks, Itai. At some point, you're going to want to get your app into someone else's hands, whether that's an external tester, a tester internal to your company, or even Apple's App Store reviewers. To Xcode, it's all the same. It starts with archiving. So I'd like to switch to the demo machine.

Okay, first I need to make sure that I'm building for the device. Okay, I'm going to create an archive by going to Product, and Archive. Xcode builds a copy of my application and packages it up with debugging information into an XC archive bundle, which you can see represented here in the organizer.

Now let's say you're distributing this to a beta tester. Well, all you need to do is select the archive and click Share. Now I'm presented with a couple of options. I can either share a single IPA file, or I can share the entire archive. I'll get back to this option later. For now, I just want to share an IPA file. So I choose that option. Now I need to make sure that I'm signing with the correct profile and signing identity.

As it stands now, it happens that I'm signing with the correct profile and signing identity. Now I need to make sure that Xcode has chosen the correct one automatically. I want to sign with my distribution certificate and my ad hoc distribution profile. If it weren't selected automatically, I could always choose it manually. So when I hit Next, Xcode generates the IPA.

I can save it there on my desktop. Now I can email this file to my beta testers. They can drag it into iTunes for syncing with their device. Now, say for instance, I'm satisfied with the state of my application. I've reacted to any feedback from testers, I've fixed any issues found, and I'm ready to submit it to Apple for inclusion in the app store. Again, the process is very similar. I select the archive. This time I click Submit. I log in with my iTunes Connect credentials.

And then I'm asked to choose the application record on iTunes Connect that corresponds to my application. In this case, I just have the one. Again, I need to make sure that I'm signing it with the correct provisioning profile and identity. This time I want to use my app store provisioning profile, so I'll select that there. When I click next, Xcode uploads the app to Apple and a series of tests are performed on it. In this case, all tests have passed and now my app is forwarded on to a human for review for inclusion in the app store.

Now what happens if, for instance, I'm not the team agent, and therefore I don't have the authority to submit apps on behalf of my team? Well, we've got a solution for that as well. Again, I select the archive. I click share. This time I'm going to share the whole archive.

Now when I save this out, it saves out the entire XC Archive bundle. I can then send that to my team agent. They can double click on it and it'll open and import into their copy of Xcode. And then, again, they can select it and go through the submit workflow that I showed you earlier. They don't need to build from source. They don't need to even have the source. And more importantly, they don't need to share their signing identity or login credentials with anyone else. With that, I'd like to go back to the slides.

So I've showed you how using Xcode's archive functionality, you can share built copies of your app with other people, whether that's external testers or other members of your team. And I've showed you how via the submit workflow to validate and upload your application for submission. And with that, I'd like to give it back to Marc.

Thank you Clark. Thanks. So I hope you enjoyed the presentation so far. What have we seen? We've been to All the things that Clark showed you and the workflow was creating a new project, provisioning devices, we've seen that, testing, simulating, archiving. Now you are all certified Xcode 4.2 experts for iOS development. We would like to share with you a few tips and tricks.

First one, a very nice feature, the developer profile. Let's say you work from home, from the office, on your desktop system. Everything is set up properly. You went through the step that Jacob described earlier. And you have a signing identity. You have your provisioning profile. You can deploy, build, run on your devices. You're extremely happy. Now, you're about to leave home and fly to WWDC, let's say.

And you want to continue working using your laptop. So you want to set up your laptop and be able to code sign your application, run them on the device the same way you do on your desktop. How do you do that? It's very easy. You go to the organizer and you select developer profile. Xcode will show you everything relevant for a developer from the kitchen and others. That is, signing identities and the provisioning profiles understood by your computer right now.

You select at the bottom, export. And once you do that, you'll be asked to enter a name for what you will archive and enter a password. The password is extremely important because this is very private information. Your private key you're signing as an entity is something very personal. And if you're signing in the name of a corporation, very important. Once this is done, you take this file that you created on your USB key, network, whatever, and you put it on your laptop. You then click Import.

You ask to enter the password. You select the correct file, of course. And that's it. You have synchronized your desktop on your laptop. You don't have the dreaded no identity file for this provisioning profile, blah, blah, blah, blah. I'm sure you've never seen that one, but it might happen.

Trust me, I've seen it. That's the best way to avoid that. That's somewhere one of the only way. And another way would be to manually do the same thing, but why do it manually when Xcode makes things easy for you? That's the first tip. Second one, problems happen when I'm staying polite.

You left home, you're halfway to San Francisco, and you remember, yes, I will have to build my application because there's something I need to change for the demo I want to produce, but I forgot my signing identity at home. I forgot to do what we just did. How do we clean up a system to go back to normal? I have one piece of bad news.

You will need to reset up your desktop computer when you'll be back home. But that's another discussion. You can use the developer profile feature. To clean up a computer that has not been used for development so far, You have to go to the developer portal and select certificates.

You will be presented with the certificates you are using and the one for which the private key is on your desktop system at home. You revoke it. If you don't do that, because you don't have the private key on your laptop, you won't be able to achieve anything. Once this is done, you go back to Xcode.

And you do what Clark just described. Refresh, you'll be asked for your identity on the portal, the developer portal. We will recreate for you a private key, assigning identity, the provisioning profile, download everything, you're in business. When back home, you'll use the developer profile feature to reset properly your desktop system, and you will be back in business.

Sometimes you will want to manage your projects and keep them in separated parts like the main target and a static library. There is one small thing, a problem that we saw that you guys encountered in the past, and we want to bring your attention to that. While you're developing, everything will be fine. You'll be able to build, you'll be able to run on devices, and so on. But the moment you will want to create an archive, you'll run into trouble.

You need to create, to use a static library to import it in the build phase. You're familiar with that. We encourage you, if you have problems at the IPA generation time, to look in the project setting, and to look at the flag code, skip install. What is it? If you say, skip install, no. Xcode will install your static library in the archive you are creating. Then when you will want to create an IPA, what will happen? You know that you can submit to the store only a self-contained bundle.

And you will have your dot app for iOS in your archive. And you will also have your static library installed. There's no way you can distribute a static library to your user on a device. So we won't be able to create an IPA. So you need to set this flag to yes. Skip the install, please. Especially if you want to create an IPA. Small thing, but can be useful.

And now you'll be able to have an archive. So we talk about creating from templates. Sometimes you want to import from existing projects. And now we're going back to a new feature in Xcode 4.2, one of my favorites. I like it a lot. I imported an old project of mine, the one that Jacob created, not of mine, but it's the same. And you see in the issue navigator that Xcode is saying something. It's saying, eh, they are setting that you might consider updating.

If you click on this, you'll be offered with a few choices. In this case, one, there was not much to change, but there can be much more. In this case, what Xcode is saying is, you have coded your iOS version that you're using. And as you know, you have to build using the latest SDK.

So why not say it? Why not use the setting that says, use the latest SDK? That way, when you have a new version of Xcode installed, a new version of the iOS SDK, you don't have to update your project. That's very convenient. Xcode is offering to modernize your setting for you. It does a little bit more. It's checking to duplicate files in some entries. It is checking for older flags that are not supported anymore. It's project cleaning. Thank you.

Another detail, small thing. I'm sure most of you attended the excellent presentation the other day about how do I master the schemes. Schemes are an extremely powerful feature in Xcode 4. Schemes are created automatically for you and if they find release and debug configuration, we'll initialize the schemes based on that. So, when you will archive an application, it is very likely that the scheme that will be created originally will point to the release configuration.

If you set up in the past a distribution, which happens to a lot of us, especially with the workflow that Xcode 3 was encouraging. If you set up a distribution configuration, the scheme won't point to that one. So I encourage you to look into your scheme and look at the automatic setup to check that it's right, especially for archive. Because if you're not pointing to the configuration you think, you will be either unable to submit because it won't build properly, or you will submit something that is not exactly what you want. Which would be bad, I think.

And that's it. That's it for today. I hope you enjoyed the presentation. You might have a few questions. So we will enter for a few Q&A, if that's okay with you. So I'll call the team on stage. Guys? If you have more questions, of course, the excellent Michael Jurowicz is available to answer all of them. We have a good documentation. We have forums where you can ask questions. I have Apple engineers replying to those. I know most of them are in the past, but the videos will be available online at some point, I'm sure.