Transcript
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
>> 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
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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,
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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,
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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,
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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?
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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,
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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,
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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.
[ Applause ]
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
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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,
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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?
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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.
[ Applause ]