WWDC2019 Session 304

Transcript

[ Music ]
[ Applause and Cheering ]
>> Hello. My name is Ashley
Carroll, and I'm a consulting
engineer from New York focused
on app development.
I spend my time working with our
largest business, government,
and education customers, helping
them build and distribute great
apps for their employees.
Welcome to App Distribution From
Ad Hoc to Eenterprise.
So who here in the room today
has had to distribute an app
before?
Just a few hands, right.
You're in the right place.
So, pretty much everyone has had
to do this, and whether you're
building apps for the App Store
or focusing on building
customized private apps for
business or enterprise, you
should learn something today.
I want to begin by taking a step
back from app distribution and
talk about the life cycle of an
app from its earliest
beginnings.
Most of us probably know this
part of the process inside and
out.
It all starts with an idea for a
problem that you want to solve.
You figure out what to build.
You create a great app, and it
makes it into the hands of your
users, most often through the
App Store.
Today, we'll be focusing on that
last bit, how users actually get
your app onto their devices.
It seems simple, and for lots of
apps on the store, it is.
But there's actually a number of
different ways that you can
distribute an app.
And that depends on who your
customer is.
This is all about finding the
right way to reach your users.
Your users could be the general
public or business and education
customers.
Depending on who your app is
for, there are different ways to
distribute it.
There are four distribution
methods that we're going to
cover today.
Ad hoc, App Store, in-house, and
custom apps.
How do you determine which path
is the most appropriate for you?
This depends on a number of
factors, and some questions you
might ask along the way include
who's the audience for this app.
Who's going to maintain the
source code?
Are you building the app for you
or for someone else?
Is someone buying this app for
their employees or students to
use?
All of this comes down to asking
who, and we can focus that on
who was using the app and who is
buying the app.
Knowing that the customer and
the user are not always the same
person or entity is critical to
mastering the different ways
that apps can be distributed and
figuring out where your app
fits.
If you can identify your
audience, it becomes a lot
easier to pick the right
distribution mechanism.
Most often, an individual is the
both the customer and the user.
They download your app from the
App Store on their own device
and then use it themselves.
Ad hoc distribution lets you
distribute to a limited number
of devices that you choose for
testing, and the App Store lets
you distribute apps to the
general public.
Now, sometimes when dealing with
the business and education
market, the customer is actually
an organization, and they're
purchasing apps on behalf of a
group of users who will use
those apps on either devices
that that organization provides
to them or on their own devices.
So there are two different ways
that you can distribute apps in
this scenario, in house and
custom apps, and those both let
you distribute apps privately to
organizations.
Your app might have different
reasons to use all of these
distribution methods at
different times in its lifetime
or simply live in one of them,
and different distribution
mechanisms are associated with
different types of memberships
in the Apple developer programs.
We're going to walk through each
of these distribution methods
today.
The expectations around each and
everything that you need to know
to figure out where your app
fits.
We'll do this by following an
app on a distribution journey
from its very beginnings as a
prototype, through the App
Store, and through being
customized for a business to be
distributed privately in a few
different ways.
That app is LunchControl.
LunchControl is an app for
collaborative food ordering, and
when we're talking about
LunchControl, I want you to
imagine yourself as the
developer for this app.
We'll begin with how
LunchControl came to be.
This whole journey starts with
ordering lunch at the office.
Everyone loves to get takeout,
but the process for ordering and
for a big group of people is
daunting and time consuming.
You have to figure out what
everyone wants to eat and go
through each of the orders to
make a consolidated list.
So, make sure you remember that
Trevor doesn't like tomatoes,
whatever your boss' usual is,
and that the new guy, Rod was
it, said he wants a turkey club.
Does this sound familiar to
anyone?
It takes way too long, so it's
almost not worth ordering, and
it really sounds like a great
problem to solve with an app.
So you give it a try, and you
come up with a prototype.
To build your prototype, you've
downloaded Xcode, started
exploring the SDK, and you've
logged in using your Apple ID.
I'm sure most of you know how to
get started because you've
probably already published apps
to the store, but we're going to
review this part of the process
quickly, just so that everyone's
on the same page, and you really
get a full picture of app
distribution from start to
finish, and hopefully you'll
learn something new along the
way.
This is your prototype.
You can select items from the
menu and create a group order.
All of the items are nicely
summarized, and it even breaks
up the cost per person.
But how would you actually get
this prototype running on your
devices?
You can sign into Xcode with
your Apple ID and leverage the
free account that comes with it,
called the Personal Team.
This enables you to explore the
SDK and test apps on your
device.
You can only deploy a limited
number of apps to a few devices,
and they expire after a few
days, so this isn't a real
distribution method.
Here's what you see in Xcode
once you're logged in with a
personal team.
You build and run your app.
Xcode installs it on your
device, but in order for it to
be able to launch, you'll need
to trust your developer
certificate on your device.
This is what that process looks
like.
You can trust the developer
certificate by going into
settings, general, profiles, and
device management.
Here are a few best practices to
keep in mind for personal teams.
These accounts are really meant
for learning.
The assumption is that you're
going to be deploying to devices
that you own, and this isn't for
distribution beyond your own
devices.
Some capabilities like CloudKit,
Siri, or APNS aren't available,
and there's no way to publish
apps to the store with this
program or debate a testing with
other users.
The goal for LunchControl is to
go beyond this learning stage.
So, let's talk about the first
way that you can distribute
LunchControl.
Ad hoc distribution can be
utilized to distribute apps for
testing.
Up until this point, you've been
walking around to different
people's desks to take their
orders and mostly just testing
the app in the simulator and on
your own device.
You're really ready to have a
few friends try it out and get
feedback and see if you've got
something special, and you also
think that integrating with Siri
and push notifications would
make the experience even better,
which aren't available with
personal teams.
Membership in the Apple
Developer Program is required in
order to distribute an app to
others.
So, this is the point where if
you don't already have an
account, most developers would
sign up, either as a company or
an individual, and once you're
signed up, you're ready to start
distributing to others.
When you leverage ad hoc
distribution, a limited number
of users can install your app
directly from their devices for
testing.
The process requires that you
register their device from the
developer website, and there are
a limited number of devices that
you can register for both
development and testing.
That's 100 devices per product
family per year.
For your average user,
registering a device involves
connecting it to a Mac and
getting the device identifier,
either from the finder's sidebar
or retrieving it from Xcode,
which means that you as a
developer would need physical
possession of their device.
You then take that identifier
and add it to the Apple
developer website, and once you
have their device registered,
you're ready to create a build
and install it for them.
There are several different
alternatives for installing ad
hoc builds for testers.
You can tether the device to
your Mac and install with Xcode
or Apple configurator, which is
available on the Mac App Store,
or you can host the app
somewhere and enable
over-the-air installation.
This is a manual way of
achieving a limited distribution
to a small group.
This program is designed to let
you deploy to registered devices
for the purpose of testing.
It's not a long-term or scalable
distribution solution, and the
provisioning profiles used to
sign these apps expire yearly,
so eventually the apps will stop
working or need to be re-signed.
For larger teams, it's really
important to take note of the
device limits.
It can be hard to develop for
new products if you run out of
devices, which is why you have
to be careful when using
development devices for testers.
These device limits are reset
once per year, and if you're
curious about when your device
counts are going to be reset for
your account, you can go to the
member page on the developer
website and look at the reset
date.
Ad hoc distribution gave us the
ability to test with a few
users.
You quickly realize that ad hoc
distribution isn't scalable as
the number of people who want to
test the app grows.
So, let's talk about the App
Store.
The App Store offers a much
better way to do beta testing
for a large group of users.
User interest in LunchControl is
growing, and you want to expand
your audience to include more
testers.
TestFlight makes it really easy
for both developers and users to
try out apps, and installation
and updates are simple.
You could scale up to 10,000
testers.
The builds last for three
months, and for a user,
installing an app is a familiar
and simple process.
TestFlight beta builds for
external testers do go through
app review.
So, you need to make sure that
you're following the App Store
review guidelines before
submitting, and the app needs to
be stable and ready for a
broader audience to test.
However, if you're making a
build available to only members
of your App Store connect team,
review isn't required.
And TestFlight is only available
to members of the Apple
Developer Program.
TestFlight is built right into
App Store Connect.
For those of you who are only
familiar with the Apple
Developer Enterprise Program and
have probably never used App
Store Connect before, this is
what it looks like.
App Store Connect enables you to
easily upload, submit, and
manage your apps on the App
Store.
All of your TestFlight builds
are available to see here, and
you can invite testers to test
your app.
Testers can install your app
from the TesFlight app on their
devices.
Once you invite a tester in
TestFlight, they will receive an
email invitation to beta test
your app.
They can review all of the
testing details that you provide
and install the app to start
testing right away.
Once you're satisfied with the
stability of your built, the
next step is submitting to the
App Store.
For LunchControl, you've made
some updates, added features
based on feedback from your beta
testers, and really iterated on
your design.
You're ready to list the app for
sale, and you've even updated
your app icon.
You've done the hard work to get
your app ready for submission.
Let's consider who the user and
who the customer is here.
Both are the general public,
which makes this app appropriate
for the public app store.
Any individual can download and
use your app, and the person who
is buying it is also the person
who's using it.
Here are a few things you should
know about how App Store
distribution works.
Both individuals and
organizations can sign up for
the Apple Developer Program to
distribute to the App Store.
Apps are available to the
general public based on the
markets that you choose to
support, and the apps are hosted
and reviewed by Apple.
This means that developers are
expected to know and follow the
App Store review guidelines.
It's also expected that you keep
current.
This means supporting new
hardware and screen sizes,
modern APIs, and new features,
like all of the exciting things
that we've announced this week.
And just to reiterate, the App
Store is appropriate for apps
that are for the general public,
which means that if you're
building an app for the
employees of a specific company
to use, the public App Store is
probably not the most
appropriate place for it.
Let's talk about a few more
scenarios that developers might
run into in the App Store.
First, let's talk about the
ability for a customer to
purchase your app in bulk for a
group of users.
There are programs in place that
enable you to do this.
For LunchControl, a bunch of
your friends are teachers at a
local school, and their school
wants to purchase the app in
bulk for all of the faculty to
use.
As a developer, if you want to
offer them a discount, you need
to make sure that this is
enabled in App Store Connect.
In this case, your user is still
the general public.
So a group of teachers who would
be using your App Store app, but
the customer that's doing the
purchasing is actually the
school that they're working for.
Customers use Apple Business
Manager or Apple School Manager
to purchase apps like
LunchControl from the App Store
in bulk and distribute them to
their users.
To verify that an education
customer can purchase your app
at a discount, you would take a
look at the pricing and
availability section in App
Store Connect.
The default availability option
for an app is available at a
reduced price for educational
institutions.
If the educational institution
purchases 20 or more licenses,
and you have this enabled for
them.
They'll receive a 50 percent
discount, and Apple School
Manager is required for them to
make this purchase.
Next, I want to discuss proper
versioning for an app and how to
handle adding additional
features.
As LunchControl grows in
popularity, more and more
feature requests are coming in,
and more organizations start to
become interested in leverage
the app.
Some users or organizations may
ask you to add features that may
not make sense for your entire
audience, but you need to be
careful about versioning your
app in the app store
appropriately.
As you start to expand your
customer base and consider
offering multiple versions of
your app on the store to various
clients or even variations of
your app for different types of
users, like if having an admin
and a regular version made sense
for you, you want to handle
versioning and your app store
presence appropriately.
This is what could happen if
LunchControl doesn't manage
their App Store presence
properly.
This is actually a real example
from the App Store, just using
the names from Liquid Oxygen
Company and LunchControl.
Don't do this.
When a user searches the App
Store for a given name, this is
what they might see if you
version your app this way.
They have no idea which app to
pick, and if they pick the wrong
one, they might not be able to
log in or use it and might not
behave in a way that's expected.
This is a really frustrating
experience for a user, and it's
easily overcome by managing your
versions better in software and
moving your customer base
forward as you make changes to
your app and your product.
What developers should do
instead is consolidate app
versions as much as possible.
Ideally, it's one app, just like
you see here on the left.
This does require more
development work, but in the end
it's a much better customer
experience, and if you as a
developer start getting requests
for lots of different customized
versions of your app, it might
be a good time to talk about how
you could deliver those versions
privately using custom apps,
which we'll get into in a few
minutes.
The final App Store scenario I
want to cover is building an App
Store app for someone else.
Your company, Liquid Oxygen,
LLC, might be approached by a
customer to build their own
public facing app.
In this case, we're going to
talk about Liquid Oxygen being
approached by a restaurant
chain, Taco Bar, to create their
App Store app for them.
Taco Bar loves what you've done
with LunchControl and really
wants you to build them an app
where customers could place
orders, find the Taco Bar
locations near them, and pay for
their food.
They currently don't have an App
Store presence, so this would be
their flagship app, and you, as
a developer, don't want to give
Taco Bar your intellectual
property.
In this scenario, the user of
your app is still the general
public, and the customer is
actually Taco Bar.
You would be building an app for
Taco Bar for their customers
while still maintaining control
of your intellectual property
and running Liquid Oxygen, LLC.
This is a brand-new app that
will have a separate bundle ID
and will exist on the App Store
alongside LunchControl.
This is not simply publishing
the same app under a different
customer name.
It's a new and distinct
experience.
So, how would Liquid Oxygen work
with Taco Bar as a third-party
developer when building an App
Store app for them?
What's the best way for them to
work together?
Taco Bar is hiring Liquid Oxygen
to build an app and submit it to
the store under their developer
account.
The developer has to join Taco
Bar's developer program and
provide a build of the app for
Taco Bar to submit to the store.
This is what that workflow
should look like.
The two developer roles that
Taco Bar should assign to Liquid
Oxygen are Developer and
Marketing.
This would allow them to upload
bills and provide marketing
metadata like the app's
description and screen shots.
The admin role should remain
internal to Taco Bar.
This enables Taco Bar to control
TestFlight distribution,
pricing, submission, and go live
on the App Store.
The app manager role should also
remain internal.
Here's what it looks like to add
and manage users in App Store
Connect.
Users with the admin and app
manager roles can create and
edit users and also restrict a
user's access to specific apps
in the account.
Make sure to limit third-party
developer access to only those
apps that they're working on.
But note, user access cannot be
restricted to specific apps on
the developer site.
Users will have access to all of
the bundle IDs on the developer
site.
You can see here that Tracy is
the developer, and she has
access to the Taco Bar app only.
And if LunchControl and Liquid
Oxygen, LLC, were no longer to
have a relationship with Taco
Bar, the customer could always
remove them as a third-party
developer later on.
If you're developing an app for
a business, that business is the
only one allowed to submit to
the App Store.
That means that apps must be
submitted under client accounts,
and customers of Taco Bar are
going to expect to be
downloading an app from Taco
Bar, Ltd., not from Liquid
Oxygen, LLC.
For more information on this,
you can review to App Store
review guidelines section 5.2.
Powerful roles like admin and
app manager should be limited
for third-party developers, and
customers should also limit app
access to only the apps that
they'll be working on, and you
should also follow the best
practices for app versioning
that we discussed.
That concludes our discussion
about the different scenarios
where you would distribute a
public-facing app through the
App Store.
For the remainder of the
session, we're going to talk
about two ways to distribute
apps that are customized for a
business, intended to be used
privately and internally by that
business.
The first one we'll talk about
is in-house distribution.
Let's check back in on
LunchControl.
Exciting things are happening,
and Acme Company has approached
you to build them a custom
version of LunchControl for
their corporate cafeteria and
catering services so that their
employees can order food and
have the same great experience
that you offer in your app.
This would mean incorporating
their back-end system into the
app and building a totally
customized version for them.
In this case, Acme Company is
going to be the customer
purchasing a custom app for a
group of users who happen to be
their employees.
We'll call it Acme Co. Café.
Knowing that the audience for
this app isn't public, it's the
employees of a company, it's
apparent that a public app store
isn't appropriate for this use
case.
When we think about apps for
internal use, there are two
distribution methods that come
to mind, in-house and custom
apps.
In a previous world, Acme
Company would probably have an
Apple Developer Enterprise
Program account and would
utilize in-house distribution to
deploy this app.
For a very long time, this was
the only way to do it.
But recently, we've enabled the
ability for these types of apps
to be hosted on the App Store's
infrastructure via custom apps,
and there are a host of benefits
to doing so.
While the Apple Developer
Enterprise Program still exists,
it's no longer the standard
mechanism for distributing
private internal apps.
There are some exceptions where
it still may be appropriate, but
for the vast majority of those
building private internal apps,
custom apps is going to be the
way forward.
In-house distribution, we'll
just cover it so that you know
how it works if you do run into
it.
So, in-house distribution
enables you to control the
entire distribution process and
host the app yourself.
It requires membership into the
Apple Developer Enterprise
Program, but there are strict
eligibility requirements to get
into that program, and it really
is meant for those cases that
really can't be solved by custom
app distribution.
Regions where Apple business
manager doesn't work, use cases
for state and federal
government, or use cases where
there are other intellectual
property issues could still
qualify for in-house
distribution.
Organizations utilizing in-house
distribution should own and
maintain the source code so that
they can do their own build to
maintain the project.
Distribution is handled
completely outside of the App
Store by the organization and is
usually done by MDM.
If you do find yourself in a
situation where you're leverage
in-house distribution, there are
a few things that you should be
aware of.
First and foremost, the apps
that you deploy using in-house
distribution must only go to
your employees and cannot be
made available to others.
Apps are signed by the
organization with a distribution
certificate, and that
certificate needs to be
protected.
If it were to be compromised or
revoked for any reason, all of
the apps that you deployed with
that certificate would stop
working immediately, and they
would need to be re-signed and
redeployed.
As you might imagine, that could
be catastrophic for a business.
Additionally, certificates will
expire every three years, and
the provisioning profiles expire
annually.
So you need to manage that
certificate lifecycle and plan
for frequent releases of your
app that are aligned with it.
Beta testing and hosting of the
apps needs to be handled by the
organization and MDM, and
there's no TestFlight access for
enterprise accounts.
Apps are also going to need
periodic access to the internet,
which makes it very difficult to
deploy apps in air gap networks.
Based on what we just talked
about, in-house distribution
isn't going to be a good fit for
Acme.
Let's move onto Custom Apps.
This is the new way forward.
This scenario could work one of
two ways.
The developer could simply offer
the app for sale to them via
Custom Apps under their own
account, which would protect
their intellectual property.
This could be described as
business to business, and this
is actually the way that Custom
Apps used to work.
Alternatively, the developer
could negotiate with Acme
Company and provide them source
code, and they would handle the
submission of the Custom App
themselves under their own Acme
account, which we could describe
as business to self.
Either way, Custom Apps is the
right solution.
How does Custom App distribution
work?
Custom Apps are part of the
Apple Developer Program and are
hosted by Apple in Apple
Business Manager.
Custom Apps used to be available
only to developers selling an
app to another organization, but
you can now use it to distribute
internally to your own employees
just like you would leverage
in-house distribution.
This make it much easier to
distribute apps to your
employees, and Custom Apps works
for distributing to employees,
partners, clients, franchisees,
or affiliates.
Customers can also distribute
licenses via MDM or leverage
redemption codes.
For those of you who are used to
the Apple Developer Enterprise
Program, Custom Apps offers a
lot of benefits.
You'll only need one program to
manage both your App Store and
your internal apps.
The apps won't expire, so you
don't need to worry about
distribution certs being revoked
or expiring.
While with in-house distribution
you could only distribute to
employees, Custom Apps actually
allows you to reach a broader
audience, including business
affiliates.
It's also easier to work with
third-party developers because
you can get and distribute an
app from them without having
access to the source code, and
there's no re-signing of
binaries involved.
You can also take advantage of
the App Store's auto update
infrastructure, features like
caching and app thinning as well
as the TestFlight and App Store
Connect tools.
Here's how you would actually go
about submitting a Custom App.
First, you would confirm that
your account is properly set up
to support Custom Apps.
Both app agreements need to be
active, and you need to provide
banking and tax information.
You can leverage roles to define
proper access for the project
team once you have the app set
up.
A developer would create a new
app identifier in the member
center of the developer website
and also a new app record in App
Store Connect.
Anytime that you want to list a
custom app for sale, you need to
create a new app ID and a new
app record.
The same bundle identifier
cannot be available in both the
public App Store and privately
as a custom app.
They're totally separate apps
with separate bundle InDesign.
Next, you would upload a build
and attach it to the working
version in App Store Connect.
Beta testing would be done with
TestFlight.
When Beta Testing is complete,
all of the app metadata and
finalized marketing material
should be verified and added.
You would then list the app for
sale as a custom app in the
pricing and availability
section.
Note, once an app is submitted
for review as either a custom
app or a public app, you can't
go back and change the audience
from public to private for vice
versa later on.
To list the app for sale as a
custom app for business, you
need to provide the customer's
DEP ID and organization name.
The DEP ID is a unique
identifier given to the
organization when they enroll in
Apple Business Manager.
Finally, you would submit the
app for review.
Once it's approved and
available, you customer can
purchase and distribute the app.
Purchasing is done through Apple
Business Manager.
The customer would enroll at
business.apple.com, and with
this program, they can buy App
Store apps, custom apps and
books in bulk, and deploy to
their devices and users.
They can also do app license
management.
Note that this needs to be set
up in advance of you listing the
app for sale as a custom app
because you need that DEP ID and
organization name to distribute
the app to them.
And Custom Apps will also be
available for Apple School
Manager this fall.
This is what Apple Business
Manager looks like.
Your customer will see the app
that you are listing for sale
for them under the Custom Apps
section.
Let's review what this process
looks like end-to-end for both
the customer and the developer.
The customer first provides you
with their organization name and
DEP ID from Apple Business
Manager.
Once you have that, when you set
up the App in App Store Connect,
in the pricing and availability
section, you select to make it
available privately as a Custom
App for business and specify
that DEP ID and organization
name.
Once the app is submitted and
approved, the customer can then
go and purchase licenses of it
from Apple Business Manager.
If for some reason you aren't
able to submit a custom app or
your customer isn't able to see
an app that you've assigned to
them, here are a few places that
you can troubleshoot.
First, on the developer side,
make sure both the free and paid
agreements are complete as well
as all of your banking
information.
If the customer isn't able to
see the app, make sure that
Custom Apps are enabled for
their account under settings and
enrollment info in Apple
Business Manager.
It also may take a few minutes
for the app to become visible in
Apple Business Manager, so just
give it a little bit of time,
and you can also consult the App
Store Connect help page for more
information.
Here are a few things to keep in
mind about Custom Apps.
Customers need to have an Apple
Business Manager account to
purchase your app.
Apps have to support the
countries that they will be
distributed in.
By default, an app is set up to
support all territories in App
Store Connect, and you shouldn't
change this unless you really
need to.
It's expected that if you're
utilizing redemption codes for
distribution that they won't be
made publicly available, and
you'll instead make sure they
make it into the hands of your
specific users.
This is a new app that needs to
go through app review, and the
review team is going to need to
be able to access the full
functionality of the app.
And once submitted, apps can't
be moved between public and
private availability.
That concludes Custom Apps.
We've covered the four
distribution methods that you
have to choose from, and the
easiest way to decide which is
right for you is to think about
the audience for your app is
public or private.
Ad Hoc lets you distribute to a
limited private audience for
testing.
The App Store lets you
distribute apps to the general
public, and In-House and Custom
App distribution let you
distribute apps privately.
Let's review the distribution
scenarios that we talked about
today.
What if the app is for the
general public?
If the app is for the general
public, it belongs on the App
Store.
What if you don't want to give
up your intellectual property to
an enterprise.
If you don't want to give up
intellectual property, you can
leverage Custom Apps to deliver
them a private, completed app.
And if you're writing an app for
the company where the audience
is the general public, you can
also deliver them a binary to
upload to their App Store
Connect account.
What if your customer doesn't
have an MDM solution?
The Custom Apps program along
with MDM can be used to deliver
apps to customers who don't have
MDM.
What if you're being paid as a
consultant to build an app for a
company?
So you can work in both the App
Store and the Custom Apps
program to, as a third-party
developer, to deliver an app to
someone else.
What if Apple Business Manager
isn't available for my customer?
So, if Apple Business Manager
isn't available, your customer
should be able to leverage
in-house distribution providing
that they're building an app for
their employees.
And what if the app is employee
facing?
Employee facing or private apps
can be distributed with both
Custom Apps or In-House, and
what if you want to distribute
an app to your own organization?
You can distribute to your own
organization using Custom Apps
or the In-House program.
To conclude this presentation, I
want to leave you with a quote
from a colleague.
"Apps are like cannonballs.
It's better to know where
they're going before they
deploy."
Apple wants you to be successful
and scale your app in the
smartest possible way, which
means thinking carefully about
the user and the customer,
managing your versions
appropriately, and knowing and
understanding the guidelines or
our developer programs.
If you understand how this works
up front, you can pick the right
distribution mechanism for your
app and deploy it to your users
without any friction.
For more information, this is
developer site, this is session
304, and please visit us at the
lab on Friday and also check out
What's New in Managing Apple
Devices if you want to learn
more.
Thank you, and enjoy the rest of
the conference.
[ Applause ]