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 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 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, 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, 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 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. 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.

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. 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 and for that I'm going to hand off to Tanya.

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, 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, 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. 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 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. 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. 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 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. 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 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. 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 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.

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 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 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.

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 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? 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 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, 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 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 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. 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. 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. 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. 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 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 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 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 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.

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.

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.

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.

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 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. 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.

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.

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, 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 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 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, 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.

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.