Hi, everybody. Welcome to In-House App Development for iPhone. I'm assuming there's a lot of IT people here in the audience. We're definitely IT people ourselves. We definitely know what this is like, so let's start. My name is Steven Cotterill. And my colleague Jake Logan and I are going to talk to you about developing mobile productivity applications for your organization. And we're going to go over some tips and best practices that we've found in building and deploying those applications, so. As I said, we're IT folk, so Jake and I both work in IT at Apple.

Excuse me. We've actually been working on deploying mobile applications for Apple employees for several years now. We did a lot of research and we've been some of the first people to bring Enterprise applications to a mobile device for Apple. Of course, we started before the iPhone. We definitely tried out things like J2ME first, which was not terribly fun. I don't know if any of you have tried it.

It's not very fun for a couple of reasons. One is the technology. Technology isn't very well polished. It's all very new. I know mobile phones have been around, but mobile phones working or actually doing something where they're handling a call, that's a relatively new concept. And so those tools weren't very well refined.

Plus there was no consistent platform. You never knew what you were going to develop for. When we did a survey of what devices Apple employees had that we would need to target, we just came up with 50 different phones that happened to support Java. And we didn't have any standards on the size of the screen or the number of buttons or anything.

It was pretty miserable actually. So we definitely have thought about these concepts, and we know that you've thought about them too. There's the technical challenges that I mentioned, but there's also the design problems that come with bringing applications into the mobile world. You have to make sure that whatever you do integrates with the information technology systems that you already have.

And you have to make sure that you can actually deploy these applications to people. It's very hard to figure out how to get a J2ME app to different people without some kind of a store. And finally, you have to make sure that while you're doing this you're keeping your company secrets secure and safe, so.

The one thing that you can't change is the tech-- the one thing that you can change is the technology. You can wait for it to get better, and fortunately, it has gotten better in the last couple of years. The dev tools have become much better. Many platforms have stores now, and you can take advantage of those things.

But the one thing that you can't change is the problem. The problem is that you're trying to build an application to go into the mobile world and let your users be connected when they're not in the office. And what we realized was that you can't fix that problem.

There's nothing you can do to change it. We had to actually just stand up and accept the fact that this is not the place that we've been for the last 20 to 30 years. This is an entirely new world. And everything that we're comfortable with, everything we've been doing for the desktop in our Enterprises is miles and miles and miles away. Maybe millions of miles away. So once you accept that this is where you are now, you can move forward.

What makes this place uncomfortable and different and new from what you're used to is that for one, it's a completely new environment. Your application is going to go not onto a regular computer, like you've been used to. It's going to go onto these little handheld computers. And you don't know that you're going to have a very fast processor. Actually probably bet that you're not going to have a very fast processor.

And you can definitely guarantee that you're not going to have unlimited power. These devices run on batteries. Another change, and this is not necessarily a bad thing, but these devices are not multi-user systems. They're actually very much single-user systems, and arguably the most personal computer that you've ever targeted.

In addition to this, there are many more variables in the mobile world. Your battery connection could give out. Your network connection could give out. If you have a network connection, you have no idea how fast it's going to be. It could be Wi-Fi. It could be 3G. It could 2G.

It could be no G. And this is the really weird one, the mind melter here, is that in your hand time actually moves slower. When a user's out in a park and they pull out their phone or their mobile device, and they hold it in their hand and they're waiting for their email to load, and the world is passing by right behind them, every single solitary second is an eternity.

It takes forever to get your email, even though it's only 3 seconds. It's not that long. But it feels really long. So what was fast before, what was fast in your web browsers, what was fast on your desktop, these things aren't fast anymore. And you're going to have to work extra hard to make them still seem fast. And then this is the part that where it's really kind of an insult to injury. Your users actually are going to demand even more from you here.

Your users are going to-- it's their phone. It's with them wherever they are. They're not plugged into a wall, so they want your applications to be available wherever they are. And that means that they could be in the office. They could be at home. They could be in the car driving, perhaps at very high speeds. They could actually be in the bathroom using your application.

And when they can be anywhere and use their application, it can be used at any time. So your application doesn't have to just work during business hours anymore. Your application has to work 24 hours a day, 7 days a week, every single day of the year depending on which year it is.

In addition, users are going to want to know that they can trust your application. They want to be able to give your application data and trust that you're not going to lose it, and you're not going to drop it, and you're not going to mangle it, and you won't expose it. And they're not going to go to any extra effort to check to see that you've done this. If they gave you something to do, they expect you to do it.

And if you didn't do it, then they're going to be mad. And finally, users are never going to ask for security because they assume it's going to be secure. No user ever says, I have a requirement and that it must be completely secure and it must follow certain protocols as set forth by the NSA or anything like that. Users won't say that.

What will happen is when your data is not secure and it leaks and it goes out to the press, or your company secrets go out, then they're going to come after you and say, why wasn't it secure? So you definitely have to keep this in mind. I don't actually have to tell this audience that.

I know that you guys know about that. So with all these additional challenges, there's actually some good news. And it's that. Oh, sorry. Yes. Totally secure. Users, they're not going to want to put in a long password, and they're not going to want to use a VPN token. They just want it to be secure.

Excuse me.

The good news is that the technological problem has actually been addressed, and this new device called the iPhone has some great dev tools that comes with it. And it offers great deployment features. So you can actually learn to leverage the iPhone. It can be your one piece of certainty in a sea of uncertainty.

Wherever you don't know users are, you don't know when they're calling, you don't know anything about them, you can still bet that if they have an iPhone, you can get to that iPhone. That iPhone will be connected. That iPhone will have the same processor, the same screen. You know that. And users are increasingly choosing the iPhone as their personal phone.

And they're going to bring it to your Enterprise and they will want it to work. So, how can you build applications for the iPhone that users will like? Since you can't change so many things about the mobile world, you actually have to change some things on your side. And one of the things that you can do is don't give users more things to do.

Instead, make them better at the things they're already doing or they already want to do. And that means building applications that make them smarter, for example. If the user has answers in their pocket, then they know more. And they know more wherever they are. Applications like Lookup or Status, these things give users quick answers to simple questions.

And they don't have to have the answer if they can look it up. Of course, the iPhone is almost always connected to some network. And you can actually build applications that poke the user. Not physically. But nudge the user and let them know hey, there's something that happened. And you can keep them informed of events and news.

And since it's on a communications device they have their choice of modes of communication for getting back to you, calling back to the organization, and actually doing something about it, which in turn makes your users faster at what they do. And by giving users applications that work remotely so that they can control servers, let's say, or their desk back at work, from wherever in the world they happen to be, you're making them more influential than they've ever been before.

What I'm trying to say is when you go out to build a mobile application for your employees or your students or faculty or whoever exists in your organization, don't think of it as a miniversion of a desktop app that you already have. That's not going to work. Instead, consider your applications as safe and legal performance enhancers for your users.

Now, to get into some more detail on the design problem. I've identified 7 key properties that I think make for successful Enterprise applications. And I've distilled them into a series of F words for your enjoyment. The first is Fast, you know. Like I said, when a-- with a device in your hand, time feels slow. To make matters worse, the processor in your hand is not very quick either.

So you're going to have to work very hard to optimize your code to make sure you're not wasting any of the user's time. And to optimize your services that back your code so that they give answers over the network very quickly with very light payloads. Your application should be Familiar to users. If you've been to any of the UI sessions earlier today, you've already heard this a few times. It doesn't hurt to follow the same patterns that you see over and over again.

These patterns have emerged because they work very well. So things like the maps or table views, or alert sheets with buttons on them, don't be afraid to use these standard interface and interaction design patterns. It's OK. These things will make it very comfortable for a user. They won't have to spend any time learning to use your application because they'll feel that they already know how to use it.

Next is you have to make sure that you're Formatting whatever is in your-- the content in your application for what's probably the smallest screen you've ever targeted. And that means that you have to consider that for some people it's very hard to read small text. And you have to make sure that whatever you're going to-- the data that you're going to give them is actually legible. If you can't do that, then you would probably want to support zooming. But also, and this is I think more important, any inputs that you wanted to present your user with need to be large enough to be touched by fingers.

Keeping in mind that some people's fingers are kind of big. Next is Focus. As I said, users are not going to stop what they're doing to use your application, so your application needs to focus on solving a particular problem. So the user knows that they can go to your app and get a quick answer, for example.

There are many apps in the store. Some of the most successful and highest rated ones solve particular problems, and they do it very quickly. The apps that track flights, for example, or apps that track packages. Or apps that quickly convert from one unit to another, these launch very fast and they give the ans-- the user a quick answer to a simple question.

Your app should have the Foresight to know or to at least guess what users are going to want to do after you give them data. So if you give them data that's a phone number, the user may want to call that number. So linking to other applications and services is a good idea.

So integrating with things like contacts, for example, so that, you know, if you're talking about a person there's a link to get information about how to contact that person. Or if you're talking about a location there's a link to get information about how to get to that location. Your applications should be Forgiving, and by that what I mean is that the users are not perfect and they're going to make mistakes. They might touch the screen when they didn't mean to touch the screen. They might drop the phone and accidentally touch it on the way down.

They may not know what they're doing. So you should definitely protect the user from destructive actions. Now that iPhone 3.0 offers undo support, you should absolutely try and build that in where appropriate. But you can't rely on it. The best support for undo would be the undo that you never have to use because you've already protected the user from doing something dangerous.

And finally, finally, it's OK to be a little bit of Fun. It's OK to have a little bit of fun at work. If people like to work then they like to work. So where you can, if it makes sense, put a little fun into your applications. One of the best ways to do this, one of the most effective ways to do this, is to use things like the Accelerometer so that you can present different views. If the user tilts it from portrait to landscape mode, or you could respond to the user shaking their phone. Things like that.

I actually try, and I know a lot of organizations have already deployed iPhone applications into their org. They find great value in making their apps a little bit playful, a little bit fun. This is also important because if your user owns and administers their own phone, they will put games on that phone.

And your application, whether or not you like it, is going to stand right next to games on that phone. And even though it's not fair, users are going to judge the quality of your application against those games. So you're going to have to try a little harder to woo them back to work. The one caveat on this: Don't go overboard. Don't pick a bad color scheme.

Don't reinvent the blink tag. Please, don't do these things. Usability is far more important than crazy, crazy fun. So once you've figured out what you're going to build, then you have to figure out how you're going to build it. And on the iPhone you have 2 choices. You can build your applications to run within Safari as mobile web applications.

Or you can target the iPhone SDK. Of course, in iPhone 1.0 we launched with web application support. And you could immediately integrate with things like the phone, the mail, the maps applications. Later we let you put an app icon on the home screen so that users had immediate access to your web app. And of course, web apps by nature are instant deployment. This is probably the biggest argument for a web app, is that you don't have version problems.

Everybody's always using the latest and greatest version. In 2.0, Safari grew quite a bit and it now supported multi-touch gesture support. And it provided 3D and hardwar=e accelerated graphics and animation so you could do some really amazing things with it. One of the most important aspects from a data and information management perspective was that you could now store data in a web app locally using a HTML 5 database spec. And the actual applications on the iPhone could be sort of saved to be run even when there's no Internet connection at all, which is actually pretty amazing. Of course also the big thing with 2.0 was the introduction of the SDK, which did all those things.

And in addition gave developers access to the neat sensors that are available in the iPhone so that they could take advantage of the camera or the Accelerometer. Things like that. Now in 3.0 Safari has completed its support for HTML 5, so it's got a lot of new things.

Including, this is sort of an exclusive, but location services. There's now a JavaScript API to figure out where you are and tell your web application about that. And based on where you happen to be at the time, you can tailor your web application to provide more relevant data to the user.

And of course, the big thing in 3.0, I know, is the arrival of the Push Notification Service. So there's these two platforms, but there's a hidden platform in here. There's actually a third platform, which is hybrid applications. Hybrid applications are a combination of web and native, obviously. And the neat thing about hybrids is that they can do everything that either platform can do.

And we're going to talk a little bit more about this later. Real quick though, a hybrid application means that you're building a web application so it's like building for Safari. But instead of building it to run in Safari, you're building it to run in your own Safari-like browser. And then when you deploy that application, your own custom browser, to your user's phones, and then they can pull up your hybrid web applications within it.

It doesn't sound very compelling, but here's why it's compelling. If you build a hybrid web application for your own hybrid web application platform, you can actually support communication between the web application and the native platform. So if the web application wanted something that only the SDK could provide, it could tell the portal or the hybrid web application that using an HTTP request.

So it could say, I need a photo. And then the application would hear that. Being a native SDK application it could work with SDK services like the camera to get a photo. And then it could send it up to your web server. And your web server could return its location.

And then your hybrid platform could actually invoke a JavaScript call to tell your web application that it got it, and now here's where you can use it. Jake's definitely going to talk more about what you need to do to build this third platform, and how powerful it really can be. What's really cool about it is that once you've deployed this platform, the users can run multiple web apps.

And they never have to configure or install anything again. So with the 3 platforms, remember it's not actually 3 choices. You can actually look at it as a road map. An evolution for your mobile application. You could start today by building a web application on the same services that you already have in your organization.

And you can build it pretty quickly, using Dashcode for example. And tie with those web standards using web standard development talent. And then while your users are satisfied with that, you can keep them distracted while you, behind the scenes, rush off and either build a richer web application on a hybrid platform or a very high performance native application.

So, that said I'm going to hand it over to Jake now, and he's going to give you some more information about tips and best practices in developing and deploying applications in your Enterprise. As well as what you need to know in order to take advantage of this magical third platform.

So, Jake?

Thanks a lot, Steve. So thanks for coming everybody. My name's Jake Logan. I also work at Apple IS&T and I'm going to share a few best practices with you for architecture and development. How we do things inside Apple to build great iPhone applications for our users. So I just have 7 best practices to share with you today.

The first is that the iPhone is not a desktop, and we'll go a little bit in-depth on that. But it's just important to remember that it's a whole new paradigm. You want to think about this kind of development differently than you have on the desktop. I expect there are folks here from a Mac development background, and probably folks here from a Windows development background, and maybe some mobile application developers as well. So the main point here is, think about it a little bit differently. It's really not a desktop. Next is use the existing infrastructure that you have, and we'll go into depth on this as well.

But it's important to just remember that there's a lot of great services in your organization today and you want to leverage those. Engineer for Performance. This is a really key point. There's so many ways to really enhance your services so that they work well on the phone. And of course you want to test on the device. Don't wait until the last minute.

Test early, test often on the device. And architect for security. Of course, like Steve was saying it's really important that security play a big role in your development model. It's easy to forget, but it's really important that you secure your applications properly to protect your company data, trade secrets and so on. This sixth point is really kind of a fun look at the hybrid platform that Steve was talking about, and we'll go into depth on that as well.

And lastly, you want to customize your deployment plan. You want to think through up front how you're going to deploy your apps. And that's true for web apps, for native apps, and also for hybrid applications. How is your scheme going to work? How are you going to make these apps work together? So when we talk about iPhone not being a desktop, one of the key differentiating factors is the reality that it's got a totally different security model. The device is personal. It's in your pocket.

It's not shared like a desktop computer would be. And each app is sandboxed, so they can't necessarily talk to other apps, although there are ways to get around that problem, as we'll show you in a little bit. But each app runs one at a time so, you know, you need to think about that. You need to factor that into your plans. Network performance is quite a bit different, right? So on the desktop we have, you know, usually wired networks.

100 based-T, 10 based-T, fast connections and so on. On the device, well, 3G is a great networking protocol and it's quite quick. It's not nearly as fast as the desktop, so it's a key differentiating factor again. And lastly processing power. So it would be really great if we had multi-core Intel processors on the phone, but we don't.

So we need to take that into consideration as well. So Don't Try to Port Your Desktop Apps. And what this graphic here is really showing is that again, it's a whole new paradigm. You need to look at iPhone development for the device in a mobile environment. Don't try and port your desktop code over to the phone. It's not going to work very well.

So there are some differences between Cocoa Touch and Cocoa on the desktop, and you need to think about those. One of the differences is there's no dynamic link libraries on the phone. So when you want to build a library and share it between applications, you need to build a statically linked library instead of a dynamically linked library. And you can do that with a new Xcode target that's available in the latest SDK, which allows you to build a statically linked library. Once you've got that library you can share it between applications.

So we're going to talk a little bit more about that in a few minutes. And you want to wrap LDAP with web services. Well, it's not only LDAP. It's when there's something that you want to do on the phone that you don't already have a framework for. You want to maybe move that functionality over to the server.

Make a wrapper for it, and then call it with NSURLConnection. So our number two point here is Build on Existing Infrastructure. And I imagine there's folks here from educational institutions, government institutions, and of course corporations. Maybe small companies. Maybe medium-sized companies. You all have existing infrastructure. You want to take what you've got and build on top of that. Maybe make some wrappers specifically for mobile usage. So again, leverage existing services and business processes.

You want to employ a service-oriented architecture for scalability, right? And you want that to be stateless so that when you build a really great iPhone app and all of your users begin using it, you don't find yourself in a situation where you can't scale out horizontally and add servers to support the new load that the organization is generating. You want to think through, you know, what's your expectation for the load and build a lot more capacity than that expectation would require. And you want to create RESTful wrappers for your web services, for your SOAP services.

SOAP can be a little bit heavy for the phone. SOAP tends to have extra parameters, extra baggage so to speak which may be useful in a data center environment or even on a desktop. But really what you want to do is take those fairly heavyweight services and create very thin, RESTful wrappers for them.

So what are RESTful wrappers? Well, they're essentially HTTP post services that return an XML document. So when you do that there's an added advantage, and that is that you can then use a lot of industry standard tools to check out your performance, the payload sizes, and so on. We'll go into that a little bit in the performance section on how you can use some of the Safari web tools to do that sort of thing. So Engineering for Performance. Our number 3 best practice. This is critical. Minimize the service invocations.

So there are generally a number of calls that you need to make when you build an application. And on the desktop it's not such a big deal, you know. You might make one call to the server, get some data back. And you might make another call to get some different data. But the two pieces of data sit on the same page together. Why couldn't you get those in one shot? So on the phone, service invocations are very expensive due to the reasons I was mentioning before.

Processor. Power. Networking performance and so on. So you really want to bundle those up and do as few service invocations as you possibly can. You want to construct mobile optimized wrappers, as I was alluding to before. You want to create wrappers for your existing services that are really, really thin. You want to shrink down those payloads and really figure out ways to shrink the size of your containers as well. You don't want a whole lot of extra kilobytes going over the wire.

Or, in this case over the air. So you want to test with the faster wireless protocols turned off. You want to focus on the lowest common denominator. And if it works great on 2G, well it's. It'll work even better on 3G, and even better than that on Wi-Fi. So don't assume that all your users necessarily have 3G. And take advantage of caching mechanisms. This is a key point as well.

In Safari, in the new HTML 5 spec, there's support for web app caching, and that's great for pure web apps. You could also implement your own cashing mechanisms in a Cocoa application, a Cocoa Touch application. You do that with NS user defaults. You can store images that don't change very much or maybe ever in your NS user defaults cache. And you could also store any other non-changing data, you know. XML plist maybe, or maybe some other types of textual data.

So you want to think about caching, you know. How can you leverage caching to really give the perception of better performance? So you want to Shrink Response Times, and let's talk about how you do that. Well, the first thing is you write some code in your client and also in your server that captures the timings for performance, right? So you want to see how long a particular service takes to be called. And what you might find is that, you know, you call a service on the device and it takes a full 2 seconds for the round trip. But on the server maybe it only takes 200 milliseconds. So there's a big delta there.

And you know you're using Wi-Fi, say, so you know that the network's not really the problem. So then you can look to your client code to look for opportunities to shrink the response time. So you want to, again, evaluate your timing data and look for low-hanging fruit. Look for opportunities to improve the performance of your application. You want to tune your client server appropriately, right? Make the tweaks where they make sense, and then rinse and repeat. Do this a few times so that you can find ways to gradually remove hotspots.

To get those things out of the way that are slowing your system down. And you want to reduce the size and number of your resources. So you can use the Safari Web Inspector is a great tool to gauge the size of your app footprint. And this is where the RESTful service bit comes in.

Because if you build all of your services RESTful, then you can invoke them right on the URL line, the URL bar on Safari. So that you can even for services that won't be used for a web app, maybe they're going to be used for a Cocoa Touch app, you can still get an understanding as to how well they perform and what the payload size is.

And for web apps it's even better of course, because you can break it down into documents and style sheets and JavaScript and so on, so you can get a real strong picture of how your app footprint looks. So the next step is to combine your textual resources. You have probably in a web app a number of JavaScript files. You can combine those all into one. Or you might even consider sticking those in a script tag in the top of your page. Then you've bought yourself another HTTP connection.

Another connection that you don't need to open up. So you can do this with any textual resources, right? JavaScript, CSS, XML, JSON, some home-rolled protocol, you know. Whatever you use there's opportunities here to really increase performance. You also want to combine your image resources. So a key technique in doing this is called spriting. And what it's really about is taking your imagery and creating optimized images for each of your icons, images and so on.

And then bundling all those up into one large image, and using either CSS or Cocoa to shift that image at run time to only show one small part of it. Then of course you'll optimize that large image as well. So once you've done all of that you can really see a huge gain. You know, many orders of magnitude in a lot of cases. So it's a really effective technique to increase performance.

And again, to optimize the image file size. And lastly, you want to turn on service side compression. In Apache, there's a plug-in called mod_deflate that will turn on gzip compression and Safari automatically will gzip or, excuse me, un-gzip on the fly so that it'll be seamless on the client side. There's nothing to do on the client side. It's just a configuration in Apache. This can make a big difference too, especially if you have a lot of textual resources.

So test on the device. Can't stress this enough. Test early. Test often. What you really don't want is to find yourself at the end of your development cycle and you never really tested on the device. And you find that things aren't really performing as well as you thought they would, you know. It can be a little bit of an illusion with a simulator to-- you really tend to feel like your app is really fast on the simulator. And then when you go test on the device it's not nearly as fast.

Well, why is that? Well, excuse me. It's great for rapid debugging, but it's kind of like having an iPhone with an Ethernet cable and a multi-core processor plugged into it, you know. It's really misleading in the sense that everything feels so fast, so you really need to test on the device.

And you need to be aware of the simulator differences as well. Security framework is the first of those differences. And the thing about the security framework is on the iPhone, well, that's the Keychain, right? And it's a little bit different than the desktop in the sense that it's headless. There's no nice Keychain application.

Keychain access application that you can use to see what's in the Keychain. So, you know, when you run a Cocoa Touch application in the simulator that needs to use the Keychain, it's not going to work. So you need to figure out ways to overcome that. Some of the ways are to write some fake code that simulates what the Keychain would do in the simulator.

Another way is to call the Mac OS X desktop Keychain APIs to simulate the behavior of the Keychain on the phone. But it's something to think about when you want to keep your development train going and be able to rapidly debug on both the simulator and the device concurrently. So again, network performance. There's a big difference between the simulator and the device and processing power. One more time, big difference.

Just pointing these out again because they're so important.

So let's talk about security now. So, fundamental to your plan should be a secure architecture. You really need to think through how you're going to make that happen. What are you going to do to make your application secure? And also everything that you do over the network's secure. So the first point is always use SSL in everything that you do. Because what we're going to talk to you a little bit about in a minute is extending your applications outside the firewall and how to do that, without VPN actually.

Implement secondary encryption on passwords. Since passwords are the most sensitive data in your application, the most critical piece of information. For instance, if somebody steals your password they can steal all your company data too. You really want to consider possibly doing secondary encryption on your password before you pass it over the wire. And you want to use the Keychain to persist sensitive data. Everything that goes in the Keychain is encrypted, of course. So take advantage of it and don't go reinvent the wheel.

Use the Keychain for the purpose intended. So let's go through how to create a secure transport library. And I want to stress that as I walk through these concepts, these building blocks that we're going to use, that we're really working towards a special requirement. At Apple we had a requirement. We needed to make a single authentication system work for both web applications and native Cocoa Touch applications, and so we wanted to build a system that would work perfectly for both.

And really allow the user just one time in the morning to sign in and be into all of his applications all day long. So the first component of this is the transport library. And we implement that as a static library project in Xcode. And we wrap the NSURL connection and implement SSL. So we make sure that it's implemented in a single place so that whenever anybody uses our library they automatically get the benefits of SSL.

They don't-- we don't have to worry that, you know, one app team didn't implement SSL and now we've got a security hold, right? If everybody uses the same library and it's on by default, everybody gets the benefit. You want to leverage in-built NSDictionary parsing code since it's really nice to not have to have a lot of XML parsing code in the client. It can be brittle. It requires more maintenance.

There's a lot of reasons why it's nice to do this for maintainability mostly. But there are other benefits as well for sharing code, consistent behavior, and so on. So the second step here is to create a shared authentication library. And we're going to leverage the transport that we just built when we do that.

And of course, the main point here is we want to support multi-app single sign-on. And that means web apps and native apps. And we want to control access to apps in a centralized way. That's authorization, right? We want to have some system where probably it's LDAP groups or maybe some other access control system that you have. Maybe ACLs.

You want to leverage that and build authorization right into your library so that every app that uses it gets the benefit of it. Finally, you want to implement Keychain slice sharing. And this is the key point, the tip that will allow you to create a true multi-app single sign-on system. So let's look at how that works. So the first thing is to get Keychain access working, right? You want to be reading and writing to the Keychain at least from one app.

That's the first step. The second step is to write to a shared Keychain slice, so to create a system by which you can share a Keychain and hence a single sign-on token between applications, right? So how do we set this up? How do we do this Keychain slice sharing business? Well, it's not too tough.

The first is you go to the Program Portal and create a wild-card app ID. And so when you create your Enterprise account in the developer connection for iPhone development, you'll have access to the Program Portal. And you'll go into the distribution area and you'll create this wild-card app ID. The first portion there, those uppercase alphanumeric characters, are a unique seed ID that's generated for you for the portal. So there's nothing to do there.

That part is automatic. The second part, com.mycompany. * is your wild-card app ID, so you can define it however you want. It doesn't have to be only two components, com and mycompany. It could be 3 or 4. Whatever you really want. Or it could just be *. But, excuse me.

That's not right actually. Once you have that wild-card app ID, the next step is to add a Keychain access group name to the Entitlements.plist and it looks like this. And you can do this in the plist editor, Xcode, even in the regular text editor. And so the com.mycompany.MyGroup of course matches the com.mycompany that you created earlier.

And MyGroup is really an ad hoc stream. It can be whatever you want. It might be the name of a security principle or just some identifier that's unique for your organization. Lastly, you want to access the shared Keychain slice with the access group name. So it looks like this in Objective-C code.

And the key point is that when you access the Keychain you're going to read and write to it or maybe search it. You're going to pass a dictionary to it, and inside that dictionary you're going to include the Keychain access group. This is what tells the Keychain APIs to go ahead and write to that shared slice.

So the next step, and this is really just a standard principle. Probably a lot of people that are working in information technology are already employing mutual authentication, but I'll just go through it here for the folks that don't know. You want to prevent man-in-the-middle attacks and this is done with SSL, right? SSL by the nature of it supports mutual authentication. So there are two parts. The client has to authenticate the server, and the server has to authenticate the client.

So when you open up your SSL connection that handshake is mutual authentication. There's a second part that you want to do. Since you don't want to store your password on the device, right? You'd rather have a token, if you can, that expires, right? A password is probably a long-term password. It might need to be changed, you know, 3 months, 6 months, a year or something like that.

Whereas a token will expire much more frequently. Maybe in a few hours. So it's a lot safer to use a token rather than a password. So what we have here is an application, and then our authentication library that we just built. And we're going to go through the steps on how we implement token verification.

So the first step is to go ahead and pass the user name and password over SSL of course, after mutual authentication to the authentication server. The authentication will go off and authenticate with whatever your authentication system is. Maybe it's L. Maybe you have some homegrown APIs in your organization that do authentication. Second part is to return an SSO token to the authentication library.

And that token will be stored in the share Keychain slice that we just discussed. Third part is for the application to go ahead and use the authentication API to pass the token over to the application server. The app server there on the left. Once the app server gets that request, and of course the request is probably for some data to show in a view, the app server will go ahead and verify the token with the authentication server, right? So now you've closed the authentication loop. Next, the off server will respond with an OK message. Token is verified. Go ahead and pass your data back to the application and the user. And so that's the last step. To actually return the data to the user. So that's how token verification works.

So our next concept, and this is really optional but it's worked great for us. It's allowed us to really kind of blur the lines between web apps and native apps. Is to create a hybrid portal platform, and so this is what Steve was alluding to earlier. So a key benefit here is that you can implement authentication centrally for all web apps.

You don't need to actually do anything special for each web app. By default when they run in the portal they take advantage of the authentication system that you've built. Next, you want to create stubs or web app stubs to launch your web apps in the portal. Well, why do we need to do this? It's not required, but it's really a nice benefit to the user. Because what it allows us to do is provide one-touch access to web applications running within our portal app from the iPhone home screen. Otherwise, we'd need to build in some navigation within our portal application to find these apps and to launch them.

Well, wouldn't it be nice if we could just do it in the same way that all other applications are launched on the iPhone right from the home screen? Another key benefit is that you can access native APIs from JavaScript, and you can do that in a central way so you can offer this ability to all web applications running within your portal. And again, the purpose here is to really kind of blur the lines between native and web applications.

The nice thing about web apps, of course, is you get the instant deployment capability. So it's always a tough decision, you know, whether to build a native or a web app. But you really do derive a significant benefit from having that instant deployment, so it's something to consider.

So all this works on a secure cloud architecture. And the cloud is really a set of servers outside the firewall, and another set of servers inside the firewall. It's a proxy system that. Well, of course everything's over SSL, and it passes the traffic through, right, on behalf of your user. So again, you're securing external data access.

You're bringing data outside the firewall for your users over SSL using this proxy cloud. Again, no VPN token needed. Well, you know, we've got such a nice powerful device in our pockets. People rightly wonder why should we have to carry around this VPN token with us all the time, and type these digits every time we need to access something related to our work, you know? It's really kind of a hassle. So wouldn't it be nice to not need the VPN token? And that's exactly why we built this system.

So how does the client architecture work? Well, the first part is you build these web app stubs, and I'm going to just show you how to do that in a few minutes. But once you've got your web app stubs, you install them onto the home screen. And when a user touches one it goes ahead and this is sort of the last dying shout-out as the app dies as it launches the portal app.

Right? So the stub dies and the portal is launched, and it goes off and verifies the token. That's the connecting part, right? So it's doing authentication behind the scenes there. And finally it launches the web application. It lets you right in, assuming you've already logged in, you know, earlier in the day. If not, it would pop up an authentication screen.

You'd type your user name and password if it was the first time, you know, for the day. So we have a couple concept apps here that Steve's going to show us in a demo in a couple minutes. What this is really showing here is that each application has its own domain.

So, you know, this Directory app can't talk to the blue app Server 2 there. It's got its own server. The traffic is routed only to its app server it's checked, right? It's verified that it really should go to that app server using certificates. And again, it's our second concept app here.

It's living in its own domain. So to make this all happen you want to leverage URL schemes across your applications. And this is a standard supported feature. It's been there on the MAC OS for a long time, and it's been there, you know, on iPhone OS from the beginning as well. And so you want to launch your app from any app on the iPhone OS. That's the key point here. You can have links on a Safari web page. You can have a link on a mail message. Maybe an SMS.

Maybe in your own Cocoa Touch application. And it'll allow you to enable inner-wrap messaging. Well, you know, it's not really messaging, but what it allows you to do is pass data between applications. So just like I showed you on the previous slide, when one app dies it can pass parameters on the URL when it launches a second app. And then maybe that second app can go ahead and do something on behalf of the first app, and then launch the first app and pass some parameters back. So that's kind of what the concept here is. And you just want to use it with caution.

You really want to protect any abilities that you're exposing, since you don't know who might be calling them, with authentication. So you want to make sure that you're authenticating the user before you go ahead and execute that action on their behalf. And so this little URL that we have below, portal://, that's just an example.

You want to define your URL schemes in such a way that they won't collide with other people's URL schemes. So maybe a portal wasn't the best choice, but it's good for demos and describing the concept. So what that's doing there is it's invoking the portal, and it's calling it action launchwebapp and it's passing the parameter Dir for Directory to launch the Directory app within the portal.

So that's what that's doing there. So let's look at how we set that up. It's really pretty simple. First is to create a small Cocoa Touch project in Xcode. The next part is to launch the web app into applicationDidFinishLaunching. And there's a little bit of code there on how to do that. It's pretty straightforward, right? You create an NSURL, set up your URL with the proper call, and then go ahead and call openURL. That will cause this app, if this code is inside, to shut down and it'll launch the portal app. And there is no step 3.

It's really that simple to make a web app stub. So with that, Steve's going to come up and show us how this all works.

As you already got a look, we've created this sort of concept for the demo here. And we're going to pretend that we're a company with the initials A.I. It could be any company. It doesn't mean anything in particular.

What we've got here is our hybrid app portal, which has to be here in order for the web app stubs to work. But then we have these two stubs. One's labeled Directory and one's labeled Transit. And all they are, these small web stub projects that Jake just mentioned, they only do one thing.

They tell the portal what app to launch. So the very first time that a user will do this in a day, let's say, he'll click on Directory and it'll open the portal. And they're seeing the portal because they haven't signed in. So what you have to do. It's morning, so I haven't done this yet.

I'll just put in my name and my super secret password, and I sign in and then it will take me to that web application. So that was the interrupted case, right? An hour later I have to look up somebody again, all I have to do is click Directory. It will launch the portal and my app. And then this becomes really powerful when you deploy a suite of applications. I signed in for Directory. I've been using Directory today.

Now I need to get a bus home and I need to know when that bus is going to be here. If I click Transit it's checking the same token, but it takes me to a different application. So I guess I could show you this code. It's ridiculously simple. So this is the code to launch Directory.

It's one class. And in our implementation file all we did is exactly what Jake showed you. No tricks up our sleeves. It launches a single URL. And for this demo I'm. We've obscured this URL, but trust me it really is that simple. So back to you, Jake.

Thanks, Steve. So the seventh best practice is to think about how to customize your deployment plan.

And this really shouldn't be an after-thought. You should think about it as part of your development plan. Don't wait till the last minute to do it, or it could be a little bit challenging. So the first thing is to create a universal provisioning profile in the Program Portal. And this is really an Enterprise profile.

So to make one of these you have to have an Enterprise account. So once you've got the UPP, the Distribution Profile is another name for it, you can sign your apps in Xcode using the provisioning profile. This is what will allow you within your organization to distribute them to your devices.

So then you want to think about creating a website to host your applications so users can download them and drag and drop them into iTunes or IPCU, which we'll talk about in a moment. And also the UPP. So you need to get the UPP on the device once for all apps, and then you also of course want to sync your apps on the device as well.

So you can do this with iTunes or IPCU. iPhone Configuration Utility is what IPCU stands for. It's a free utility from Apple. So that's the first option. iTunes. I think we all are familiar how you sync apps from the app store onto the device. It works just like that. There's also a nice feature.

If you want to get a little bit more advanced, you can create a script or maybe a small Cocoa application to drop your applications from some remote location into the iTunes directory, so they'll automatically show up in iTunes. So that's the first option. It's the one we recommend.

But some organizations don't like to run iTunes for various reasons, so that's where the second option comes in. iPhone Configuration Utility is a little bit more surgical approach, right? It won't sync your contacts or your music or your photos or anything like that. It'll just surgically install the application over the cable. So it's also a lot more lightweight.

It's a quick download. It's free. It works on Windows. So it's a pretty effective way to get applications on the device as well. So lastly, I just want to share with you some of our development ideas. This is kind of fun stuff. Some of these things we've already done. Some of them we're looking at now. The first is Directory Services, and that's the app that Steve just showed. Look up people, groups, places, applications. Great. Well, with the new location services it's a really great opportunity to leverage that for Directory Services.

What if you walked into the lobby of a building and touched a button and got a list of conference rooms in that building? Well, maybe you know you need to go to a particular conference room, so you touch on that and you get a map of how to find the conference room. So things like that. Leveraged location services within your directory services infrastructure is a really good idea. Collaborative. So approvals. Meeting requests. Expense report approvals. Business process approvals. Change requests to deploy things into production.

Service tickets. Group calendaring of course, right? So the thing about iPhone nowadays is it's getting so advanced that it's hard to make a justification for building your own calendar client or your own software on the device. But you might want to for certain key features that are only available in your organization. But really this is more about implementing the server side and leveraging the great client applications that are on the device. iCal or. Not iCal, but Calendar in contacts application and so on. Remote access to voicemail.

So this is a pretty cool idea. What you can do is use Audix APIs that you probably have available in your organization to capture landline desktop voicemails, and allow people to listen to their desktop voicemails right on the iPhone. Pretty cool idea we think. So an organizational news channel. Transit tracker is the concept that Steve just showed you. There's also another one that we do is menu service, you know.

Wouldn't it be nice to know what's for lunch? And lastly, VPN on demand is new on iPhone OS 3.0, and we're very seriously looking at that as well. It's really outstanding because it doesn't require you to type anything, right? You just access a website that's within the firewall and boom, it connects automatically and lets you right in. So with that I'd like to bring up Steve again to finish us off.

OK. Thanks, Jake. So you've heard an awful lot about things you can do, and we've even given you some tips on some of the things you might not have thought of. Hopefully it's new information. Hopefully we didn't bore you. And now you actually also have some ideas on where you could go next. You might have already come here with an idea for an internal application, but you might have thought of something really great just now.

So we just want you to remember a few things. First of all, as we've said several times, the iPhone's not a desktop and it doesn't take a genius to figure that out. But it does take a genius to remember the details. It's not as fast. It won't last all day. Things like that. Second is test on the device. Jake hammered this point home very strongly. I totally agree with him.

You can use a simulator to work out the big bugs, but you really need to get onto the device at some point. And earlier is better before you can say that your app is ready to ship. Third is engineer for performance. And fourth is architect for security. Both of these things are not things you can go back and put in later. They're the foundation for your house.

If they're not solid you're screwed, so you have to think about these things up front. So if you want any more information, if you have any questions, Mark Malone is the Internet and Server Technologies Evangelist at Apple and he will be able to help you out. You can email him at his email address. And you can always go to the Apple website, or the developer's website, to get any more information about developer tools, technologies, documentation and things like that.