Again, my name is Mark Malone. My email is down at the bottom of this presentation, so please capture it and send me email all about the incredibly exciting internal applications that you guys are building, workflow apps, all sorts of things. I'm always interested in internal implementations. The App Store has got plenty of things on it, but I think the in-house applications are the ones that are really exciting. So let me know how we're doing and how you're deploying applications. So I'm gonna take a bit of a romp through the SDK and it's basically my swag based on what I think in-house application developers are interested in doing. I used to do a lot of development within large organizations before I came to work at Apple, which is a large organization as well. So I figure I kinda know my way through here and you can always tell me that I'm wrong. Here's basically the list that I came up with. So a little bit on architecture, development platforms, there are two for iPhone. Displaying web content, in-house applications typically show web content. We love the browser. We love the deployment mechanism. We've got all these existing assets already that we display within web browsers on the desktop. Calling a web service, sort of stepping back from the presentation piece, talk a little bit about web services support on iPhone. Parsing XML, if I'm calling web services, then XML matters to me. If I've got a native application, how do I write data locally? What are the formats that I can use to go and write it in the classes? Security services associated with iPhone SDK based applications, so where can I store passwords and certificates, those kinds of things. Where do I store it, how do I write it? And then finally deploying iPhone applications, so sort of soup to nuts. Sound good? Yay, all right, good.

Let's go on. Let's begin with architecture. So I can't have a decent presentation without talking a little bit about the architecture of iPhone, especially since it carries over so much from the desktop environment of Mac OS X. So at the baseline, we've got a standard Unix kernel, something that's been tuned so that it works well on these mobile devices. And so what you get with Unix is you get stability, something that's highly tested.

You also get a lot of POSIX compliant capability that you can actually leverage within your application. On top of that, we create a stack called Core Frameworks. The Core Frameworks are our typical data types that we support in native applications. There are CF network code, those things at a low level that you're probably familiar with already if you've ever built anything for a machine or a device running Mac OS X. On top of that, we've provided a stack that's great at displaying media content, rich media, so animated graphics, OpenGL, core animation, those kinds of things that folks are used to seeing on our desktop, playing back video, stereo audio, recording audio as well, nice rich media stack at that level. On top of that, we've got the Cocoa Touch Frameworks. These are the classes that you're gonna use to provide user interface, interaction between your application logic and the user who's actually tapping around interacting with your application. So that's all within the Cocoa Touch layer. And then in comes your application and sits on top of it. So although I've presented it as a typical stacked architecture, the reality is an application can reach down to just about any place that it wants to within the frameworks, as long as they're publicly exposed APIs to get to those. So if you wanna open a BSD socket, go to town, you can do that. You can use the high level networking classes as well. But if you're more comfortable down at the Unix level, there's a lot of functionality that you get just through the SDK. So your application sits on top, and it sits in sort of a sandbox. A lot of folks are familiar with web-based sandboxes. And the Safari on iPhone lives in its own sandbox as well. So it can pull content from a particular domain. It can write cookies. But it doesn't have willy-nilly access to the file system. It can't go and read and upload files. It's a very user interaction based model. And a lot of folks are used to this when they're doing browser based applications.

Same sort of implementation on iPhone. If you're building an application that runs within the Safari browser, it sits in a sandbox. Now it can access the various applications or some of the various applications on iPhone. And the way that it does it is through web APIs. So I can go and I can launch a mail, a blank mail message, have it pre-filled with the to, the body, the subject, those kinds of things, just based on within my web content having a mail to URL within the web content. Same thing with the phone. If I want to go and present a phone number to the user for them to dial, I can have a tell URL within my web content. So you see, we've got this web API layer there that you as a web developer need to go through in order to access those things outside of your sandbox. And it's very much like the desktop model. There's a lot of integration you've got on the desktop through these same sort of APIs.

If I'm building a native application, same sort of sandbox. There's rules associated with building an application for iPhone. It sits in this world where there's a lot of control over what it can do. There's a lot of richness there. There's a lot of features in the SDK. I get access to a lot more than actually a web application gets through a native based application cuz there are more APIs there. So I can access the address book list, I can access the camera. The only way to do that is through a native application or photo library, or the accelerometer, or the location-based services. There's a slew of things that a native application has access to, but again, it's all through this API interface. The key message of both of these is no matter how you go and access the services on the device, whether it's through a web vehicle or a native application is to always use what are the provided SDK APIs. There's a certain amount of functionality that's exposed to developers to use within their native applications, and they're documented and they're sitting in a public directory, our public frameworks. You want to make sure any time that you're talking to a service on the device that you are using those public frameworks because anything that's considered private from an API perspective or not documented, we feel like we can move around, that we can change and end up breaking your application. If you're shipping an application through through the App Store, and it's got some secret way of talking to something that's not a public API, well, it might get through. But the key is you want an application that's gonna have some longevity. You wanna use the public APIs. Badger us for a public API for doing something that you feel you have to have only have access to through some secret mechanism.

So web-based application, native-based application, both sit in the sandbox, both need to use APIs in order to get it. And it's all about the public APIs on iPhone. So that's my rant about architecture and sandboxes. Let's move on to development platforms available to you. To begin with, freedom of choice is what you want. You do have freedom of choice. When we first shipped the iPhone, it was all about building a web-based application. Then we pushed out the SDK. Well, the web application capability is still there. And so a lot of folks are saying, okay, well, which way do I go? Which one do I choose? Am I gonna create this web-based application? Or is this native thing really, it seems like the hottest thing out there, is that way to go? Well, your choice might be based on a couple of different things. Might be based on the language, capabilities, all sorts of things. So from a language perspective, if you're an in-house organization that lives and breathes web-based technology, you live and sleep CSS, this is the stuff that you grok, then guess what? A web-based application, at least from a technology perspective, makes the most sense.

This is what your programmers know. So standards-based implementation within Safari gives you a great web-based experience. If you're a Java development house, or you live and breathe compiled languages, you love pointers, or love garbage collection, that kind of space, well, then you're naturally, just based on a language choice, going to gravitate to an SDK-based application. So that's just on a pure sort of language. What do our developers, our programmers within an organization know? Both sets have advanced tools.

So if I'm a web-based developer, we've got a great application for you that you might not know about unless you came to Vicky's talk or you managed to find it in the SDK directory. And it's Dashcode. Dashcode was originally created for folks who wanted to create dashboard widgets for our tiger and above dashboard environment. We've revved this tool for iPhone application creation as well. So now Dashcode can create dashboard widgets, but it can also create web-based applications for Safari on iPhone. So the same high level tools for laying out an interface, dragging on our buttons, reusing our code, having a built in debugger is now all there for building web based applications for iPhone and iPod touch. So if you haven't kicked the tires on Dash Code lately, I highly recommend it, even if you just wanna see what we've got in there. We've got high level templates for creating most of the common interfaces that you'll experience in native applications, but all just using web technology. And if you've got an existing web-based solution already and you wanna see, well, what's, sort of, how does Apple do this under the covers? Look at the code that we generate for some of these templates and steal it. It's got great stuff. We've got great art for buttons. We've got all the hardware accelerated animation capability exposed there, all the CSS effects. So kick the tires. It's well worth it if you haven't seen it in the past couple years. For doing iPhone development, well, we've got the Safari, Same Safari browser that you're used to seeing on iPhone or iPod Touch within the iPhone simulator as well. So if you wanna test internal websites, internal web products that you've already got, you don't necessarily need to try it with an iPhone. You can launch the simulator, launch Safari within the simulator, go to that property within the organization, sign in. How does it look? Does it run? It does, great.

Then you don't need necessarily to have one of those devices on hand in order to see if it's gonna work for users. So the simulator's great cuz it's got the same browser built right into it that you can play around with. So that's it on the website from a tools perspective. Over on the SDK side, we've got the same things that we provide users that are building desktop applications for the Macintosh. Basically the same tools that were used to build the SDK itself. And the first one is Xcode. Xcode is our sort of Visual Studio equivalent.

It's an IDE for managing all your project files. There's check in, check out integration with CVS per force, subversion, so that capability is there. Native debugging of native applications. So Xcode is the IDE of choice for doing those native based apps. For laying out your interface, you have that capability over in Dashcode for web apps. On the native side, you use Interface Builder. Interface Builder is a separate application outside of Dashcode and It's great for doing prototyping as well. So even if you're not a native application developer and you just wanna go and throw together some screen interface to present to your end customers, then go launch Interface Builder. Drag on some buttons, drag on a list, and you can run it within the simulator. Later you can go and use those Interface Builder files within your own native application just by hooking them up. So Interface Builder's a great application for laying out UI. And then finally, the iPhone simulator is there again for testing debugging your applications on the desktop.

You don't necessarily have to have an iPhone or an iPod touch present in order to step through your code. Now there are some caveats there. If you're accessing the key chain, or if you're doing any sort of OpenGL work, you do need to do the debugging on the device itself. However, the experience is great because all you need to do is plug in your iPhone or iPod Touch into your development environment, run it within Xcode, have it push the device, and you can step through your source as it's running on an external device. So either way, within the simulator or on the device itself, it's a great experience. So those are the tools. We've got something great on both sides. Maybe you'd make the choice web or native based on capabilities of the application that you're building.

So if you just love the deployment model of the web, then maybe a web-based application is the way that you want to stay. You make a tweak to what's running on the web server, boom, everybody's got the same version. Everybody's got the latest and greatest version. We've got some good parallel functionality on both sides. So mail maps integration, you can do it through the web, you can do it through native. iPhone look and feel, use our IDEs either on the web side or over on the native side to just reuse the code that we use, the same button art, those kinds of things. Multi-touch support, if you want multi-touch, the ability to pinch open and pinch close swipe, you can get that same capability obviously in a native application, but you can also get that in a web based application as well.

And that's something new with iPhone 2.0 and the version of Safari that's in it. 3D graphics animation, CSS animation is something new that Vicky talked about in her web based presentation, it's all about hardware accelerated animation on screen that looks just like it was the, it's equivalent in a native application.

HTML5 constructs, things like offline data access, so JavaScript APIs on the website to write to a SQL-based database, SQLite to be exact. The website now has offline application capability as well. So through HTML5 manifest, you can have all of your index.html, your.css, your.javascript, all of those files kept locally and control that and have an application experience based on a pure web technology. Now if you need access to things like the location based services API, if you need access to the camera, there's a bunch of other things where you're definitely gonna have to go down the native side. But if you're satisfied with a lot of the requirements at the top, then it's sort of pick and choose based on some of the other choices. Maybe skill sets and things like that you have within the organization. So based on platform features. So which one of these? There's always a decision that folks have to make. Some folks will choose web because they've got just an existing web application they just wanna port and be done with. Some wanna go full native cuz they're starting from the ground up.

Some people are somewhere in the middle. They're transitioning an application from something that's web to something that's native. And the big gotcha at the end of this is the reality is you can create an application that's a combination of both. It can be a web-based application, but it can also be a native application.

It can be a native application that does nothing but show web content. So all the user interface can be web, and then there can be a little shim of native capability that takes advantage of those things that only a native application can do. And those are called the native hybrid type applications. And you'll see there's a lot of applications that are using this capability within their application services. So native web hybrid.

So those are development platforms. Let's talk a little bit while we're on this web rant about displaying web content. So just at the baseline, if you've got an in-house application that looks great in Safari and iPhone, then odds are great that it's going to look-- sorry, looks great in Safari on the desktop. Odds are great that it's going to look great in Safari and iPhone. We've done our best to try to take you out of the loop when it comes to making the content look good on iPhone. So without a lot of tweaking on the back end, it should display fine. It should be interactive.

It should have all the capability that it had before. There are obviously some caveats, Gesundheit. So deploying an application via the browser, what do you get on iPhone? You get the same sort of compatibility that you would expect with Safari on Mac, Safari on Windows. Same sort of desktop capability, but in a portable platform. We think we've got the best implementation of the W3C standards. So if you care about a standards based implementation of DOM or CSS or ECMAScript, then we think we've got one of the best implementations. And we love to gather bugs about where we might be off base in this statement that we think we're the best. So we've got a great implementation there for standards.

But we also know that there's a web reality out there. There's a myriad of websites that perhaps you created within your organization or that folks get to, your users get to just through trolling the web that weren't built with standards in mind, right? They were code generated for IE only, or it was code generated for Netscape. Or it was generated at some sort of server. Or you know what, it was published just cuz it worked in IE and that's fine. So the browser is full of all sorts of optimization technology that we go through in order to make sure that we don't necessarily stumble over content that's not standards based.

So the caveat is, the biggest caveat is there's no plug-in support. So perhaps you've got Flash on your internal app, perhaps you've got Java applets. Maybe you've got content in some sort of MIME type that requires a plug-in, perhaps Windows Media or something like that. Then we're not going to support that. So we support standards code, we support HTML, we support pretty much the web reality from a pretty grand perspective. But when it comes to plug-in support, we don't have a plug-in model in the browser on iPhone like we do on the desktop. So that's sort of the number one thing that you need to do if you're migrating an app from the desktop browser to iPhone is make sure that there aren't any plug-ins in there.

So what do you get that's new and sexy? Well, CSS visual effects. I mentioned that that capability was there on iPhone as sort of a nice partner to core animation for a native-based application. And it's just pure CSS syntax for doing animation on screen. So transformations, moving objects around on a page with only using CSS, no JavaScript necessary. A lot of folks wrote iPhone applications based on web technology and used JavaScript in order to be moving divs around within a page. Very clunky. The CSS stuff is just incredibly fast, tuned for the device, and pretty darn groundbreaking as well. So transforms, we've got support for transitions. So again, pure web interface, but it's got the same sort of transition speed capability that you would expect from a native application. Animation as well. Here's a web template that's in Dashcode that does that same rotation that you would see in the stocks widget or in the weather widget. You get that same capability just by using CSS animation.

Or you can come up with something that's completely out of the box. You can mix and match these technologies to create an experience that's still pure web-based, but something that your users would never think this is a web-based application just by using a combination of these. So the CSS visual effects are incredible. I mentioned they're hardware-accelerated because you definitely want to use this if you've got any sort of animation that you're providing within your web-based interface, and that the JavaScript way of sliding in divs is definitely the clunky way to go.

Public specification for the CSS visual effects is available via webkit.org. Webkit.org is the open source repository of the engine underneath Safari on iPhone, as well as Safari on all the other platforms that you see Safari. So you can go and check out the specifications there. Our goal is to push CSS visual effects to be part of the CSS3 specification. We want to make sure that other user agent vendors besides us are pushing this technology. So we're definitely keen to make sure Firefox as well as IE implement these. And as a result, the specs are out there in the public.

So that's CSS visual effects. If I've got a browser that points to some SVG content, I can display it great on iPhone. This is something that's new in 2.0, so any sort of vector-based SVG content you've got within your organization. If you've got charts, graphs, those kinds of things, instead of rendering an image and delivering it to iPhone, throw it out there as text. That's just SVG. The nice thing about SVG is that it's vector-based.

It's infinitely scalable. So if a user pinches open on the chart on the left hand side on that pie chart, it stays crisp for each one of the zooms that a user would do on it. It's not like zooming an image where it starts to get pixelated as you go. SVG supports JavaScript handlers as well. So if I wanna tap on a slice within the pie chart and have something happen as a result of that, that kind of integration is there. So SVG 2.1 supports something new in Safari and iPhone. The ability to translate popular office document formats is something that's been available since the get go. And something that in-house developers will probably want to think about if they're building workflow based applications or something like that. We know that Word, Excel, PowerPoint, these are popular formats in a lot of bigger organizations. If you're writing a native application to perhaps workflow documents like this through some sort of process, then we're gonna display those document formats great for you. All you need to do is point the.doc at the browser or embed a browser within a native application. We'll do the translation and display on the screen. One of the nicer implementations is the Excel implementation where you get a tab across the top for each one of the sheets associated with a given Excel spreadsheet.

It's nice and interactive. The user can tap on each one of those tabs at the top and it will bring that sheet forward so the user can see the content that's associated with that particular sheet or tab. Now, you can't get in there and edit a Word file. You can't run the macros within an Excel spreadsheet. It's all about looking at this content from like an approval perspective.

It's all about display. So think of it as a great workflow tool for moving these things through a process, but it's not--the manipulation is left purely to tapping on the tabs associated with an Excel spreadsheet. You can page through it, move it all around, but again, you can't edit the content that's there. So Office document support, built right in. So this is your application running within Safari. This is the New York Times content, just navigating to that site within Safari. I mentioned this hybrid model. Well, so New York Times did the same thing. They went and created a native application because they loved the deployment model and are still presenting the same web-based content, the same story information within a web view within their native application. So this is Safari within your application, creating a native app, embedding a view that supports all of the web technologies that I talked about a little bit previous.

So embedded Safari, you get all of those things that I talked about. You can send SVG directly to the browser. You can send work, office documents directly the browser, PDF documents directly to the browser, or you can send them directly to a UI web view embedded within your native application and the experience is going to be the same. So you get all of that. You get the ability to load not just from the Internet now that it's been embedded within your application, but you can also load from within your own application bundle or you can load from the file system as well. And the file system here, I'm talking about your own documents directory, those areas where you can read and write from. And I'll talk a little bit about file sandboxing later in the presentation. So in the browser you can load only from the Internet. If you've embedded Safari you can load from other places as well. And there's the ability to bridge native as well as web based code. So I can write a web interface that based on user interaction within that web content I can trigger something within the native side to actually happen. Or I can do something over on the native side of my application that injects HTML or calls a JavaScript function within that embedded web view in my native app. So you can come up with these sort of bizarre mix and match worlds where some of the functionality is in JavaScript, some of it's over in native C. And it comes down to how do I wanna deploy this application? Where do I wanna put the various bits of business logic within my application? So I'm gonna talk a little bit about how do I access content as well as the integration between the two. So this particular example is loading from the web. You're gonna see this sort of presentation walk through a lot, basically building up a string that points to my resource up there in the cloud and in a string instance. NSURL is a class that we use all over the place. You're gonna use all over the place any time you go and access a web service. Well, here I need it in order to go and build up a path.

I take this URL that I just instantiated with the address to my external web content and tell my web view that little piece that's embedded within my native application to load this NSURL request that points to that remote URL. As a result, the embedded web control is going to go and fetch that index.html.

It's going to parse all the content on the page just like a browser would and pull in all the requested resources associated with that page. So if it points to include a JavaScript or a link element that pulls in CSS, all of that stuff is gonna be pulled in. And as a result, after all of those external resources is pulled, then the method webviewDidFinishLoad is gonna get called on the delegate for my UI webview. So as a result of that request, once everything's been requested, pulled down, is now being presented to the user. After all of that's done, this particular method is gonna get called. Means your web view is finished displaying all the content, and it's now available for interaction with the user. So this is loading content from the web.

Loading code from the application bundle just as easy. The key here is you need to find a path down to your application bundle. Your application bundle is basically that folder of data, your resources folder that you added to your native application. You need to build a path to that. And then based on that path, you can load it into the view as well. So here I'm grabbing the main bundle. I'm building a path to a directory. my web route that I just dragged into my resources directory. I called it local hostess. Within local hostess is an index.html file. That's the file I wanna go and load into my web view. So here's the full path that you get as a result of that call. You can see that you definitely don't wanna go and hard code any of these paths. There's a unique application signature there, but you can see it all resolves down to that index.html. Throw that into an NSURL.

create a request, tell the web view to go and load the request. Boom, all that content, just like the web route was sitting on the server, is now loaded from within my native application bundle. I can do the same thing from the file system. The path just points to a file system URL instead of an application bundle.

So let's talk a little bit about that interaction between the UI web view and native back and forth. So if I wanna execute JavaScript from native code, within my native application I wanna have something happen within the UI web view. There's some JavaScript functions that are sitting in there. All I need to do is create a string that contains that JavaScript function that I wanna call. So again, build up an NSString. Here I'm gonna tell my UI web view to display a common JavaScript alert to the user. So I'm saying window.alert, throwing some text in there to present to the user.

And then I call the UIWebView method passing that string. And there's a long function name here, string by evaluating JavaScript from string. Just pass in that string. And as a result, that alert's going to be presented within the context of the web content being displayed. Really straightforward. I can have any sort of get element by ID call. I could say window.location.href equals, tell it to navigate. Any of that JavaScript that you're used to calling within the context of the web page, you can build up a string of that and call it just by passing it through this particular native function to the view itself.

Key is to only inspect the DOM after the web view is loaded. So I mentioned that there's this web view did finish load delegate that's called after the UI web view is completely loaded. Once it's completely loaded, then the DOM is fully intact. You can make any sorts of calls that you want to the content that's sitting in there. Until this particular method is called, you don't wanna call any JavaScript cuz it's not fully there yet. And so you might not get the results that you were expecting. So only call it after it's been loaded. Now let's go the other way. Let's go and call into native based on the user doing something within the context of a UI web view. So the way that we do that is we take advantage of the fact that we've got a delegate within the UI web view that gets called every time UI web view has been asked to load content. So if I tell a UI web view to go and load content from the web, this particular delegate function is called.

And it should start load with request. So my web view is being asked to load some sort of URL that's mentioned in that request that's the argument. So what we want to do is we want to take advantage of that fact that this thing is being called every single time and trick it to call our own scheme, our own destination.

So instead of having content like a link or a button within my web context that points to HTTP colon my function up in the cloud, I would come up with my own scheme. And it would be like my app colon slash slash and then a whole chunk of data, right? So I know that my should start load request is gonna get called.

based on any sort of navigation. So here's a little snippet. I've got a button element that's sitting within a piece of web content and a JavaScript function and an unclick handler there. My delegate gets called any time that UI WebView is asked to go somewhere, to load a request. So I say window.location which tells the view to go and load some content. And instead of having it point to the public web, I use my own scheme. So I put my app, colon and then some raw data there. That's the data that I want to pass from the web context down into the native context.

So as a result of that particular function getting called, I can look at the scheme. And if it's a scheme that I own, it's something that I wanted to trigger from my web context, I can grab it and do something interesting. If it's an HTTP scheme or it's something that I know the browser just knows how to handle, then I can just let the browser handle it. I can just let it pass through and not grab it. So that's the mechanism for communicating between the two. We've got a class on the desktop, Mac OS X desktop, called WebKit. UI WebView is quite a bit different from WebKit, even though there's overlap from some of the API perspectives. You definitely don't want to leave here thinking that there's an equivalent API to WebKit on iPhone. The web views are significantly different. So a web view is significantly different from a UI web view. But this little mechanism, this little trickery allows you to talk from one to the other.

All right, so that's displaying web content, all the different document types we support, the standards-based content as well as some manipulation between the two different architectures. Let's talk a little bit about calling web services. There's two standards that I certainly know about. One is SOAP and the other one is REST. So I'm going to talk a little bit about each one of them. I'm going to talk less about one and you can probably guess which one I'm going to talk less about. Let's start with it. It's called SOAP. Folks that that aren't used to seeing any sort of SOAP APIs or even know what I'm talking about, I've got a little diagram. It's basically a client server call, right? You've got the client that's the iPhone. Most SOAP calls are a post. SOAP calls are a post because of the envelope associated with the SOAP method. So client, be it iPhone or whatever, creates an XML envelope, makes an HTTP post to a service. the server then responds with a SOAP envelope that's got the HTML or the XML content within it.

And this is what a typical SOAP request looks like. It's got HTTP headers associated with it. It's got this thing called the SOAP envelope that sits around the particular call. And then lo and behold, in the middle here is this little piece of functionality. This is the actual data that we're sending back and forth to the server. That's got basically the unique characteristics of this call. SOAP's a really nice technology because it allows an abstraction. It's sort of like Corba for the web from my perspective. It provides a nice abstraction between various interfaces. That's a SOAP request. This is what a SOAP response looks like. Again, typical HTTP headers that you would expect. Again, the SOAP envelope.

And then in the middle there is the result of that particular function call that I made. So a lot of folks think that SOAP is something that's a little overly verbose. There is a lot of content here, but you do get some nice retrospection capability and other things out of using SOAP. So what do we have on the iPhone?

Well, anybody that's used to building Macintosh applications will see that we've got a huge web services star set of frameworks and such on the desktop. none of that stuff is over on the iPhone. So from a SOAP perspective, you can either build and parse SOAP manually using the XML classes that we've got.

But there's also some interesting third party libraries out there that you might want to take a look at. The first one is GSOAP out of Florida State University and the second one is Access2 from the Apache foundation. So both of these are great libraries for making SOAP calls. Access2 is particularly useful if you love Wisdl. So if you love Wisdl then Access2 supports it, GSOAP does not but both of them work fine for making SOAP based calls on iPhone. Compile them into your application, both have generous legal agreements so that it's easy for you to distribute it without begging for permission out of these guys.

So this is the SOAP implementation that you can use if you've got SOAP within your environment. If you're using a RESTful technology, something on the back end that's more RESTful, well, you've got the same sort of client server model where you're making these web services calls. However, RESTful calls are typically GETs, a little less heavy. And the responses are XML. There isn't a soap envelope going in either direction. It's really up to the user to define what those interfaces are. So still client server. This is a typical RESTful request, right? It's a URL. It's got the destination, it's got the object, it's got the method name, and it's got any parameters just sitting right on it. That's why it's typically a GET request. So this is a RESTful request, RESTful responses. Sky's the limit, right? It's up to the server to define what kind of XML comes back, so it's all sorts of content, right? There isn't a defined DTD like there is in the SOAP world for these kinds of transactions. So this is an HTTP response.

So there's three core networking classes that you're going to use to make these kinds of calls on iPhones. On iPhone. You're going to use them all over the place. The first one, NSURL, I already mentioned. You're going to use that for loading content into a UI Web View. Any time you want to go and access any sort of web service, you're going to use the same high level class to go and reference a service that's sitting in the cloud. As I showed for the UI Web View example, it supports file-based, so something sitting locally, as well as cloud-based URLs. And it's really a nice class to use, even though it just basically holds a string, because you can go and dissect the parts of a URL. So if you want to ask a URL object for its port, or for its path, its query string, all sorts of things, you've got high-level access there.

Most of our classes, our networking classes, require an NSURL object as one of the parameters. Second one that you're going to use most often is NSURL request. That's encapsulating the payload of a request. Typically a GET, GET is what you'd use, a GET request is what you would get if you're using NSURL request. If you want to do a POST to a RESTful service, then you're going to use NSMutable URL request. When you're using the mutable URL request, you've got access to all the parts of the body. So you can put in your own headers, you can set the body if you're doing multi-part uploads if you're doing basic form completion. You can embed your own cookies within the posts, all sorts of things. This is the class that you would use.

One nice thing about it is it gives you great control over locally cached content. So you can create an URL request and you can provide arguments to it that indicate whether it's okay or not to use content that was previously fetched from the same destination. And there's a shared cookie store.

So any cookies that I may have retrieved through a session interaction over on the Safari browser side are available to me within a native application where I'm using these classes. So as long as the cookies came from the same domain, once I'm over in a native application, those cookies are gonna be posted with each one of the posts to that same domain when I'm using these native classes.

So it allows you to build something where you can share session information, all sorts of things, just by jumping between the two. Final class that you're gonna use is NSURL connection, and this does the management of the communication with the back end. All right, it's that final piece when it's time to go and send that request up to the server. So it supports synchronous as well as asynchronous loading of content. So you could block your user interface, you could block your thread while you're going and pulling down data if you wanna do that. You probably shouldn't. There's a slew of callbacks associated with redirects, which is nice, especially if you're building an application that you want to be secure. If you tell your application to point to somewhere in the cloud and the cloud says, no, you know what, the data's really over here. It'd be nice to know within your application that somebody's telling you to go somewhere other than where the data really does reside. So this particular class has a callback associated with it where we'll say to your application, hey, you know, the server says you should go over here for the content.

You've got the capability to look at that URL and say, no, I don't want to go to this particular site anymore. Something's been breached. There's a man in the middle or something going on here. There's also callbacks for authentication challenges. we'll handle all the sort of standard authentication challenges that occur. So if there's a certificate sitting on a server through which you're trying to talk to a particular web servers, and that certificate we have a route within our search store, we'll take care of that authentication challenge.

That's already handled. But if we hit a challenge, there's a server cert up there that we can't validate, or somebody on the server side is trying to authenticate through another mechanism, we've got a callback there. We'll call back to your application and say, OK, there's a challenge here. We don't know how to handle. How do you wanna go? And so people take advantage of those callbacks in order to go and implement their own authentication mechanisms within their native application. The final piece within NSURL connection is you've got even more granular control over caching capabilities.

So there's a final class that I talk about but is not available, you shouldn't use. It's called NSURL download. It's actually in the documentation. It works in the simulator, but once you move your code over to the iPhone itself for an iPod touch, it doesn't work. So it's fairly useful, except it does something that we don't want a lot of users doing, and that's writing to disk. This particular class, all you do is you point it to a URL in the cloud and you get a file as a result of it. We want to try to make it a little bit harder, a little more intentional for people writing to flash-based memory on these devices. So those are the three primary classes and the one not to use. A little graphic here for calling a particular web service in the cloud. The call is gonna be made based on my native application. Within my native application, I've created my own class called My Data Grabber. This is the guy that's gonna be in charge of talking to my web service up there in the cloud, so I instantiate my data grabber. First thing I'm gonna do to go and talk to my service in the cloud is create this NSURL object, right? Contains a string that points to my web service. Next thing I'm gonna do is create an NSURL request, passing in that URL as one of the arguments.

And then the third step is to create this NSURL connection object and pass it the request object in. And I'm gonna pass in a reference to my class, Cuz my class is gonna wanna hear about interesting things that are happening with this particular communication to the server. So once I go and I call this particular method, with this NSURL connection instantiation, a call is made up to the server, pointing to that particular URL that was provided. The get goes up, and then the data comes back down from the server. Something to keep in mind is that the data is not necessarily gonna come back in one fell swoop. It might be packed up by the server and sent in bulk. And each time we get a chunk of data from the user, this particular method is gonna get called on the delegate, the listener that cares about this communication. It's gonna call did receive data. Data's gonna be passed as an argument. It's gonna get called each time I get a buffer of data from the server. So you're gonna wanna go and concatenate that data structure up within your native application until the transaction is complete.

And the way that you know the transaction is complete is connectionDidFinishLoading is called. Now all of that data that I received can be thrown together and maybe it's an image I can present, maybe it's a chunk of XML, I can throw it to a parser and parse it. So you wanna wait till that particular method is called, then you're good to go with the data.

So those are the core classes. The examples that we've got that take advantage of these are reachability, very useful to determining if a particular URL is available. It's important to find out if a URL is available before you make the call. And the nice thing about reachability is you can detect whether it's going to be accessible via Wi-Fi connection or a cellular connection. So that's pretty useful. Ytap and Bonjour Web both take advantage of these three core classes. And URL cache is particularly interesting for looking at the caching mechanism associated with the various network calls.

So that's calling web services. Web services typically respond with some sort of XML content. We've got a couple open source libraries that we provide at the bottom layer on iPhone, they're also on the desktop. The first one is libxml2. So if you want C-based access to parsing XML content, then you've got it just through the libxml2 library. We've also got libxslt on iPhone and iPod Touch as well. So if you're doing any sort of XML transformations based on XML style sheets, then you can leverage this library to perform those transformations. The Safari browser as well as the UI web view will take any XML content that's being presented and transform it on its own without you having to use this library as long as it includes an XML style sheet within it. So you don't necessarily need to go and use this library if you're just taking XML content and presenting it as HTML, for example, within a UI web view or within the browser. So these are the two low level libraries that you have access to. They're open source, so the documentation is open source as well. So it's xmlsoft.org. There's examples up there as well as the documentation, so take a look at that.

We've got a high level XML support class built into iPhone as well. So at a higher level on top of that XML lib, we provide an NSXML parser. And what this is is a single pass parser, no DOM. So you don't have access to functions in order to query for particular nodes. It's all about sort of top down. Let me walk through all of your XML and then provide you callbacks each time I hit elements within the XML itself. Single pass. So it's delegate based and you basically get a call back within your class that responds to the NSXML parser delegate methods for each time an open element is found within the content. It calls didStartElement, passes a dictionary of the attributes for the particular open element. There's a call back each time we find content within an element between a begin an end tag and that's found characters. Found characters is buffer based as well, so you want to buffer up any string that's returned because that could be called multiple times. And it'll be called multiple times until the close element is reached for any item within your XML. And when a close element is reached, did end element is the method that's called in your parser delegate. Once the didElement function is called, all your concatenated string is ready for presentation or ready for use within your application.

SDK samples, Seismic XML, best example out there for using NSXML parser. It does it in a asynchronous mechanism. It asynchronously loads a table as well, so it's a pretty useful example for all sorts of things. Spawning threads, parsing XML, and presenting data in a table in a threaded manner.

While we're talking about high level support, one thing that you should think about is plist formatted XML. If you own the back end and you own the structure, the DTD of the XML content that you're pushing down to the clients, you might consider putting it in plist format. Plist DTD is something that we use all over the Macintosh as well as iPhone for holding configuration information.

It's basically our default text file format for configuration and information and preferences and those kinds of things. So if you own the back end and you can create your XML in this particular format using this particular DTD, then you get a big bang for it. So this is what a plist formatted XML looks like. You can see it's got a limited set of entities, so things like dict. There for dictionary objects, there's strings. You also see key value pairs. There's array types in here. So it's a fixed set of entities.

If you can live within this particular environment, what you get is very easily marshaled data types. Basically, we'll parse through plist formatted XML and do the conversion for you to data types that are native on iPhone itself. So anytime we hit a string element, we'll convert it to an NSString. An array will become an NSArray. A dict will become an NSDictionary along with all its keys and the values within it. bool and its number and its data and its date accordingly. So it's a really easy way to go and do the marshaling for a lot of different data types so you don't have to do all the string conversion on your own.

So easily loaded, NSDictionaryClass can take plist formatted XML directly. So if you've made a web service call, it's come down as plist formatted XML. You can instantiate an NSDictionaryClass directly with the contents of a file, with the contents of a URL, the contents of a data buffer. And you get a dictionary object out of it as a result. With a dictionary object, then you've got very much like a DOM implementation, where you can ask it for its keys, you can ask for the objects associated with keys. It's a really nice implementation and really easy to go and hook up to things like table views and picker selectors and those kinds of things within the iPhone user interface.

And they're very fast. I mean, we use these file formats all over the place. And so the code that we've written is highly optimized for parsing this kind of content. So I've got an example where I've loaded my entire iTunes dictionary into an NSDictionary. And it loads it incredibly fast. It navigates the keys incredibly fast. And it's a huge file. So it's something you should definitely take a look at. If you've never seen any of these files or you want a high level application to create your own plist formatted XML. There's a property list editor application that's on every Macintosh. Allows you to interactively go and create these files, choose data types associated with fields. And then you can generate an XML file as a result of using this app and take a look at the data that it's formatted. So give that a whirl if you haven't seen it before.

That's parsing XML, pretty straightforward. Moving on to saving data locally. I mentioned that web applications as well as native applications live in a sandbox. Well, you've got the ability to write files to that sandbox. You can read files from that sandbox as well, those ones that you've written. One thing that folks want to do is deploy multiple applications. Well, there's some restrictions there. Multiple applications can read and write to a sandbox. However, they can't read and write to each other's sandboxes. The goal is to provide a completely secure environment where native applications can't just troll across the file system and read willy-nilly. And so what that means is from an application perspective, you can't read outside of your particular area as well, even if you own both of the applications. And boy, it sure would be great to share the data between the two. If you do own application one and you do own application two and you wanna sorta share data between the two, there's other mechanisms, right? There's the cloud that's there, right? So if I've got content that I wanna share between two applications, I can stick it in the cloud. My model can exist in the cloud and both of these applications can access that same data. Cuz it's up there, it's centrally located, right? These are sort of always connected devices, or at least most of the time connected devices. So if I need to transfer information, I can do it through the cloud. Another mechanism that we've got is basically an open URL call, where one application says, hey, I've got a bunch of data and I wanna send it to another application. And so he just throws it up to the operating system. The operating system catches that data and says, I know who cares about this kind of stuff. And then launches the second application and tells it to go ahead and load the data. That's all through an open URL mechanism.

So the way that you configure your application to receive this catch, or to receive this TOS data is by modifying your info.plist, going and throwing a URL types, specifying a URL scheme within there. That scheme is the URL type that you care about within your application. Now, any time a web-based application or a native application calls a URL that begins with that scheme-- in this example, it's myapp2-- your application is going to get launched. And the rest of the query string is be passed to your particular application.

So I've got an example of what it looks like in just a second. The key here is that you wanna make sure that your scheme is unique. Right, there's a lot of different applications that might wanna go and implement this sort of data passing mechanism. You wanna make sure that yours is unique, and the best way to do that is to define your scheme as your application signature.

Application signatures are guaranteed to be unique for any application that's distributed. If you use the same URL scheme as your application signature, then you're gonna have something that's inherently unique. You also wanna make sure that you don't use any of the schemes that are supported by built-in applications. So don't say that your application can automatically handle HTTP, or automatically handle FTP, or SMS, or any of those other things that we do within the native applications, cuz it's gonna be our application that's called every time. So HTTP is gonna launch Safari. Mail-to scheme is gonna launch the mail application. SMS is gonna launch the SMS application. Those are the examples to stay away from. So come up with something of your own, come up with something that's unique, that's key.

So here's an example. I've got application one wants to send some data over to application two. So I create this URL string and have the scheme in it, as well as a bucket of data, this text data. I know that application two responds to that particular scheme, my app two. So I build up this URL.

Then I call openURL. This is a method on the application, the shared application object. And I pass in that URL, so I'm passing in that string myapp2, and then some data. And as a result of me calling that particular application method, my application is dropped. Application 2 is launched. And then the handleOpenURL method is called on application 2. And that URL is passed in. So the myapp2:text data is passed to application two through this particular mechanism. One thing that you wanna remember when you're implementing this in your own application is URLs can get launched by a whole slew of different things. Right, it can be any sort of native application can decide to call your application scheme just cuz it wants to, right? I could put a URL on a web page and surf to that web page within Safari on iPhone. And if it's got a link in it that's got your scheme on it, user taps on it, we're going to launch your application and pass it the data. So you want to be very cognizant of the fact that this scheme can get called by other people, other applications, random places on the web. So come up with a unique way of securing your own data communication between your applications or your services where you're going to go and take advantage of this. Don't just take whatever string that you get from the wild and throw it into a database. It's a great mechanism for doing buffer overflow, hacks of applications. So look at the data that comes in, come up with a convention for how that data's gonna be passed to keep it secure.

You might even encrypt the data that's sitting there on the string when you pass it and only your native application, the one that receives it, knows actually how to decrypt it. And then anything that it doesn't know, your application's gonna get launched, but you're gonna just kick it off and say, I don't wanna talk to any of this data. All right, so there's ways around it. So that's the mechanism for passing data back and forth. process the arguments within the URL again, just be very cautious about how you process those arguments. Cuz they could come in from a whole bunch of different ways. LaunchMe is probably the only sample that we've got in the SDK that shows you how to do this.

Basically it's something that a native application you build, you install, tells you to go over to Safari, you type launchme:/ and then some text. Once you load it in the browser, it goes and loads the native application and says, hey, it worked. So a nice thing about it, That was it shows you what you need to put within the info.p list in order to say I respond to these types of URLs.

So core file classes that you're gonna use in order to go read and write. First is NSFileManager. You'll use this class for all sorts of operations associated with managing files and directories, setting the various bits, permissions, those kinds of things on files and directories, determining whether files exist or not, as well as creating them. You'll use an NSFileHandle class all over the place to read and write. So anytime you've got a file sitting within the file system, NSFileHandle is the class you'll use to actually read and seek and flush and all sorts of things there. So these are the two primary classes. You definitely want to avoid hard-coded paths, especially if you're going to be talking to any of the folders that you have permissions to talk to. And the way you do it is through the NSSearchPathForDirectories in Domains JavaScript function. That's JavaScript function, C function.

This C function allows you to request from the OS a path to your documents directory if you pass in the NSDocument directory constant. You could also pass in other constants as well, saying, I want the temp directory or I want the caches directory. You can ask for those, but you have to ask through this particular C function. And we'll build up a path to that particular resource for you, to that particular folder. So use that before you go and write. So here I've got an example using those classes. And as file manager, it's a singleton, you ask for the default manager. Here I'm making that C function call asking for the full path to my application's documents directory. So I get a path that's a string. Here I'm appending my file name at the end of it. So I'm gonna write to a file called myfile.txt.

Then I use the file manager to go and create the file. And then I get a file handled to the class called saved file. And then I use the file handle to do all my writing, synchronization as well as closing the file, reading, those kinds of things. So straightforward process. The key is that you definitely want to use the C function for determining where your particular directories reside.

All right, so while we're writing files, we can also write out SQLite files as well. We've got a SQLite implementation on iPhone, much like on the desktop, and it's LibSQL version 3. So I can write files that conform to my own file format, or I could write out database files just using LibSQL. SQL 92 with caveats, so if you're used to writing typical SQL, then there's a good chance that you can shoot the same sort of SQL to SQLite, supports things like transactions and triggers and views. Views are read only, however, and supports common data types, including integers, reels, texts, and blobs. So there's a nice SQLite API for writing out these various types. You could write out objects that you've got in memory as well. You can use the blob field for holding all sorts of content, including anything that you've got sitting in memory.

things that are in memory, classes that you've instantiated on your own as long as they conform to the NS archiver, NSCoding implementations, then you can serialize those and throw them into the database as well. So LibSQL version three, files that you create using the APIs in a native application on iPhone, those same files can be opened anywhere that SQLite is used. Creates the same sort of SQLite compliant files. It's an open source library, LiveSQL, so the documentation is open source, sqlite.org. Lots of great examples there.

And we've got an SDK sample called SQLite Booklist that does reading, writing of records to a SQLite database. It's got a great implementation where it takes the stub of the database that it's gonna use for all its transactions out of its bundle, writes it to the local file system where it's got write capability, and then uses it for each additional write that you might wanna use. So it's a particularly good example. And the URL cache example uses it to store data as well. So those are some good samples if you're interested in saving data that's SQLite based.

As long as you're writing files out, it's good to see the results, the fruits of your labor. And you can do that within the organizer. You don't necessarily need to write something that reads all the stuff you just wrote out just to validate that it's actually successful at writing. You can open up the organizer window within Xcode. You'll see all of your in-house applications listed down here. And if you rotate the little triangle associated with your particular application, you'll see an application data element there. Click on the little down arrow and what you get is a prompt to save your entire documents directory somewhere within the operating system. You'll be prompted to save this folder.

So you know, stick it on your desktop, stick it wherever you want. And then what you get within the organizer view is the hierarchy of those documents that you just wrote out. So this is my image cloud sample that goes and hits a bunch of images up in the cloud, writes them out to the local file system. You'll see on the left hand side I've just selected one of the images, Xcode will present what it can if it knows the file types. If there are text types, it'll show it in there as well. Of course that directory is still sitting somewhere with my file system as well because I saved it there so you could romp through it manually as well, open the directories and see what was written out.

If you're doing simulator-based developments, simulator has a documents directory as well. It's an incredibly long URL, but there's a documents directory there as well, so you can see the results of all your writes within the simulator. You don't necessarily have to have a database application to take a look at that.

All right, so that's saving data locally. Just ripping through the last couple ones quickly. Got some security services available on iPhone. First one I talked about in the initial presentation, in-house certificates, as well as a lot of the most common routes. They're useful for authentication and signing. We have a keychain API on iPhone, much like on the desktop for Macintosh programmers.

Common crypto APIs, so if you wanna do any sort of unique random number grabbing, SHA, any sort of ad hoc encryption of content, files, those kinds of things, then you'd use the common crypto library. And then we've got the CF network framework. It's a lower level network, below NS network layer for TLS. If you're doing any sort of secure networking and you wanna get down to the nuts and bolts at that level, then CF network is the place to go.

And then spend a little bit of time on digital certificates and keychain, cuz these are probably two of the most used by in-house applications or soon to be. So at the get go, we've got support for routes like server and identity certificates. The most common are built-ins. We've got over 132 sitting within the keychain on iPhone. Basically the same set that you would see on the Macintosh desktop if you opened the keychain access application and clicked on certificates. Most common routes are already built in, so if you want to use them, they're good to go. They're stored in the key chain, so they're securely stored. You can import your own certificates if you're your own certificate authority and you want to use those certificates as part of authentication for back end resources. You can import them via Safari. Going to a secure web server, users can import an in-house cert. Or they can also be distributed to users for use via an attachment in email. And in the previous presentation, I also mentioned that the iPhone configuration utility is a great way to go and push via configuration profiles certificates out to your users as well. So we support in-house as well as the most common routes already within the key chain. And you can use them for doing all sorts of things.

So you can use them to authenticate with the built-in app. So Safari can use your in-house certificate to authenticate to a server sitting within your organization that has your own certificate on it. instead of using a public route. You can also, since you have access to the keychain, use certificates that you've deployed through whatever mechanism as a way of providing authentication within your own application as well. You've got access to that search store, so you can use the search as part of your chain of trust for communication to a back end, all sorts of things.

So certificate support, it's there. Keychain support, so we've got a pretty significant keychain API on the desktop if you're used to it. We've greatly simplified it. The keychain provides support for all sorts of storage of information that's considered secure. So things like cryptographic keys, certificate information. If you're going to collect any sort of passwords from a user and you want to store it for sessions, then throw it in the keychain. It's a secure way to go and store it. It's encrypted, you don't need to worry about it sitting out in the file system or anything like that. When you launch your application, you can go and pull it out of the keychain again. It hasn't been tampered with in any sort of way. So if you're gonna store passwords, throw it in the keychain.

There's a shared keychain store, basically one encrypted store that all the passwords for all applications are stored in. But based on application signatures, there's restricted access to basically little slices of the keychain. So application one has access to applications one's keychain or slice of the keychain. Application one can only read and write from a particular portion of the keychain. They can't necessarily read passwords, certificates, or any other information that was written there by another application. Unless, of course, that other application has the exact same signature. So there is a mechanism for deploying applications that have a little star as part of their application signature. If you deploy that way, then those applications that conform to that signature protocol can all share the same slice of the key chain. And the documentation for doing that is on the, I think it's in the distribution tab of the program portal on how to do that.

The secret is protected by hardware, not password. I mean, this is interesting to folks that are used to unlocking the keychain on a Macintosh based on logging in and a password associated with the keychain. There aren't any prompts in iPhone for access to the keychain. People that are used to the desktop experience, if Safari wants to access the password associated with a particular website, you see a dialog that's presented by Safari. Hey, we want to go get your password out of here so we can use it for auto form complaint. There isn't that kind of implementation on iPhone. the security associated with the keychain on iPhone is all about a hardware password. There's something unique about the hardware that's used to go and lock the keychain.

Backup occurs, but it's tied to device. So if you want to recover a keychain onto a phone, it'll only go back to the phone that that particular keychain came from. Since it's locked with something unique about that device, it would be useless anywhere else anyway, because it's encrypted with that device secret.

So keychain APIs, there's four of them, concise set of C functions, sec item matching, that's all about finding something within the keychain. I've stored a password there, I wanna go and retrieve it now. So I just ask the keychain using this particular API to give me back that password that I wanna use based on whatever criteria. Perhaps it's a name associated with that particular password or a domain associated with that password.

If I wanna add something to the keychain, it's sec item add. If I want to update something sitting within the keychain, it's just one big array of data types. I can update just one aspect of it. I would use this particular API call. And then finally if I want to remove something from the keychain, I would use sec item delete. The reason I've listed them here is because it's a much smaller set than what folks might be used to if they're using the keychain APIs on the Macintosh desktop.

SDK samples you might be interested in if you're doing anything with the keychain, generic keychain example. Throws stuff on, pulls it off based on lookups, deletes, those kinds of things. And then the crypto exercise example is particularly interesting, especially if you want to do any bulk encryption of content. If you want to take a file and encrypt it before you write it out to disk or if it's sitting on disk and you want it encrypted or decrypted or you want to set up a secure communication based on certificates between a client application and the server, that crypto exercise application is a great sample for getting your hands around how that's done. Thank you. So that's security services. Gonna wrap it up with deploying iPhone applications.

Should be pretty short. Two different application architectures, two different ways to go and deploy, at least within these particular architectures. First there's a web app deployment, everybody knows that, right? Everybody knows how to deploy a web application. Pretty straightforward, especially for a single one. All you need to do is find a place to go and host your particular web app, poke a hole in the firewall, pass out the URL to your customers, your end users who are using it. And once they've got it, they'll create a home screen icon so it stands right next to the rest of the native applications on their iPhone or iPod Touch. One thing that you should consider if you're deploying multiple web-based applications is coming up with an iPhone portal. So basically one destination where users would go and get all of their web-based services through one particular URL. It saves you having to open up multiple ports in the firewall or distributing multiple icons, having multiple icons on the home screen. And it's something that we've done within Apple for our deployment of web-based applications.

So in my sample here, I've got the little single icon. You tap on that to go to all the Apple web-based services. Since it's all coming through a portal, all of these apps use the same authentication mechanism. If I authenticate successfully to the system, then I get in. If I don't, then I'm blocked. Once I get in, then these are all just web-based icons that are sitting within my portal web-based application. Great user experience because basically all that session information is leveraged. Then the user goes and taps on the various one, whether it's the directory app or something else, launches it. And the presentation is great. So consider using a portal if you're gonna deploy more than just one iPhone-based app. It's a great shortcut. From a native application deployment perspective, there's three different mechanisms for deploying a native application. The first one is enterprise. Enterprise deployment are for folks who are members of the Enterprise Developer Program at Apple, so the iPhone Enterprise Developer Program. It allows you to deploy unlimited applications to unlimited devices. There's no tie between a device ID and the application that you're distributing. It's unlimited.

The only real caveat is that you can only deploy to members of your own enterprise. It's not a deployment mechanism that allows you to deploy outside of your enterprise. It's for in-house application distribution, only to folks who are part of your enterprise organization. So that's enterprise distribution. There's ad hoc application distribution. Ad hoc is all about tying the capability of a particular application to run on very specific known devices. So there's a set of iPod Touches or iPhones that I want my application to run on and none other than I'm doing an ad hoc deployment.

And then finally, you know what you love it, it's the App Store deployment, right? It's all about pushing it up and this is for commercial and free applications. So these are the three mechanisms of deployment. The ones that are most important to in-house developers are typically the enterprise and ad hoc distribution methods. Although there's a lot of enterprises that are commercial application developers as well. So typically they'll have an App Store account as well and they'll use that for deploying to customers that are folks outside of their organization.

So enterprise and ad hoc deployment, the process is build, authorize, deploy, and install. There is no over the air capability for deploying in-house applications for doing iPhone enterprise application development or ad hoc. Only the App Store mechanism is the way to get it over the air. In order to go and deploy an application that's ad hoc or enterprise, first thing I need to do is to create a signed distribution build of my native application.

Then I need to interact with the program portal at Apple, so sign in. Perhaps I'm doing an ad hoc distribution, so I need to select the device IDs of the devices that I want my application to run on. As a result of interacting with the portal, I'll get back a distribution provisioning profile.

If I want to do an enterprise deployment, I would still go through this same process, but I would not select devices and tie that particular distribution to those devices. I'd say no, choose the radio box that says I want to do an enterprise deployment. And then the need to select device IDs goes away. So as a result of interacting with the portal, you'll get distribution provisioning profile. It's signed by us to make sure that it's not monkeyed with. Once you've got that provisioning profile and your signed application in hand, it's time to go and deploy it. And you can deploy it in any mechanism that you want to do, as long as it gets it to the desktop of the user that needs to have it installed. So you can use email, you can push it through any sort of mechanism, you can use a thumb drive, whatever it takes to get it out there, but it's got to land on the desktop. You can't push it to the email of a client on the iPhone. It's got to land onto a desktop. The reason it's got to land on a desktop is because the only way to go and install in-house applications is via iTunes. Right, so the way you install applications with iTunes is you drag and drop them on top of the icon for iTunes, either on a Windows machine or on a Macintosh. If iTunes is already running, I can drag both of them into the library section of iTunes as well.

There's the iPhone Configuration Utility, which I talked about in the previous presentation. It's got the capability of adding provision profiles as well as apps. So if you're an IT organization and you want to prep a bunch of iPhones before you give them to developers, you can use that tool to do the same thing.

Once they're there, once the user clicks their phone in and synchronizes, the in-house application is pushed over to their device. They're good to go. App Store deployment, a lot simpler than that, right? All you need to do is still create a distribution signed build of your application. The next step is you push it up to the iTunes Connect portal, and then we take care of the distribution to the App Store, either on iTunes on the desktop or the App Store application on the mobile device.

So that's the application distribution mechanism. And that's it from a presentation perspective. I've got some links here at the end, links to the iPhone configuration utility, developer documentation. I mentioned some CSS effect, public specification is out there, webkit.org. Interesting Ruby library that I use for generating SVG graphics if you're into SVG and trying to figure out how you're going to go and generate some of those, that's pretty interesting. And my email is at the top, so if you've got any sort of headaches or things that you're running into as part of your deployment, building, any of the process associated with in-house application development, please keep in touch. Thank you.