Good morning, hello. Welcome to session 705, Distributing Enterprise Apps. My name is Dave Rahardja, I'm an iOS software engineer. So tell me if this sounds familiar to you, you're in charge of a team that's developing an iOS app for your business or for your school, okay. You're in charge of everything including managing developers, contractors, distributing apps over MDM, making sure they run on a whole bunch of different regions and make sure that it keeps running for years and years to come. So if this sounds familiar to you this session is for you.

I want to give you a kind of a comprehensive overview of everything that you need to know to successfully develop and distribute and deploy an iOS app in an enterprise setting. So we're going to do that by focusing on four major areas that will sound familiar to you if you've ever done this. First managing your team, next using Xcode server to provide help for development, then some app distribution strategies that will keep you in the clear for years and finally custom B2B and how that fits within your organizations deployment plan.

All right so four major topics, let's start with the first one, managing your team. So let's start at the very beginning, how do you get started developing enterprise apps at all? Well, it's really simple, you need an enterprise developer account, it use to be that we had a 500 member...500 employee limit for enterprise app accounts, that's gone, no minimum company size as long as you have a D-U-N-S number for your enterprise you are eligible. This program is 299 a year.

To get started you need to create an agent account and then add admins and team members to the developer portal. So let's talk about these roles, an agent is a person who is authorized to accept legal terms with respect to the developer program. Admins manage team members and they prepare apps for distribution, there can only be one agent but multiple admins, team members are those people who actually develop and test code under the program.

Because agents and admins are able to produce things that represent your company so agents sign contracts, admins publish apps with your code signing certificate. They should be employees of your enterprise, team members however can be employees or contractors and we'll talk about the kind of a work flow here for contractors in a minute but first let's talk about admins.

So admins can add and remove team members from your roster, they can create app ID's in the developer portal, they can request push certificates for those app ID's, they can add devices to the team development provisioning profile which everybody else in the team including the team members use to actually do debugging on iOS hardware, they get to manage the distribution code signing certificate which is a special certificate, a code signing certificate that you need in order to publish the app.

They also create the distribution provisioning profiles. This is in contrast to the development provisional profile which is automatically managed by Xcode. And finally they are the ones who package the actual apps for final distribution. So as you can tell admins have a lot of power in this program, most of the administrative tasks with respect to developing and distributing apps fall under admin accounts.

Team members are coders and testers they should have their own personal code signing certificate, each one should have their own code signing certificate, don't share your private keys between developers. During the development cycle if a developer loses their private key you could just create another one as long as nobody is using an older version of an app that they produced it's fine, just create a new one, don't share the code signing certificates. Use the team development provisioning profile to debug on iOS hardware and this is done automatically by Xcode if you set up Xcode correctly you never have to worry about this.

Team members can distribute apps to a limited extent, they can create ad-hoc distributions which are app bundles...app packages that can be run only on test devices. This is great for QA for example or alpha testing but they cannot be run outside of their own little group of devices.

Now contractors, many of us have contractors that come in and out of our development circle, so the way that you should treat contractors is they should be enrolled as team members in your program, you should invite them using their e-mail address and then they should get their own code signing certificate, just like any other team member. At the end of their contract simply remove them from the member portal and that's it, you'll invalidate the code signing certificate, they can get another one for another project next time.

All right so let's walk through a little flow of inviting a team member including contractors to join your development team, so here we have the developer website here member center and we have a list of people in your development team including some admins and some members, what you do is click on the invitations icon in the site bar and you'll see this. You can invite one or a bunch of people into your development team at once, click invite person, enter the name and e-mail address, this is just an e-mail address it doesn't have to be their Apple ID because any e-mail address that they can be reached at.

And they will get something like this so you've been invited to join the Apple developer program, so the reason they don't have to receive this e-mail over Apple ID is because when they click on that blue underlined link there they will be taken to this portal where they can then sign in with their actual developer ID.

If they're already a developer like the 99 dollar app developer they can click the top button and log in with that, if they're not part of any development program they can click on the register button on the bottom and they will get access to the developer tools and the rights as a developer by virtue of joining your team, okay.

Once you do that the next thing you should do as a team member is to go to Xcode and type your registered Apple ID in, so you click register, you register as a new developer for example, go to Xcode, hit your preferences, go to accounts and add this.

This is the key to having a really nice flow of artifacts between your team members, you admins using Xcode. When you log in Xcode will show you what development teams you belong to down there on the bottom right, in this case Ann is a member of the business markets enterprise program team.

When you click on view details you will see this so you start out with no code signing identities of course and no provisioning profiles, the first thing that the new team member should do is to click the plus button and request a new iOS development code signing certificate.

When they do that all of the admins of the team will see this, they will see that Ann has a requested a code signing certificate, all you got to do is hit approve and Xcode will get the signing certificate installed on your team member team member's computer. The same goes for provisioning profiles, when they refresh their provisioning profiles after they've done this they will get the latest iOS team provisioning profile, so most of this, once you've set this up much of the details is taken care of for the developer by Xcode.

All right so let's switch gears a little bit so once you set that up you can actually start developing. But what I want to recommend for your admins to do is to create app ID's right at the beginning of your app development cycle. So if you want to develop you know some an app and you have some app in mind go ahead and go to the developer portal here and click on certificates, identifiers and profiles. Click on app ID's and plus and create your new app ID. Create this at the beginning of your development cycle and I'll tell you why in a second.

Use the team ID prefix for your app, there may be some legacy entries if you were a developer before, don't use those use the team prefix that will get you the happiest path and use an explicit app ID, you should no longer use wild card app ID's because this will get you a lot more features if you use an explicit app ID.

So the reason that I asked admins to create app ID's at the beginning of the development cycle is because many of the apps developed today require entitlements in their provisioning profile, so you have iCloud entitlements, for extensions you would need special entitlements sometimes and if your app needs push notifications you would need to have an app ID registered first before you can get a push certificate, etcetera, etcetera. So because many of the apps that we develop today use a lot of modern additions that need provisioning it's usually easier to just enter the app ID first and then just keep checking boxes as you need on the developer portal, that's why.

So in summary enroll in iOS developer enterprise program to begin development, you're agents and your admins should be employees. Your contractors can be treated as team members, you should invite your team members as you create your program and you should approve their code signing certificate requests. Remember each team member should have their own code signing certificate and best practice create your app ID's at the beginning of the development cycle that gives you the most leverage as you continue to use features that require entitlements.

So that's managing your team, I hope that's helpful, next I'd like to talk about Xcode server, Xcode server is a great hub for development. To install Xcode server all you have to do is install the OS X server from the Mac App Store and then install Xcode on the same machine.

When this happens a new entry will show up in your server dot app side bar to enable Xcode service. So here's how you set it up for enterprise development, the first thing you want to do if you want to log in with your enterprise account on Xcode server, so edit that, log in, you can log in with any admin account on Xcode server.

When you do this, the Xcode server will get its own code signing certificate, all right so if you look at the key chain there it is that's a servers, it doesn't belong to any developer it's a servers own code signing certificate and this means that the server can produce app packages for you and we'll see how that can be useful in a few minutes. Once you're logged in you should create a user for each of you admin and team members on OS X server.

You don't have to give them home directories, you can select services only so this basically creates directory entries for your team members. This greatly facilitates the rest of the past because you can create groups out of these entries and then create access controls based on that group. All right so that's really it for OS X for Xcode server on OS X until later we'll talk about bots.

Let's talk about code repositories, so you can create code repositories on Xcode server also, we support git or subversion, I can recommend git these days, you should create one repository per app and because that makes it easier to integrate your code repository trigger with bots later on and create access controls on the server, it really is very simple, all you have to do is hit the plus button, create a repository, it's that simple.

Now on your developers machine you can actually add a server as its own entry under your preferences, under your accounts so here's a server, if the server is visible on Bonjour it will show up here, add that server to your Xcode environment and you will get this, check out an existing project on your Xcode welcome screen. When you click that Xcode will automatically reach the server and figure out what repositories you have access to and this is where all the accounts come into play click that and you're good to go.

So bots, so a great feature of Xcode server is bots, so what are bots? Give you continuous integration they will run units tests on devices connected to the Xcode server, it will generate reports and create archives for QA. So I'm going to walk you through how you create a bot using Xcode.

So anyone can create a bot, it doesn't have to be an admin. as long as you have rights on Xcode server, the first thing you want to do when you want to create a bot is open the project that you are interested in and create a share scheme, go here, click manage schemes.

Most of the time you already have a scheme that you want to use as a template for the bots scheme so go ahead and duplicate that scheme right there and call it integration for instance and make sure that the shared check box is checked, it has to be shared and remember to commit the scheme to your server with the source control and check it in otherwise of course the server can't see the scheme that you've just made. Next on the server connect your test devices so if you plug an iOS device into an OS server it will show up here, it will show up at the bottom.

If you click on add the team Xcode server will take your device and automatically add that to your provisioning profiles. The rapid device you did go to the developer portal and create a new development provision and profile which can then be downloaded by your team members so why do you want to connect test devices to the server? This device is actually used for the unit test, they'll actually run the unit test on the device. So connect a variety of test devices if you can, an iPad, iPod touch, iPhone to get the best coverage for your tests and like I said the development provisioning profile is automatically updated actually connect new devices and add them the portal.

Once you've done that back to Xcode, create your bot, under product remember this is you still have the project open that you're interested in creating the bot for, under product go to create bots, under the create bots dialogue, choose the scheme that you've just made, the dash it all integration scheme and call the bot give a name to the bot, so we have here dash it all commitment integration so for this example we want the bot to run when a new commit is made to the repository and that's it. You can choose when you want to perform the operation, you can choose what actions you want to do, analyze, test, archive and which devices you want to run this bot on.

Bot creation succeeded and the bot is ready to use, it's that simple. So what do you get? When the bot runs it keeps a data base of its run status and results so you can see the history off the builds, which builds failed and passed, you can see how many of your units have passed and failed, you can even see this on a web browser by going to the servername/Xcode/bots.

Your bot will produce these results, it will produce test results, unit test pass and fails, static analysis results. It will produce logs from your build and test sessions, it will produce extra project archives so you know exactly what code got compiled for that run. And here's where the servers code signing comes into play. The bots will actually use Xcode servers code signing certificate to create ad-hoc signed app packages which QA can then download straight from the web server or Xcode and install on their own devices to do regression testing, it's great for QA.

That's Xcode server, it's a hub for development, install OS X server and Xcode on the same machine, sign in with your enterprise account, any admin account will do, host your code repository there, connect your test devices and use bots for continuous integration. It's a great hub for your development needs, that's Xcode server, all right. App distribution strategy, distribution provisioning profiles, when you're ready to publish your app and distribute them to your enterprise members you need to create a distribution provisioning profile.

The way you do that is go to the developer portal, certificate identifiers and profiles again and click on the distribution item on the side bar. Then next step click in house so this is available for enterprise accounts, in house distribution will allow you to run your app that you signed on any devices without limit of UDID. Select your app ID that you've provisioned before right there and that's it.

You can download the provisioning profile and then go to Xcode and open the project and see archive, product archive right there. When you click archive the project will be archived and will be ready to distribute, it is not ready to distribute yet, you need to do one more step, you need to click distribute and save for enterprise or ad-hoc deployment right there. Then choose the provisioning profile the provisioning profile that you've just created, not the team provisioning profile but this one the in house provisioning profile, distribution provisioning profile.

And then save the file. If you're using MDM to distribute your apps and you should you get the opportunity to create the manifest file that can then be provided to your MDM server over here. Consult your MDM server and you can enter the URL and app icons that will be used to download the enterprise app that's how you package your apps for distribution. All right so next topic is something that's near and dear to all our hearts, code signing and provisioning rules, all right. Code signing certificates are valid for three years.

Thank you. You can have up to two valid certificates at a time all right so they can overlap but at any particular time you can only have two valid ones. You have to update your app binary to update your code signing certificate because you know it's part of the code bundle.

Provisioning profiles, provisioning profiles are valid for one year but you can renew it at any time. There is no need to update your app binary, in fact it is the best practice to update your provisioning profile silently over MDM so that the apps will continue running. Enterprise apps need both of these to run, they need to have a valid code signing certificate and a valid provisioning profile at the same time to run on a user's device so to illustrate the kind of strategy that you might have to build around these rules, I've got a little chart here for you, so the vertical bars in this chart are years, so this is year 0, year 1, year 2, year 3, etcetera and the arrow up there is where you are in time, I'm going to describe to you the kinds of things that you might have to consider as your app is deployed over the years.

So let's start by assuming you're going to publish an app and year 0, you've never done it before, here we go, app A 1.0 at year 0 we're going to distribute it. Well the first thing you got to do is you got to get yourself a code signing certificate, so you do that and you sign your app with it, great.

Well, that's not enough right, you need a provisioning profile, you need a distribution provisioning profile, that's so these three steps are what we have just seen a few slides ago when you go through and go to your archives and distribute for enterprise, this is it. You go to cosigning certificate, you use it to sign an app and then you have a provisioning profile. So the provisioning profiles are embedded in the app so when the user downloads the app they automatically get whatever provisioning profile you chose when you distributed that app.

So everything is great, apps running, fantastic, six months go by you go hey there's only six months left in my provisioning profile, I'd better refresh this before some of my users run out of provisioning profile validity, so you create a new provisioning profile, remember provisioning profiles can be renewed at any time so you just do it and push it out using MDM and the users are good to go for another year from that point, all right.

So everything is going fine and now you want to create another app A version, let's do an app A 2.0, you do the same thing again just assign it a code signing certificate, you don't have to include another provisioning profile in app A 2.0 because the apps bundle ID didn't change but it's a good idea because provisioning profiles are free to renew just make another one, bundle it in with app A 2.0 so when the user downloads it at that time they get a full year's worth of use of the provisioning profile.

And time goes on and you keep doing this over the years and everything is great, all the users are getting their provisional profiles pushed by MDM, you don't have to do a thing, the app continues to run. All right so now you're 2 1/2 years into your first code signing certificates validity date. You decide to create another app, app B 1.0.

You could sign app B with your current cosigning certificate but you're going to get six months of use out of it. So many of our enterprise developers will have some kind of threshold date where they say if there is less than this number of days left in my original code signing certificate I'm going to create a new one. So we're going to assume six months is too little, they're going to create a new code signing certificate and sign app B with a new code signing certificate.

Because you're signing at B with a new code signing certificate you're going to have a new distribution provisioning profile for app B which you include and everything is great, everything works, app A continues to work with the old cosigning certificate and app B continues to work with the new cosigning certificate, everything is fine until you reach close the end of app A's code signing certificate validity date.

What do we do now? Well, you can't reuse the old code singing certificate but you have a new code signing certificate that's good for another few years however in order to update the code signing certificate in your app you must distribute a new version of your app that is signed with a new code signing certificate, okay. And because the code signing certificate has changed you also need a new distribution provisioning profile for app A, which you bundle with app A and you distribute.

Now everything is good for another 2 1/2 years or so. Notice your code signing expiration dates and use the newest code signing certificate that you have on hand, embed a new provisioning profile every time you distribute a new app. Host your in house app using HTTPS, this is just a little note because we've made a recent change in iOS that requires HTTPS in order to download your in house apps. Then use MDM to distribute your apps and to refresh you provisioning profiles silently. Remember that an app must be updated in order in order to change its code signing certificates. All right so that's a little bit about app distribution strategy.

All right now let's talk about custom B2B, so what's custom B2B custom B2B are apps that are hosted in the Apple App Store but are only visible to a limited audience. Because they are hosted in the App Store they are reviewed by Apple but when you install a custom B2B app there's no provisioning profile required because they are considered App Store apps.

To publish a custom B2B app you have to be an App Store developer, not necessarily an enterprise developer, you follow the same steps that you do for publishing irregular App Store app, however all you got to do is check that little box that says custom B2B and when that happens you get a field that allows you to specify what Apple ID's can see your app. These Apple ID's are Apple ID's for the VPP portal, the volume purchase program portal, right here.

When a custom B2B app is published and an Apple ID is put in there the purchaser of that app can see these apps, list it at the bottom of their VPP portal where they can then purchase licenses and push these apps out using MDM as though they were App Store apps.

So why would you use custom B2B? If you're an enterprise custom B2B is great if a custom app that's made for you contains code that you don't own, when you buy an app tailor made for you from some, from a separate company for example you can ask them to publish the app as a custom B2B app which you can then view and purchase using your own portal and you will know for sure that nobody else gets access to that app.

Okay, they're also great for subsidiaries so if your company if your enterprise happens to be a conglomeration of subsidiaries many of them have different VPP programs with different requirements creating a custom B2B distribution maybe easier than developing an enterprise app for them, all right. So a custom B2B app does not require any code signing or provisioning profile watching for code signing provisioning profile expiration because they are App Store apps. You can create promo codes for beta testing your apps.

So that's custom B2B. So today we've covered several high level topics here, managing your team and the roles in the program. We talked about Xcode server and how it can become a great hub for your development team. We talked about app distribution strategies and we've talked about custom B2B and how that can be used in your enterprise. Some Key take-a-ways, agents and admins should be employees, contractors should be team members. Use Xcode server for continuous integration and QA and keep an eye out for the code signing and certificate expiration dates and use custom B2B if you don't own the code.

All right I want to call your attention to a great portal site that was just launched, developer.apple. com/enterprise made especially for enterprise developers. Our evangelist is Paul Danbold and development forums are always a great resource for you. Some related sessions, this morning we had Managing Apple Devices please check the video out. We had Building Apps for Enterprise and Education earlier today, with that thank you very much.