WWDC2010 Session 301

Transcript

>>Todd Fernandez: Good afternoon everyone.
Welcome to Session 301, Mastering Xcode
for iPhone OS, I mean iOS development.
I'm Todd Fernandez and I manage the Xcode iPhone tools
and Dash Code teams, and I am very happy to be here
with you today to tell you about all the great
new features in the tools in the new SDK.
But I'd like to start the session by posing a question.
Why are you all here?
I'll even hazard an answer.
I believe you're here to learn how to get
the most out of your development tools,
so you can create and app that earns a Five-Star review.
Am I close?
All right.
But let's be honest, what are those five
stars, what are they really all about?
[ Laughter ]
But how do you get there?
Well, I think you've made a great start by
coming to WWDC10, the center of the app universe.
And for the next hour, I'd like to be your guide on
a journey through the iPhone development experience,
iPhone development universe, where I will orient those of
you new to the platform, as well as tell all of you all
about the great new features that
we've added and the new tools.
Now, as an aside before we really get going here, for those
of you Star Trek fans, I confess that I was much happier
about this journey to the stars metaphor before I
knew I was going to be wearing a red shirt on stage.
I'm just really hoping that the stage represents the
bridge of the Enterprise and not an exotic planet
where I've been sent as part of an away team.
And then I've got this weird earphone, I feel like I'm
part of the Borg to, that's the end of my Star Trek.
Let's get started.
So, in fact, this is the first
of a two-part series of sessions.
Again, this afternoon I'm going to give you a tour of the
complete development cycle, and then tomorrow morning,
we're going to go deeper in several critical areas, which
I'll identify as I go through the content this afternoon.
Again, today we're going to start
with a tour of the complete cycle.
I also want to make clear at that outset that I'm
not going to talk about Xcode 4 this afternoon.
While we're very excited about Xcode 4 and we hope all
of you are as well, today we want to help you get ready
to get your app into the App Store
as quickly as possible, and for that,
you're going to be using the new
iPhone, iPhone SDK 4 and Xcode 3.
All right, well, how does one get started on this journey?
We're going to start by talking about developing your app.
And, what's the first thing you need to develop a great app?
A great idea.
Now, I can't help you much with that, but once you
have your great idea, that's where the tools come in.
And, Xcode provides a number of different templates to
get you started to turn that great idea into a great app.
There are number of different template types, depending
upon what kind of application you're building.
You can also decide whether you want to create an iPhone
version of that template, iPad, or we hope universal,
which will then run on all of the iPhone OS devices.
All of our templates create working apps right
out of the box, so it's very easy for you
to get something working immediately and start
experimenting as you start learning the frameworks,
and add new to functionality that
your particular idea needs.
For those of you with existing iPhone
projects, we also make it very easy to upgrade
that project to also build a version of it for iPad.
Simply select the Upgrade Current Target
for iPad menu item from the project menu,
and you're ready to start customizing it for iPad.
There are a number of important build settings
that control, first, what API's your app uses,
and we'd really encourage you to always use the latest SDK.
And a couple of other settings that control which
devices and which OS versions your app supports,
and were going to talk a lot more about this tomorrow.
Finally, this is where your expertise comes in.
Where you actually use the tools to start creating
the user interface, the behavior of your application,
and there's a variety of great tools to do so.
For an Xcode source editor and all the productivity features
to help you write that code from, and learn the frameworks
and new API's, Interface Builder to build
your user interface, Xcode's build system
and especially the Static Analyzer, which you can use
to find complicated bugs in your code and then walk,
have Xcode explain how, in fact, the bug
occurs so that you can understand and fix it.
And finally, the integrated documentation, especially
Quick Help, which is great as you're learning UIKit
and the other frameworks you need
to create great iPhone apps.
It's very easy to access that information
right from the Source Editor.
But instead of talking more about this, I thought it would
be better to have Jacob Xaio come up and give you a demo.
Take it away Jacob.
>>Jacob Xiao: Thanks Todd.
Okay, let's get started by creating
our new iPhone app project.
So, we use one of these templates, and
as you can see, they're quite a few here.
Some of them are iPhone only, and some of them are iPad
only, for a few of them, you can pick between either an iPad
or an iPhone version, but I'm going to
use the Window based application template,
because I want to create a universal application.
Ok and here's our new app project.
And one of the great things about these templates
is that they're ready to go right out of the box,
so I can just hit the Build and Run
button and it will launch into simulator.
And you can see this is using our new iPhone 4
simulator, so it looks great, but it's a little blank now,
so that's where your great idea comes in.
Ok, let's see what this template has set up for us We have
a shared group, where you can put your code and resources
that you want to share between the iPhone and the
iPad version of the app, then you have an iPhone group
where you can put your iPhone specific code, and you
can see we already have an app delegate and an interface
that will be used for the iPhone version.
And similarly, we have the iPad group where we
have the iPad's app delegate and its own interface.
Okay, let's get started with the iPhone version.
I'd like for my application to have a translucent
status bar, so let's set that up here at launch.
Okay, I'll send a message to application, and you can see
that Xcode does auto-completing the Xcode
application of the application variable name.
And the same thing happens when I set
the, with the Set Status Bar style method.
In fact, even this enumerated type, I can just hit
Option-Escape and I see all the possible completions
for that, and this is really great for
going through an enumerated type like this.
I can just see which one I want, which is black translucent.
Okay, next let's add a method here to show
some information about our application.
And I'm going to use a UIAlertView to
show information about the iPhone app.
Oh, I forgot to add the first bracket
here, but Xcode can do that for me too
if I just add the completed, the end bracket here.
It'll just insert that for me.
And now, I have this init method, and you can see
it has these placeholders for me to put my content,
and I can hit Control-Slash to quickly jump between
those, and it makes it easy to fill out this long method.
Okay, now let me show the alert.
And another great feature that
Xcode has is Build and Analyze.
I can just choose that and it will build my application
and look for any potential problems,
which it looks like it's found one.
Says we may be leaking an object here, and I can
just click on that and it will show me the flow
of the application and where the potential problem is.
So it looks like we're creating this alert view here,
but then when we're done with it, we're not releasing it,
so let me just add the release method here, and we'll
build and analyze again, great and the problem's gone.
Now I'd like to trigger this method from Interface Builder
in a button, so to get it to show up in Interface Builder,
I just use the IBAction return value,
and copy this method into my header.
Now I can open up the interface file in Interface Builder,
add a button and when I control drag it to my app delegate,
you can see the method I added right here.
Ok, now let's build and run this
new version of the application.
Great, here's our translucent menu Status
Bar and the Info button with our alert.
Now I'll go Home and back to Xcode, but Xcode
says that the applications still running,
and that's because of the new multi-tasking in iOS 4,
so the application really is still running suspended.
And, if I want to confirm that, I think one of these
methods is related to that, I think it's this one,
but if I want to find out more, I can Command double-click
on the method to jump right to it in the header file,
here in UIApplication.H. If I want to see
more information, I can Option double-click
and I get the Quick Help popup,
tells me a little information here.
But if I really want to see all of the
documentation, I can just click on the book,
and that brings up the full documentation here.
Yeah, this looks like the one I want, so
I'll just go back and set a break point here,
and now when I bring the application
to the foreground again, yep,
sure enough, it's stopping here at the break point.
Okay, now let's work on the iPad version.
I'll just copy this method in, and of course, I need to
change iPhone to iPad, and you know, on second thought,
this iPhone alert is not the best variable name here,
so I should probably change that to be more general,
and for that I can use Edit All In Scope, by selecting
this variable name and then just picking the Edit All
In Scope menu item, and this, for this Xcode, we'll
go through and find all occurrence of this variable
in the current scope, and as you can see,
its changing them all at the same time.
Ok, now let me go to the iPad interface, and add the
button, and when I Control drag, it's not showing up here.
That's because I didn't add it to
the header file, that was my mistake.
Let me just copy it, and use the Go to Counter Part
button, which instantly just takes me to the header file.
Ok, now I should be able to just
Control drag in, and there it is.
Then I can use the Overview popup to switch from the
iPhone simulator to the iPad simulator, and when I build
and run again, the simulator will change to
the iPad mode and here's the iPad version
of my app with the popup, with the alert view.
Ok, back to you Todd.
[ Applause ]
>>Todd: Thank you Jacob.
So just to recap, we've seen using a template
to create a new universal app project,
we've seen several of the important source code and
interface editing workflows as Jacob built user interface
for that app and wired it up to his source code, he
used Quick Help and the Integrated Documentation Viewer
to explore the delegate method that gets called
when the app is unsuspended, as well as a little bit
of building and debugging in the iPhone simulator.
So, let's continue on our journey.
We've started developing our app and
we've done a little bit of building,
but let's talk a little bit more about building.
So, the device versus simulator; Jacob used the Overview
popup to switch between which simulator he was running in,
but we've also just greatly simplified
that choice between device and simulator.
You just chose your destination device and
then if you've got more than one device,
you can choose a specific device
right from the Overview popup.
And, in fact, depending on how you have those build
settings I mentioned earlier, like deployment target,
that will control which devices appear here, for example, if
your app is configured to build, to have a deployment target
of OS3.2 and you have a iPhone running
3.1.3, it would not appear in this list.
Similarly, you can choose Simulator at the top and
then if your deployment target is set appropriately,
you'll see all the simulator versions
that are compatible with that version.
Like Jacob built, the universal app, which is
configured with a deployment target of OS3.2,
which show both the iPad simulator
and the iPhone simulator 4.0.
There are few new things in the simulator in iOS 4.
You can now build once and then simulate on multiple
OS versions, just like Jacob just showed you.
The reason this is possible now in the OS4 SDK is that it's
the simulators now using the modern objective C run time.
You get many benefits from that, but one of
the most noteworthy is you no longer have
to declare your instance variable for properties.
However, there is a cost for that benefit as well as
again the ability to simulate on multiple OS versions
with the same build, in that, this is an ABI change, so
that any code that you have compiled for the simulator,
libraries, other code that you're using
will need to be recompiled with the new SDK.
Moving back to the device, this
was actually introduced in 3.2 SDK,
where we now incrementally upload your
app to the device as you make changes.
Only the change bits are uploaded.
For those of you who have large resources, whether
its audio, video, photos, what have you in your app,
this can save you a lot of time and give you much
faster turnaround as your Edit, Build and Bug cycles.
Course, since the simulators running
right on your development system,
it's still going to offer you faster
turnaround then uploading it to the device.
But you really need to test your
app on every model you support.
Although you can save a little bit of time,
I don't think you need to test both the
iPhone for white, and the iPhone for black.
To further motivate you to test on devices,
let's talk about why it's important to do so.
Well, some of this may seem obvious,
but let's talk about it.
The Mac, of course, where the simulator's
running, is a far more powerful
and less resource-constrained device than any mobile device.
And what that means is that performance analysis you do
on, in the simulator, which can absolutely help you find
and fix serious bugs in your application, is still not going
to accurately represent the behavior
of app running on devices.
Further, a lot of the hardware capabilities that the device
has, whether it's a compass, the GPS system, the camera,
or now on iPhone 4, the gyroscope, those just
aren't available in the iPhone simulator,
so if your app uses those facilities, you'll need
to do, you'll need to test them on the device.
And finally, though the iPhone simulator does a good job
of trying to allow you to simulate multi-touch gestures,
there's really nothing to substitute for
actually interacting with your app on a device
to really understand how it's going to feel for your users.
Now again, it's your, you need to decide exactly which older
OS versions and devices that your app is going to support.
If you are supporting those older devices, you need
to know how your app performs for all of your users.
And what that means is that you need to keep devices
running older OS versions, because it's not possible
to rollback the OS version to an
earlier version on a device.
So I think this, I'll just let you gaze on this for a while
as a public service, you may not have seen this before,
but this is the device line-up as well as the
OS versions that are supported on each one,
including the new iPhone 4 there next to the iPad.
Just kind of, drink it in.
There will be a pop quiz later.
All right, well we talked about building on the iPhone
simulator and a little bit on the device, but, of course,
to build for the device, you need
to have your device provision.
So, let's continue on our journey.
So provisioning profile you need on your development system
in order of Xcode to sign your apps so that it can run
on a device, and you also need that
same provisioning profile on our device
so that it will authenticate that
app and allow it to be run.
Now, I want to ask a question.
How many of you wish the provisioning
was as simple as that animation?
I have some good news for you.
Hopefully some of you saw my demo yesterday, but we've
added automatic device provisioning in the new SDK.
We've worked really hard to make those
simple cases simple and allow you
to get started developing on a
device as quickly as possible.
You joined the developer program and everything else is
on the iPhone provisioning portal,
and everything else is done in Xcode.
Use that same login information from joining the
program, you enter it into Xcode, and, in fact,
Xcode will prompt you for this when you add a new
device and you don't have provisioning information.
Once you've entered that login information,
Xcode will communicate with the portal,
determine that yes in fact you are a member of the program,
and then check to see if you already
have provisioning information.
If you don't, Xcode will ask if you'd like to get started
creating the code sign in request that you'll need
to get your development certificate and it
will create it for you, upload that request,
as well as your device information from the
device you've connected, up to the portal,
which will create the certificate, create a
provisioning profile containing that device
and certificate and download it to your Mac.
Now for those of you who are working in teams,
this same process works for multiple certificates,
multiple engineers, and multiple devices.
And the way it works is it adds a wildcard app ID so
that this particular provisioning profile can be used
to develop any application, and all of
that gets wrapped up into a single profile,
which is then downloaded and installed by Xcode on your Mac.
Now, once you're making some changes, whether it's
your team's growing, you're adding a new engineer,
or you're buying now iPhone 4, so you can
test on those and you need to add new devices,
Xcode will automatically update that,
upload that information to the portal,
where a new provisioning profile will be
generated and downloaded back to your system.
And at any time, any of your team members can simply click
the refresh button in the provisioning profiles source
in the organizer to get the latest
profile or profiles for your team.
Now I say profiles, because once you get past the simple
cases, there are actually some reasons where you still need
to create a custom profile on the
iPhone provisioning portal.
In certain, for certain iOS features, such as
Push Notifications, they actually aren't supported
with a wildcard app ID, so you'll need to create a custom
profile containing and app ID for your application.
Another reason is distribution-provisioning profiles.
Once you're getting ready to distribute
your app, you'll need one of those,
and that needs to be created on the portal.
But there's still more good news, because Xcode will still
manage those for you once you've created them on the portal,
it will download them automatically for
you, and as changes are made to them,
they will be kept in sync with your development systems.
Developer Profiles are a great new feature
we added in the previous SDK release, 3.2.
And what Developer Profiles are is
all of the Code Signed Certificates
and Provisioning Profiles on your development system.
You can export that into a single file, which you
then take to another system, so that if you get,
you've been working on a desktop and now you've got
a new laptop, you can just export your provisioning,
your Developer Profile from your working
development system, move it over to the other system,
and you're immediately provisioned
and ready to go develop there.
Finally, I want to give a brief commercial
for some more sessions coming this week.
There's some great debugging features in Xcode,
especially targeting some unique features
about iPhone OS, such as Push Notifications.
The Xcode Debugger allows you to configure your apps
so that when you launch it, it actually doesn't launch
until it receives a Push Notification, at which time
the debugger will attach and allow you to debug.
Instruments is an extremely powerful tool that
makes it really easy to gather a huge amount of data
about your apps behavior, running it in the iPhone
simulator or on the device, and then also help you analyze
and make sense of it, to find and fix
performance problems in your code.
There's also something new in iPhone OS 4, a new UI
automation feature that is part of Instruments as well.
There's a new Instrument supporting that that allows you to
run a script against the application running on the device
so that you can automate your user interface testing.
And we think that's a great addition to Instruments,
especially in combination with the other Instruments
that can gather information about memory usage
and performance while those tests are being run.
And with that, I would like to ask Chris
Skogen to come up and give you a demo
of these last two sections about provisioning and building.
>>Chris Skogen: So I'm going to give you guys
a quick demo of debugging and using Instruments
on the app that Jacob started in his previous demo.
So we're going to bring up Xcode, here's Jacob's demo.
We're going to start by running the simulator
and looking for issues that we might have found
or might see in the process of running it.
Here's Jacob's app, oh my goodness, that's a horrible typo.
All right, so let's go fix that.
Now, I'm sure somebody will see where the bug is right away,
but I'm a bit of an idiot, so I'm
going to put a breakpoint here.
I'm going to go up and enable breakpoints
and I'm going to hit Build
And Run on the simulator, and I
will stop when I get to that spot.
Wow, what could be wrong here?
Oh look, I'm going to change this to app, perfect.
All right let's remove this breakpoint.
We'll stop it, and we'll run it again on the simulator.
Great, pretty straight forward.
I know you guys write much more sophisticated
code than I do, so , you'll have to bear with me.
Now we're going to go up to the Overview popup, now
that we see that its working right on the device.
We're going to go up to the Overview
popup and we're going to switch
over to an actual device and see what this thing looks like.
So I just choose Device, make sure my
breakpoints are enabled, hit Build And Debug.
Wow, look at all those fingerprints.
Now we're waiting for it to run, oh, something happened,
doesn't look like it's actually
run, yep, bad access, where is it?
I was accessing my mutable data here and I was setting
zeros in every 10, 24th position, don't ask me why,
and it seems to have crashed, so I'm going to
roll back up and, holy cow, I activated the,
I allocated way too much data for a device.
This is actually a good point,
back to what a good reference back
to the point Todd was making about
always build and run on device.
This app ran fine in the simulator, the minute
I put it on the device, the device cannot stand
that big of an allocation, it just doesn't run.
So, I'm going to go ahead and fix that, stop it, I'm
going to build and run on the device again, here it comes,
or there it is, and now I can go ahead and
hit Show Info, this is my iPhone app, perfect.
My app seems to run fine on the device now.
So let's go ahead, stop that and let's take a look
at Instruments and let's try to profile this app.
We've actually gone ahead and pre-set up a template for
Instruments that's going to use the UI Automation tools,
and the new Time Profiler, so I've got
that here in Automated Time Profile.
I went up here, go back here, we'll start over.
>>Todd: See it's an automations script,
so you want to run it multiple times.
>>Chris:Exactly. So I just went up to Run with
Performance Tool, choose Automated Time Profile.
Now it's going to launch Instruments,
it's going to set Instruments
up with a UI Automation tool and also the new Time Profiler.
Down here you can the Java script that we wrote
to actually put the app through its paces.
It's basically just going to go ahead and tap
the button for us, and take a screen shot before
and after tapping the button and record the results.
So right now it is actually already running and you see
down here, here's the Tap Show Info button, before the tap,
there's the screenshot that we took
after the tap, there's the screenshot
and the Show Info button tapped test actually passed.
Script is completed so we can go ahead and stop that.
And if you guys want to see the automation on the
device, I'm going to run the same process again,
and we should see the device automatically push
the button, show that, close it and we're done.
So what is in this Time Profiler that we can see now?
Well, we can actually see, if I go over here on the left and
I click, Hide Missing Symbols, and Hide System Libraries,
I'll just see all of the entries for the code in
my project as they were running on the device.
So here, we can see most of the time, 72% was
in Show Info, so if I double-click on that,
it will actually show me the code in my
Xcode project that I was using at the time.
So, that's it, that's a pretty quick tour of
the new Instruments features and also debugging
on both the simulator and the device, back to you Todd.
[ Applause ]
>>Todd: Thank you Chris.
Thank you.
So just again to recap, Chris built the
device and debugged and device in simulator,
and gave you a brief peek at Instruments.
I hope, again, you'll be encouraged to go check that
out in sessions later this week and also in the labs.
And the combination with your new UI Automation
Instrument and all the existing Instruments as well
as the Time Profiler Instrument that's new in iPhone
OS SDK4, just make Instruments even more powerful
and that time line there you can add multiple
Instruments and be able to correlate all that information
with individual events that you're sending with
your UI Automation script, it's very powerful.
All right, well we've developed
our app, we've built it on devices
that have been provisioned, now
our app is clearly ready to go.
You remember that great idea I said
you were going to come up with?
Well clearly we don't have it.
Now it's time to distribute our app.
So one of the great new things that we added in
iPhone SDK 3.2, is that instead of previously
when Xcode was pretty much done helping you once it built
your dot app, we now have first class support for a variety
of powerful distribution options
in Xcode and the latest SDK's.
It all starts with allowing you to
create archives of your application.
You can think of this as kind of a frozen build of your app.
One of the things that you have hopefully
known to do, that we documented, is that,
in order to be able to symbolicate crash reports that are
generated by that particular release of your application,
you need to preserve the descend that was created
from that specific build of your application.
Without it, you can't get it back and you
can't symbolicate those crash reports,
so you've probably been doing that manually.
Well archives do that automatically for you in Xcode.
Another huge advantage of using archives, is that previously
it was only possible to prepare your app for distribution
by building it and signing it in one-step in
Xcode, which meant that you couldn't actually test
that final release build of your app that you
were going to submit to the store or distribute.
Archives separate those two steps so that you can freeze
that build of your app, test it thoroughly and make sure
that those bits are good, and once you're sure they are,
then you can use that frozen build of your app as the source
for a distribution without having to rebuild.
Steve made clear that one of the most common reasons that
your apps aren't approved within that first seven days is
because the app actually crashes, and with archives
we've made it really easy for you to avoid that.
You simply choose the Build and Archive menu item
from the Build menu, and it creates your archive.
So what actually is an archive?
It's your app, your dot app bundle, and that unique
descend that was built when that app bundle was build,
and the Xcode creates a POS with metadata, so
that it appears correctly in the organizer,
so you can look that and find it, that's what it is today.
You may be wondering what's the difference
between this new archive and a snapshot
or a tag of my source that build that app in my repository.
Well, even if you have the exact source code that
was used to build that released version of your app,
each build is unique, and if you rebuild that same source,
you will not get an equivalent descend that would allow you
to symbolicate crash reports, so that your
source code cannot replace an archive.
Once you have your archive, you can use
the new validation features in Xcode.
Validation performs many of the same tests that will be
run on your app once you submit it for app store review.
It detects many common problems,
and often suggests fixes for them.
We really encourage you to take
advantage of this functionality
and validate early and often in your development cycle.
We have several different ways to do so, you can
actually, there's a way to run validation always
on build, and we'll talk about that more tomorrow.
And then there's when your preparing to distribute,
when you can run a validation on an archive.
Before you can run the validation on an archive from
the organizer, you will need to have configured your app
in iTunes Connect, which I'm sure you're all
familiar with, but the manager application areas
where you would set your application, its bundle identifier
and all that information before
you can actually validate your app.
I just want to briefly mention another important
organizer functionality, the ability to take screenshot
of your device, which can be used for many purposes,
including setting up your marketing
information on iTunes Connect.
You can also use it as the source or
literally the launch image for you application.
It's often useful for debugging, we saw taking
screenshots as part of our automation testing, and,
of course, very useful for documentation.
And, Xcode organizer makes it very easy
for you to take screenshots of your device.
Returning to validation, in the new archived application
source, you'll see all of your archives at the top,
organized by bundle identifier, and at the
bottom, there are three different buttons
for different sharing options;
first being Validate Application.
When I click that button, Xcode will ask you
for your iTunes Connect login information,
then ask you for which distribution provisioning profile
you want to re-sign your app for this particular validation
and which application you want to validate.
It will then re-sign your app with that
distribution provisioning profile, package it up,
upload it to iTunes Connect, the test will be run there,
and it will be reported back to you right here in Xcode.
There are many different types of errors that can be
found an reported this way, and we'll talk more in detail
about all of them tomorrow, but in fact this
one, I just am missing that iPad sized icon
and where I need to fix that in my info plist.
So once, once I validated my application,
there are many different options for sharing.
You can use your Ad Hoc distribution provisioning
profiles for these to do your beta testing
or distribute your app to a limited audience.
Xcode will re-sign your app, package it up again, and attach
it to an email, if that's how you want to send it out,
or alternatively you can just have it save that
package to discs so that you can post it on a website
or distribute it however you choose,
sneaker net if you must.
When you go to a larger audience,
you may want to take advantage
of the new Enterprise Distribution
feature that was introduced in iOS 4.
Xcode will actually help you create those files, and
again, we'll go into more detail about that tomorrow.
This scales much better that Ad Hoc
Distribution and can support, you know,
larger enterprises with getting your app
directly wirelessly to your employee's devices.
And , in fact, there's a session immediately following
this session where Chris will be performing another demo,
immediately following in Nob Hill about managing mobile
devices, where they will also discuss this feature.
They also have a lab coming up later this week.
Finally, once you've insured that this application is
good, it's the one you want to send out to your users,
you can use the final option, Submit
Your App to iTunes Connect.
We'll, again, perform the same test
that validate application does,
and then forward your app for App Store review.
So that it can get to its ultimate
destination, the App Store.
So with that, I would like to ask Clark to come up
and show you a demo of the demonstration features,
as well as a little bit more about the organizer features
that are very useful to you in developing your apps.
>>Clark: So I'm going to start by
opening this app you may have seen before
in Todd's demos yesterday, it's just the Picture Viewer App.
Now, say I'm ready to start distributing this app to a
group of beta testers or just some friends, whatever,
I can start by choosing the Build an Archive command.
Because I didn't have the appropriate provisioning
profiles on here, I can go, just hit Refresh,
and because I've already logged into the
portal, it downloads them all for me, and now,
I can come back to Picture Viewer, that builds fine.
So, I go to Build An Archive, you see it added another
archive to this list, I made a few earlier today,
and say for instance I wanted to go validate it,
so I enter my iTunes Connect info, hit Validate,
it defaults to choosing a distribution certificate, which
is what I want in this case and Picture Viewer is the name
of app on iTunes Connect, so I hit Validate.
And, just as in Todd's example, this app doesn't
have an iPad-sized icon, and to fix that I would,
of course, go add one and add it to the plist.
Now, say for instance I wanted to, as I said
before, share this with a group of beta testers.
I went to Share Application, again, you'll see that it has
this selected by default, if it didn't select the right one
by default, I could just explicitly choose my Ad Hoc
profile, and in this case, I'll chose save to disc,
I want to put it on the desktop, give it a name, and
its created all I need to send out, it's the IPA file,
I can just email that, put it on a
webpage, whatever, get it to my audience.
Additionally, there are other options, email would have
created the same file and just opened up mail with it
as an attachment ready for, ready to be sent out.
I also have the Enterprise Distribution option, which
will query me for all the information that I need
in the manifest.plist file, of course there will be more
about this in the, in the managing devices session later.
Now also, submit to iTunes Connect is basically identical to
validate in every way, except that after validation passes,
it actually goes and does the final step of
submitting it to the App Store for review.
That's generally what's involved now with distribution.
There's a lot fewer steps than before, and
they are a lot more simple and straightforward.
Now I'm going to show you some other things in
the organizer that we've added in 3.2 and 4.0.
One is the Developer Profile, which Todd mentioned before.
These are all of the signed certificates and
provisioning profiles I have on my system.
If I were to export this, give it a password,
because this does contain private keys
so it's important that it's protected.
Now I could take this file, import it on any other machine,
even that had never been set up for iPhone development yet,
and I would get this same set of profiles and
signed certificates, and I'd be up and running.
Additionally, as you saw before, if I
say deleted one of these accidentally,
I could still refresh and get it right back.
And with that, I'll give it back to Todd.
[ Applause ]
>>Todd: Thank you Clark.
Just to recap again, we've seen the various
distribution features, including validation and sharing
through Enterprise Distribution as well as
simply packaging up for Ad Hoc Distribution.
There are a number of other features in the organizer;
taking screenshots, symbolicating your crash logs,
which you can simply drag into the Organizer Crash
Logs tab, that's where you restore your devices,
and of course you've accessed the device console
for debugging message or seeing what going
on in your device while you're working with it.
Of course, all of this works with Xcode 4 as well, and we're
really looking forward to your feedback on how Xcode 4 works
for you for your iPhone development, but again,
you still need to use Xcode 3 for your work
to actually submit your apps to the Store.
I also want to emphasize that we made it very easy for you
to experiment with Xcode 4 because its completely compatible
with the Xcode 3 project format, so it's very easy
for you to work on your same project with Xcode 4
to see how it works for you and give us feedback and then
to go back and build your app in Xcode 3 when you're ready
to submit, and ultimately get your app in
the Store and earn that Five-Star review.
So with that, I will conclude and
point out some of the references.
The Dev Center, which has lots of great
resources for you as iPhone developers.
The developer forums, which I definitely encourage
you to go and check out and help each other out
and we will certainly help you there as well.
Michael Jerkewitz is our developer tools evangelist, and
you can submit questions and comments to him as well.
We've got a number of great sessions later this
week, and I wanted to kind of give you a commercial
for many different features that we've just touched on in
this session, whether it's Instruments, Interface Builder,
Xcode 4, the user interface testing and of course
the second half of the session tomorrow morning.