Transcript
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
[ Applause ]
>> Hello, everyone.
And welcome to session 415,
Maximizing Apple
Development Resources.
My name is Nahir Khan and
I'm an iOS Software Engineer
on Springboard.
So today, we're going to go
over all the different types,
development resources
the Apple provides to.
And we're going to
break them up into
about three main categories.
First one, is Self Help and
this is where we are going
to cover Documentation
and Dev Forums.
The second, once you've gone
through those is
working with Apple.
And with that we're
going into Bug Reporting
and Developer Technical
Support or DTS for short.
Finally, once you've got
your app all ready to go,
we're talking about getting
your app in the App Store
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
and over here we're
going to talk
about App Store and
iTunes Connect.
So that, let's start.
So the first main
category is Self Help.
So the really nice thing
about these resources is they
can access them 24 hours a day,
seven days a week.
And they're going to get let
you work at your own pace
and get all the information
that you need without having
to come here or somewhere
else, it's really nice.
So first one we're going to
go over is documentation.
So I'm sure you guys
are very familiar
with this site,
developer.apple.com.
So this is the first place that
you should go when you start off
and you learn a new
API, the item we came
up with say this week or
is it the new API to you
that we've had for some time.
First thing you should almost
always do and check out our WWDC
and Tech Talk videos 'cause they
give you a nice broad overview
of our APIs and designs
and brand new features.
Once you've done that,
the next best thing
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
that you can do is go into--
and take a look at all the
documentation we have here.
We got lot of getting started
guidelines, so if you just want
to get in, try to figure out a
broad overview what's going on,
this is exactly where
you can go.
We also have our entire
development library here,
so if you want to
figure out how some API
or certain classes work, this
is also where you should go.
Lastly, you can also download
all of the sample code
and projects that we
provide for any or many
of the APIs that we have.
There are many new APIs
that came out this week,
and if you want to
understand how they work,
it's a great place to
download and check it
out and run it yourself.
So let's get in the
class reference.
So, I'm sure many of you
are familiar with this,
this is where you can
get the entire reference
for your entire API,
you can get--
take a look to see what
are the arguments I need
in your method names,
all that good stuff,
you can also see example code,
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
so you can see exactly
what you need to do
to actually use these
great new features in APIs.
And lastly, you can also
checkout some common issues
and frequently asked
questions that we have
or that you may have
about the APIs.
There's usually, if
you have a question,
and you not really
understand what's going on,
there's usually a very
good chance that's covered
in the common issues and
frequently asked questions.
One thing I should want to call
out our full programming guides.
These are entire books
worth of content here,
whether it starting off with
Objective-C and you want
to know how that works, you got
there, or say you want again
in to OpenGL, we actually have
the entire documentation on that
as well, or in this case we
have brand new text editing APIs
and iOS for iOS 7,
really great stuff here.
But I know what you're thinking,
you don't want to go onto--
have a Safari window open
and have that next to you.
If you're anything like me,
when you're coding away,
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
you want to be able to access
stuff nice and quickly.
And the cool thing is, you
can access all the stuff right
from Xcode and the Help menu.
Go there and you get
the documentation API
Reference guide.
And the nice thing is in Xcode
5, we've actually revamp this
to make it really, really
nice and easy to go through
and check these things out.
And not only that, there are
a lot of other cool things
that you can do in
Xcode as well.
For example, the
Option-click on any symbol,
you can get a nice quick
description of what's going on
and also access the header
files if you want to go in
and get maybe a bit
more information.
The nice thing is you can also
get a one click access directly
to the Reference guide there.
So you don't actually
have to like go and search
for that online, you got
it right through Xcode.
We also have a bit more
information in the sidebar
when you click on the symbol.
You get the same access to the
headers and the API reference,
but you also get our links
to any programming guides
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
that might be helpful with
that particular symbol
that you'll looking at.
Another nice thing is that
you can get one-click access
to some sample code as well,
it's really, really nice.
One thing I want to call
out though is at the bottom
of all our documentation
pages is a feedback area.
So over here this is where you
can go and report any typos,
missing information
that you see,
maybe if something
it's confusing or even
if something was helpful,
this is really great
where you can tell us how we can
make things better even for you.
So, if you go in
and you find, wow,
this are really nice document
I was reading and I'd really
like it some more stuff
is like that, let us know.
If you think, that was like
90 percent that way there,
but there is something else
that could make this even great,
let us know that or something
wasn't helpful at all,
that's where you can go.
So once you've actually
gone through documentation
that you're working on,
still not sure what to do,
the next best place you can
go is the Developer Forums.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
So devforums.apple.com and
we have areas for iOS, OS X.
And we also have areas for
our tools and also deployment
and other types of things
that we provide as well.
So the nice thing about
the developer forums is
that you have peer support.
So you're actually there
working with the rest
of the Apple developer
community.
So when you have an issue and
you're not sure what's going on,
the nice thing about the dev
forums, it's a really nice place
where you can go
and get some help
and maybe triage your problem.
So, see and try to
actually drill
down to see what exactly is
going on, is it may be an issue
in a certain API was working, is
it maybe issue in your own code,
maybe it's an issue
with some virus stuffs,
it's where you can do that.
The nice thing is,
you can also search
if someone else has a question,
maybe it'll be helpful to you
or if they get that answered.
And also, you also have Apple
employees there as well.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
So over here, if you see an
Apple avatar right there Dr.
Ernie, he's actually
one of our moderators
that you can see always
around helping people out.
And there are also
engineers on here as well.
So if you have a question,
engineers are visiting
these as well.
One thing I want to
call out though is
that the forums are
kind of public,
so if you have a question that
might be a bit confidential
for your own application,
everyone can see
what you post here.
So if you don't want
to go through that
and don't want everyone to
see what your secret stuff is,
I suggest you check out DTS,
and we'll go into that in a bit.
So let's go over an example
post, don't need to go
into too much, just some
things I want to call out here.
So over here we have
someone who's has--
is reading some of our example
code and the guy got confused
on something, what's
going on here,
it doesn't really
following some guideline.
And actually, Rincewind is
actually an Apple engineer.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
So if you ever see an avatar
with the little Apple
logo right next to it,
know that's an engineer
helping you out here.
Also we have little area there
where you can say a post
was actually helpful
or not very helpful to you.
And the nice thing is other
developers can see this as well.
So someone answers your question
and it really helped you out,
let other developers
know so that they'll know
that this is exactly
what they need to--
that's an exactly
answer that they want.
You'd also report a post.
So that doesn't necessarily
mean that something is bad here,
it could be as really
great question
but maybe it's in
the wrong area.
So if you click there, a
moderator can go take a look
on what's going on,
actually moving around.
Next, once you've gone
through all these things,
let's go in the areas
about helping with Apple.
So you work with
some documentation,
you got your app ready to go
and you need some help from us.
So, one of the first main areas
about this is bug reporting
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
and for that I'm going
to hand off to Tanya.
[ Applause ]
>> Thank you, Nahir.
Good morning, everyone.
Thanks for joining us
here, I know it's Friday
and it's almost lunch.
So I'll try to make it
as quick as possible.
My Name is Tanya and I'm
an iOS Software Engineer
on the MAPS team.
And today, we're going
to talk about a topic
that is very near
and dear to me.
In fact, it's near
and dear to a lot
of Apple engineers,
bug reporting.
And we're going to talk about
how you can utilize bug reports
to communicate with Apple
regarding the issues you've been
running into.
So let's start with the
very fundamental question
on why should you
file bug reports?
You should file bug reports
because it provides a way for us
as Apple engineers to
help you out directly.
You see we worked really hard
to make an amazing platform,
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
make amazing tools that help
you make wonderful applications
that delight our customers.
But sometimes, there might be
issues, there might be problems
that we did not anticipate,
and when you run into these,
we would like you
to let us know.
We would like you to let us know
so that we can take
the appropriate action
to address those quickly.
When you file a bug
report it goes directly
to an Apple engineer, I
read these bug reports.
All the engineers, you might
have met during the labs
and sessions, they
read your bug reports,
they're surely not eaten by
the trolls in our dungeons,
this feedback is important,
these back reports
are important.
So, if you want a direct
communication channel
to an Apple engineer to
tell us some of the--
to tell about the issues
that he would be encountering
in our software, bug
reports are the way to go.
Sometimes, when I tell
people to file bugs,
they have a few questions.
Sometimes they say, well,
Tanya, I saw this problem,
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
but it was an extremely
trivial issue,
you see perhaps it was a typo
or the color was a little off,
should I still file
a bug report?
Yes, absolutely.
File a bug report.
You see, a problem
that might seem trivial
to you might have some
really bad consequences.
Also it might manifest
itself in worse ways.
So file a bug report.
Sometimes we say, well, you
know, this problem happened once
and it never happened again,
I never ever saw this again.
Should I still file
a bug report?
Yes, you should file
a bug report.
You see, even though, the
problem only happened once,
it might still have been a
really bad user experience.
Others might hit it too and
other might hit it more number
of times, so file a bug report.
Sometimes they say, well,
it's a really obvious problem,
I'm sure you have 12
copies of the bug.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
I am sure someone else
has already filed it,
should I still file
a bug report?
Yes. You should still
file a bug report.
You see, it's better to
have five copies of the bug
than to have none at all,
there's a good reason
I say that.
At Apple, if an issue is not
tracked using a bug report,
it essentially does
not exist for us.
Bug reports are like
to-do items,
we track everything using bug
reports, bugs [inaudible],
even big features that go
into a particular release.
And some other things
that might not seem
so obvious to start off of it.
When I come into work
every morning, in fact,
when all Apple engineers
come into work every morning,
the first thing we do is to
go through our list of bugs
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
to figure out what is it
that we need to do that day.
To figure out, if you're on
track for a particular release,
I know that's a good
one, it's an actual bug.
To figure out, if
you're on track
for a particular release our
program office, our management,
they go through a list of bugs
to figure out if you're focusing
on the right things
at the right time.
So we track everything using
these bug reports, bugs,
features, coffee
problems, elevator problems,
all of that, these
are important.
So now that we know why these
bug reports are important,
where do you actually
go to file these?
The one stop shop for filing bug
reports is bugreport.apple.com,
this is the only official
way of filing bug reports.
When you file a bug report, you
are provided with a problem ID
and you can use this ID to
track the status of your bug.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
Also, even after the bug
is filed, you have a way
to provide additional
information.
On the other hand,
if the engineers have any
clarifying questions for you,
they have a means to get back
to you with these questions.
And one thing to keep
in mind when you're file
in this bug reports is
to keep things specific.
Follow the golden
rule of bug filing,
just to use one report
for one issue.
Things that might seem
related to you, and might seem
like they can be
grouped together
into one bug report might
actually very different things
and there might be different
engineers working on it.
So help us track things better
by keeping things specific,
so file one report
for one issue.
So what do you file
these bug reports for?
Well, when it comes to software,
there are few things you can
use these bug reports for.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
Bugs, if you notice something
does not work as expected,
that's a software defect, that's
a bug, so file a bug report.
If you notice an application
quits unexpectedly or crashes
or if it's hanging and
unresponsive, file a bug report.
If you notice your
application slow or hanging
or perhaps leaking memory
and you think it's a problem
in our API, file a bug report.
If you have a suggestion for a
new feature or an improvement
of an existing feature,
file a bug report.
One thing to keep in mind
when you're filing
these bug reports is
to file them as early
as possible.
Do not wait till the last
seed to report an issue
that might be blocking
essential functionality
of your application.
There's a good reason why
I say that and it relates
to how we schedule things.
So let's look at the
graphical representation
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
of the problem at hand.
So the horizontal axis
represents the various
milestones in our release.
The vertical axis
represents the probability
that the bug will get addressed
in that particular release.
If you notice the blue line
that relates little
parameters curves downwards.
So if the green arrow
had to present
when we receive the bug
report, you can tell easily
that the sooner you file,
the higher the chances
that your bug report,
bug will get addressed
in that particular release.
On the other hand, if you
wait till the last minute,
we run out of time.
Also the fix that is needed
to resolve the problem
you had reported,
it might be very risky, so we
might not be able to incorporate
that into a particular release.
But does that mean,
it just expires,
we don't look at it ever?
Absolutely no.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
We will address that
in the next release.
Now there are few
other things you can do
to improve the chances of your
bug getting fixed in time.
But before we talk about that,
let's look at what actually
happens after you file your bug.
So as we had established
earlier,
it goes directly to
an Apple engineer.
The engineer might forward
it to other engineers
if the underlying cause
of the issue is not
in their area of expertise.
But for the sake of
simplicity, let's just assume,
it stays with that one engineer.
Now in the perfect scenario,
the engineer will understand the
problem, will investigate it,
come up with the fix, and
integrate that into a build.
Once the fix becomes
available in a release build,
we send the bug back to you.
Now we recommend that when
you get back the bug report,
you verify that the problem
was fixed and we also recommend
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
that you do this as
soon as possible.
You see sometimes, the issue
might not have actually been
fixed and you have the option
of sending the bug back to us
and by responding
quickly, you make sure
that there still enough time
for us to reinvestigate it
and still fix it in
that particular release.
Sometimes, the bug
may come back to you
as a duplicate, what
does this mean?
This means that there is an
existing bug report that we have
that is tracking the same
issue as you had reported.
Now does this mean this is
just a waste of your time?
Absolutely not.
Duplicates are important.
You see, your bug report
might have better information,
it might have more
actionable data
than the original
bug that was filed.
Also many times, we use a number
of duplicates as an indicator
of how widespread the problem is
so that we can prioritize
it correctly.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
Even if your issue was tagged as
a duplicate, you have the option
of requesting status of the
original bug, just put a comment
in your bug report and we will
provide the relevant information
to you.
Sometimes, when you file a bug,
we might send it back to you
as insufficient information.
What does this mean?
This means that the bug report
does not have enough information
for us to diagnose the problem.
Now if possible you
want to avoid running
into this scenario, and there
is a good reason why I say that.
Let's bring back our older time
versus [phonetic]
probability graph
and see what it looks like.
If you read-- you did the
right thing by filing early,
so you started out strong.
But unfortunately, the bug
report did not contain enough
information, so we
sent it back to you
with clarifying questions.
You collected the information
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
and sent it back to
us which is great.
But unfortunately in all
this valuable time was lost.
So even though you had
started out strong,
you end up on the lower
part of the curve.
To avoid this back and
forth formal information,
start out with a well
written actionable bug report
in the first place.
To make your bug report
actionable it should be clear,
concise, informative,
constructive and specific.
To ensure that your bug report
has all these qualities,
let's go to the different
components of a bug report
and talk about some of the
things you should keep in mind
when you're filing a bug report.
So here are the different
components of a bug report,
the problem report title,
the problem detail section,
additional enclosures,
configuration information
and reproducibility.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
Let's start by looking
at the title.
Think of the title as an
advertisement for your issue.
You want it so that when the
engineer reads the title they
want to open it and
investigate it.
A good title is clear
and succinct.
Think of it like a tweet, you
see, you have limited space,
but yet you want it to convey
as much information as possible.
So make every word
count, avoid filler words.
Drop off any articles of
preposition or pronouns
that are not needed there.
So a good title should
stand on its own.
You see a title is often seen
a list of tens or thousands
of bugs and could be
totally out of context,
also above title is often use
as a search for you issue.
So, when you're coming up
with the bug title think
about how is it that you
would search for the issue
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
and hopefully that will
give you some hints
on how to structure it.
So let's look at an example.
Here we have one, copy
and paste is broken.
Now, it's surely succinct
its only five words.
It's probably descriptive
though,
it doesn't really tell us how
is it if we perform the copy
and paste and surely we don't
know what we mean by broken.
So let's improve this further.
Here we are at information
about how is it's that we--
that perform the copy operation.
This is fine.
But there's still the
word broken in there,
which is not descriptive.
So we add information about
what is it that we saw.
Now this is pretty good,
but we can get bonus points
by prefixing it with
the software version
where we saw the problem.
Now this is especially
relevant for seed build,
'cause when we see the title
we can clearly and easily tell
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
that this problem
was encountered
in a seed build versus
a GM Build.
Next up, is the problem
details component.
When we talk about problem
details we mean be descriptive.
Remember, the engineer who's
reading your bug report was not
present with you when
the problem had happened.
They had not seen
what you had observed.
So tell them about it, and
this is the place to do that.
The problem details component
has five different subsections.
Let's talk about each
of them one at a time.
Start with summary, the problem
summary section is probably
recapping the title and
include some more descriptive
summary information.
What was going to?
What happened?
And why is it a problem?
If you encountered an error
message, this is a great place
to put the exact text
of the error message.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
And so remember be specific.
Saying Safari is slow is
generally not good enough.
Is Safari slow compared
to other browsers?
Is Safari slow compared to
Safari on other machines?
Is Safari slow compared to
Safari's earlier versions?
Be specific.
Also use the correct
terminology?
If you're not sure what a
particular control is called,
use a screenshot.
Because that will tell
us exactly what it is.
So be precise and
avoid weird language,
saying nothing happens
does not communicate much.
Instead tell us what is
it that you did expect
to happen and did not happen.
So instead of saying nothing
happens when I try to print
from Safari, try
saying this instead,
the printer progress
dialog does not appear
after I select the print button.
That is much better.
So let's look at
an example summary
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
for the copy and paste problem.
We start out by recapping
the title which is great,
and then we add some other
observations that we had made
when the problem had occurred.
This is pretty good.
Next up is steps to reproduce.
The problem with steps
to reproduce is to think
of what it would take
to reproduce the issue
on a freshly set of
device of machine.
Pretend you're telling your mom
on how to reproduce the issue.
Put yourself in the shoes
of the engineer and think
about what is it that
they might need to know
to diagnose the problem
correctly.
So anticipate the sort
of questions they
might have for you.
Also remember do not make
assumptions about them knowing
about your application.
So be specific.
Instead of saying open the
file, tell us how is it
that you open the file.
Did you open the
file using finder?
Did you open the
file using terminal?
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
That might be a relevant
piece of information.
Always remember it's better
to include more information
than less.
So with that, let's
look at an example.
The same copy and paste
problem we've been working with.
So we start out fresh, we do not
make any assumptions of the code
that might have happened
before this.
We provide information
about how is it
that we perform the
copy operation.
Next up, we move onto how is it
we perform the paste operation.
We launch the Mail app,
select the compose button
and then select the paste button
that appears in the callout.
This is pretty good.
Next up, are the two
results sections,
expected results
and actual results.
Use these sections to specify,
what is it that you'd
expected to see?
And how was it different
from what you actually saw?
Now this piece of information
has actually very important,
because sometimes what you
expect might not be consistent
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
with what the engineer expects.
So by specifying this we can
clearly tell why you thought it
was a problem what had happened.
Let's look at an example.
Start out by specifying, what is
it that we did expect to happen?
Which was us being
able to paste image.
Then we specify what is
it that actually happened,
which was us ending
with an image,
containing a blue box
containing question mark.
Now it might not be clear
what is it that we mean
by this blue box
containing a question mark.
So in all these cases attaching
a screenshot is a great idea,
it will tell us exactly
what you saw.
With that let's talk about
the regression section.
Use a section to specify
when does the problem occur,
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
when does is it not occur?
So did the problem happen
in the first seed of iOS 7,
but did not happen
in iOS 6 and earlier.
Also does the problem go away
if the application is relaunched
or if the machine is rebooted?
All that is relevant information
for the regression section.
Let's look at an example.
We start out by specifying,
when is it that we
did see that problem?
Which is the iOS 6 seed.
Then move on to specifying
the software configuration
where we did not
see the problem,
which is iOS 5 and earlier.
We also provide some other base
we had not seen the problem
which was using an
alternative way
of performing the
copy operation.
Let's talk about
the next component
which is the additional
enclosures.
Now when you're filing a bug
report there might be extra
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
information that you
can attach to your bug
that will greatly help us
understand the problem a
lot quicker.
Now an example of that
is a sample project.
You see, when I find a
sample project attached
to a bug report it pretty
much feels like finding gold,
because these are awesome.
They are great for two reasons.
First, it helps you isolate
the problem to figure
out if it's an issue with
your code or with our API.
Second, it helps us understand
the problem a lot quicker,
because we have a focus
example to work with.
So sample projects are great.
In addition, there might be some
other logs that you can attach
that will greatly help us
diagnose the problem quicker.
Our online webpage has some
excellent documentation
on what sorts of
logs you can attach
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
to what sorts of problems.
And it also has detailed steps
on how you can go
about retrieving it.
Let's go through of few of them
that are common in
a lot of cases.
First up are crash logs.
So if you run into
a crash you may want
to attach the crash log.
To retrieve the crush log
for an iOS device start
by connecting the device
to your host machine.
And then sync it with iTunes.
This will transfer the log file
from your device to
your host machine.
So the next step is
to locate the log file
on your host machine.
Now, if you're using a MAC,
look under this location
which is the User Directory,
Library, Logs, CrashReporter,
MobileDevice, and then a folder
name corresponding to the device
where the issue had occurred.
You'll see files of this
format, there will be prefix
for the name of the application
of the process that had crashed.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
And will also contain
a timestamp
from when the issue
had occurred.
So hopefully this will provide
you with enough information
on figuring out which is
the file you need to attach.
If you had connected your
device to a Windows machine,
it's the same steps, but
you just need to look
under a different location.
If you'd encountered the
crash on in OS X machine,
look under this location which
is the User directory, Library,
Logs, DiagnosticReports,
you should see the files
for the same sort of format.
They'll be prefix for the
crashing application process
name and will contain
the timestamp
from when the problem
had occurred.
Next up are console logs.
Now these logs are great
because they capture some really
important application and
system state information.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
They might contain
some error information
that will help us understand
the problem quickly.
So to capture these
for iOS devices,
launch your Xcode organizer
window, select the console tab
from the left inside panel.
Reproduce the issue if you can,
and then save it using the Save
log as button at the bottom.
On OS X it's a bit different,
we use a different application
called console, it's located
under the Utilities folder of
your Applications Directory.
So once you launch it, you get
a window that looks like this.
Select the All Messages tab
from the left inside panel,
reproduce the issue if you can.
And then save it
using the Save a Copy
As option from the File menu.
Screenshots, now a picture
is worth a thousand words.
And this is especially relevant
when it comes to bug reports.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
You see, you might have
run into a display issue
or a screen rendering
issue that is very hard
to describe using words.
Or as we had mentioned earlier,
you might have use the control
and you don't know
what it is called.
So use a screenshot in
all these scenarios.
To capture a screenshot
on an iOS device,
press and release the Power
and Home button together.
And that should save
the screenshot
as a photo in your photos app.
So you can go about retrieving
it using the usual ways
of either emailing it or
syncing it with iTunes.
There's an alternate
way you can use which is
to use the Xcode Organizer.
So select the screenshots tab
from the left inside panel
and then use the new
screenshot button at the bottom.
If you want to capture
a screenshot on OS X,
there are few different
commands depending
on what is it that
you want to do.
To capture the full screen,
use Command+Shift and 3.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
To capture a part of the
screen use Command+Shift and 4,
and just specific window,
this is actually handy,
Command+Shift+4, and
then press the spacebar.
All these shortcuts save
an image on your desktop
that you can very easily
attach to your bug report.
You know sometimes
screenshots are not good enough.
Perhaps you're trying to
describe a sequence of events
or a bad animation or
something being slow.
In all these cases screen
recordings are great.
To capture a screen recording on
OS X, launch QuickTime Player,
select the New Screen Recording
option from the File menu,
select the start recording
button, reproduce the issue,
stop the recording you should
have a movie file you can very
easily attach to
your bug report.
This will be great.
Next up are snapshots.
You know, snapshots are
essentially a state snapshot
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
of all the processes
that we're running
at the time the snapshot
was captured.
So if you run into a performance
issue on an iOS device.
If something is slow
or something is just
stacked doing some task,
capture a snapshot.
In fact capture multiple
snapshots because since each
of these is a snapshot, we
might need multiple to figure
out what is exactly
causing the slowness.
So to capture a snapshot
on an iOS device,
press and release one
of the volume buttons
and the home button together.
This should create a
log file on your device
and use the same ways of
retrieval as a crash log.
So connect to your device,
to your host machine,
sync it with iTunes and
look under the same location
as you would for a crash log.
The log file will be
prefixed with the word stacks
and will contain the timestamp
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
from when the problem
had happened.
If you run into performance
issues
on OS X capture sample logs.
So if you notice
something is slow
or something is just stack doing
something, capture sample logs.
So launch your terminal window
and run sample with the name
of the application or process
that is behaving poorly.
Now that should all put a file
that you can very easily
attach to your bug report.
Another great tool
that is available
on OS X is sysdiagnose.
So, if you run into a
system performance issue
on OS X this will capture a lot
of very useful state
information.
So launch your terminal
window, type in sysdiagnose,
take a few minutes to run.
But by the end of it, you'll
have a collection of rich logs
that you can attach
to your bug report.
I have to admit, this is a lot
of work and it's probably going
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
to take a lot of time.
But even though collecting
this information,
sort of making the
sample project
or attaching these logs they
might be optional in some ways,
you might still want to spend
the time collecting this.
And let me convince you by
bringing back the good old time
versus probability graph.
You see when you attached
this additional information,
[inaudible] sort of moves up.
The chance is that
the bug will get fixed
for that particular release.
It goes up because
it's much easier for us
to understand the
seriousness of the issue.
Understand the issue
itself as well.
So the next time you're filing
a bug report, think about it,
whether to spend that extra
time collecting this information
in order to improve the chances.
With that, let's talk about
the configuration information
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
component of a bug report.
Use this section to
specify the software
and the hardware configuration
of the device or the machine
where you saw this problem.
So in iOS, this would be the
hardware model and version,
the exact software version.
Now, remember, sync iOS 6
is generally not good enough
because we shift
many different builds
of iOS 6 in the last year.
So, to find out the
exact version,
launch the settings app,
navigate to General-About
and look under the
version field.
You should find the exact string
corresponding to the build.
Also if there was any
other hardware involved
in this problem that you
saw specify information
about that as well.
On OS X the best way to capture
configuration information is
to use the system
information report.
And our online documentation
has some excellent steps
on how you can go about
collecting this information.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
Last component, we're
going to talk
about is the reproducibility
section.
Use this section to
specify how often is it
that you see the problem.
Do you see it always?
Did it only happen once
and you never were able
to reproduce it again?
Even if you did not try
to reproduce the issue,
still tell us about that because
that is still a relevant piece
of information.
With that, we have
reached the end
of the bug reporting section.
But let's recap what we learned.
We talked about why bug
reports are important.
They are a direct communication
channel between you
and an Apple engineer
so that you can tell us
about the issues you've been
running into with our software
and we can address
those appropriately.
These bug reports are read
and very diligently
tracked by Apple engineers.
The timing is important in
filing these bug reports.
So file as early as possible.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
Also start off with well
written actionable bug reports
that are clear, concise,
succinct,
informative and constructive.
We also talked about a few
things you should keep in mind
to improve the chances
of your bug getting fixed
in a particular release.
With that, I like to hand it
over to Ted who's going to talk
to us about Developer
Technical Support.
Thank you.
[ Applause ]
>> Thank you Tanya.
So, I'm Ted Jucevic.
And I'm here to talk to you
about Developer Technical
Support.
So, Developer Technical
Support or DTS is a organization
of engineers that provide one
to one support of public APIs
through email with a guaranteed
response for developers
of our iOS, OS X and
MFi developer programs.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
So, if you have question
about how
to integrate an Apple
technology or you have a bug
in your app you can't resolve,
or a code level question related
to the development of your iOS
app, Mac app or MFi accessory,
we can help by providing
best practice guidance on how
to use our APIs and
troubleshoot.
So, when should you contact DTS?
Before you contact DTS,
make sure you've read the
relevant documentation.
You've checked on
the forums to see
if your question has already
been answered by somebody else.
Write some test code.
And if appropriate,
do post your question
to the developer forums.
But if you still need help
after you've exhausted all
of the resources, contact DTS.
So, you've decided that
you're going to contact DTS.
To do that, what
you need to do is go
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
to
developer.apple.com/membercenter
and click on the technical link
in the developer
support section.
This will take you to a page
where you can request help.
Fill out and submit the
technical support web form.
And all follow up
correspondences
with DTS will be through email.
So, we need a lot of the same
information that is required
when filing a bug report.
An Xcode sample project,
Symbolicated Crash
Logs are all important.
Now, Symbolicated Crash Logs are
crash logs that have the symbols
so the memory addresses,
translated into human
readable function names
and my [phonetic] numbers.
Many times after somebody had
some Symbolicated Crash Log,
they look at it and they
can actually figure out how
to solve the problem themselves.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
If not, when you
submit the support
for request make sure you
include the Symbolicated Crash
Log because if you have a
crash, we're going to need one.
So, I've told you about what
DTS does, how to contact DTS
and how to work with us.
Let me start off or end this
part by giving you some answers
to some common questions
that we get in DTS.
So, all these answers
are actually
in technical note
documents that we've written.
For example, the ones that
are list on this slide are
on the iOS Reference Library
for you to-- you can find 24/7.
The first one, iOS Debugging
Magic has a relative information
for both new and
expert developers
who are debugging
iOS applications.
And it's one that I would
highly recommend reading
if you have started debugging
your app, or your about to.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
The second one, understanding
and analyzing iOS
application crash reports.
It's important because
it explains to you how
to symbolicate your crash logs
and also gives information
about common exceptions
or other information
about what may be
causing your crash.
The rest of these are also
important, I'm not going to go
into them for time, but
make sure, you know,
they're worth your
time to read them.
On the OS X side, we have
some similar documents set
that I also recommend
you take a look at,
if you're working on
an app on the Mac.
The Mac OS X Debugging Magic
is like the iOS version
where it has a treasure trove
of information for both novice
and expert developers, and
then of course the second one,
how to reproduce bugs report
against a Mac App Store.
Well, the title kind of explains
it completely for itself.
So, thank you very much.
With that let me hand
you back to Nahir.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
>> So now, you've made your
app, got all the help you need
and you want to get to
it to your customers.
And you put it on the Mac App
Store or the iOS App Store.
So for that let's go on that.
First one is the section
that we're going to talk
about is the App Store.
So, we have a whole page for
developers at developer.com--
developer.apple.com/appstore.
And this is where you can learn
about our approval process
and exactly what we go about
when we're actually trying
to approve your app
to get on the Store.
There's also where
you can and figure
out what the guidelines are
on what's actually
allowed in the Store.
I recommend you check that out.
We all have some other
cool stuff here as well.
So, if you've ever been on a
website and you've seen those
on the iOS or on
the App Store links,
or you've seen this really
nice product images for our--
some of our products, you
can actually download all
that on this website.
You can get full
pictures of our products,
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
you can get to those links.
And we also have some guidelines
on how these things are going
to be used, so check that out.
There's also a really
nice contact form here,
if you have any questions
for the App Store.
So, I [inaudible] with
all these other ways,
there's one single
place you can go
for all your communication
with the App Store.
So, on this page, you can
get the status of your app.
So, if you've put it
in and you're trying
to see what's going
on, what's going
to review process,
this is where you go.
This is also where we
can get some-- get--
give us some clarification on
an app if it's got rejected.
Maybe someone miss something.
The app reviewers are people
and sometimes we make mistakes.
So this is where we can
also know what happened.
If your app has been rejected,
there's also where you can go
to start off with the
appeal process, because just
because your app has been
rejected doesn't mean they'll
never be allowed
in the App Store.
We can work together to get
back in there or get in there.
This is also where you go to
get an expedited app review.
So, if you have an app in
the App Store right now
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
and you notice there's a very
horrible crash and you needed
to get it out there, that's
where you can go to start that.
Now, just as warning, you can
do that for every single one
of your submissions to the App
Store because we kind of catch
on to that and we're
going to allow that.
This is also where you can go to
provide requested information.
So, say we want to host
your app or feature it,
this is where you can add some
information for there as well.
Next we're going
to iTunes Connect.
And I'm sure many of
you are very familiar
with iTunes Connect.
This is where you go
to handle everything
about managing your app and
the business of your app.
This is where you can go
on to see your sales trends
to see what's going on there.
This is also where you can go to
setup all your contracts and all
of your little tax information
and all the other
stuff that you can do.
This is also where can go to
setup iAd and all those stuff
that you need to get
ready to have ads in
and deal with the ad process.
And also you can go in to
get In-App purchases and how
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
to set those things up as well.
Now, iTunes Mac is huge
and there's some questions
that you might have.
So, there is a frequently
asked questions phase there
and I highly recommend
you check it out.
There are a lot of
good information here
and you have a question there's
a very good chance that's
answered right there.
But if you don't want to go
through, you can also check
out the Contact Us Page.
And it's kind of nice because
got to hold drill down menu.
So, in this case, I'm Canadian
actually, so I'm trying
to figure out what's going on
to get my, like Canadian deals
and tax information and all
that, I can actually go in there
and say, oh, I will
have something
with the tax information and
I'm for-- kind the tax forms.
And it tells me exactly
what I am to do
and where I can get
more information.
It also gives me some related
frequently asked questions
pages, so you can
check that out as well.
Now, iTunes Connect as I
mentioned is a very large area,
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
so we actually have gigantic
guidelines here, both for iOS
and Mac developers and I highly
recommend you check these out.
They go step by step on how
to do multiple different
things in iTunes Connect.
So with that, coming to the end
of our presentation, so today,
hopefully we got a
bit of understanding
of all the different developer
resources that are available
to you and when you
should actually use them.
So we went over, saw the ones
that are great for helping--
getting help yourself,
also a bunch of resources
when you're working with Apple
and also all the
resources available to you
for when you are
deploying your app.
We also went in-depth into
the importance of bug reports.
We gave you a little
behind scenes of what goes
on with Apple engineers
when we're looking at them
and we gave you some
really good tips on how
to file some really great ones.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
We got some links here about
some of the places or some
of the things that we discuss.
So your dev forums, app review,
etc. And here's some
excellent links
to some technical tech notes
that Jed had mentioned, Ted.
And here's some for
the OS X as well.
I hope you've had
a wonderful WWDC.
I hope to see you
guys again soon.
[ Applause ]