Hello!
My name is Robert Terakedis, and I'm on the Technical Marketing team focusing on Apple
Device Management with Workspace ONE.
Today I'd like to focus on the current landscape of software management for Apple Platforms
and the current capabilities within Workspace ONE to enable this.
In this video, I'll cover the following topics.
First, I'll explain recent changes for Enterprise Software Developers developing for iOS and
tvOS.
Next, I'll cover how Workspace ONE manages iOS and tvOS software.
After that, I'll explain recent changes for Enterprise Software Developers developing
for macOS and how Workspace ONE helps manage software for Mac.
First thing, if you missed it, there was some noise at the beginning of 2019 with Google
and Facebook in the news over some abuse of Apple's Enterprise developer program.
As shown in an investigation by TechCrunch, both companies were externally distributing
software signed with developer certificates meant for internal use only.
This led to Apple revoking the certificates for a short time which impacted their own
legitimate business-internal applications.
But what went wrong in this scenario?
Why would Apple revoke the Enterprise signing certificate?
First, there was violation of the intended terms of use for the developer signing certificate.
Enterprise signed apps are intended for use by the Enterprise, and NOT the general public
(or partners, etc).
Additionally, by signing the app in a method intended for internal, non-store distribution,
the developers were able to bypass Apple's application review process.
On top of that, the app being distributed by Facebook was said to have previously been
banned by the App Store.
In other words, Apple already declined to make the app available to non-Facebook users.
With that said, it's important to understand all the different app distributions available.
If you're attempting to distribute an app to individuals, you can start by distributing
the app via Personal or Ad-Hoc distribution for limited, private testing.
Once your app is ready for the general public, you can use App Store Connect to submit your
app to the Apple App Store for review and sale.
From an organization or Enterprise perspective, Apple traditionally had three ways to distribute
software.
The first was to distribute apps publicly via the App Store in the same way as individual
developers could do so.
As an example, VMware uses this method to deliver our apps such as VMware Boxer and
the Workspace ONE Intelligent Hub for iOS.
For non-public apps meant for enterprise use, Apple allowed you to sign and distribute apps
internally without using the App Store.
Apple also had a third method of Enterprise distribution known as Custom Apps (previously
known as B2B apps).
Organizations develop applications and submit them to the App Store, restricting the distribution
of those apps to select enterprises (either Business-to-Self or Business-to-Business).
However, looking back at WWDC 2019, Apple mentioned Custom Apps as "the new way forward."
Basically, organizations that currently can sign In-House apps (using an Enterprise signing
certificate) will continue to have that capability (that capability is not going away for the
time being).
However, organizations new to the Developer Program should leverage Custom Apps and will
not be able to sign apps using an Enterprise signing certificate.
To do so, these Organizations need to meet strict eligibility requirements.
As an example, you may need to request an Enterprise signing certificate if your organization
distributes apps to countries where Apple Business Manager or Apple School Manager is
not available.
But why Custom Apps?
What is the benefit over In-House apps?
There are a few key differences I'd like to call out.
First and foremost is the audience.
Again, In-House apps are strictly meant for use by employees of your own organization.
With Custom Apps, you gain the ability to distribute apps both internally (Business-to-Self)
and externally to partners or customers in a Business-to-Business scenario.
Second, since Custom Apps leverage the App Store infrastructure and processes, you gain
many of the same benefits (even though your app is distributed privately).
For starters, organizations gain the use of TestFlight for beta testing your Custom Apps,
which is a premium experience over manually managing your beta testing.
Custom Apps can be stored in macOS caching services for localized delivery to multiple
devices.
You no longer need to rely on custom caching services implemented by a third party.
Finally, there's no need for MDM administrators (or developers) to maintain any app signing
or provisioning profiles, as normal App Store processes maintain a Custom App's signing.
This helps keep the apps working as expected over time and prevents them from expiring.
Digging deeper, be aware that Custom apps (and any updates to custom apps) go through
the App Store app review process.
This means you need to allow for approximately one to two days for Apple to verify operation
of your app.
Also, if the app requires any type of login or data sets, you'll need to provide generic/sanitized
test accounts and data for Apple to use during their review.
More detail about this is covered in depth in the WWDC 2019 session on App Distribution,
and also in Apple's documentation (linked in the attached deck).
So how do you make an app a "Custom App?"
Much like a public app, you'll have a few prerequisite steps.
First, you'll first need to make sure you've registered your App ID (or Bundle ID) in either
Apple's developer site or in App Store Connect.
Then, within App Store Connect you'll upload a build and optionally beta test it with TestFlight.
Finally, when you're ready to start distributing as a Custom App, you'll list it for sale but
select "Available privately as a Custom B2B App" as the Distribution method for Business
and EDU.
You can see in the screenshot fields to specify either your own or a customer's Apple Business
Manager or Apple School Manager ID.
Once made available to these IDs, admins in those Apple Business or School Manager instances
can now search for the app and purchase managed distribution licenses for that app.
For clarity, the "DEP ID" field refers to the Organization ID in Apple Business Manager.
Basically, if I was an organization looking to license or use a Custom App developed by
another company, the Organization ID is the number I would need to supply to App developer
for them to add in their list of DEP Customer IDs in App Store Connect.
If I was looking to distribute my own app, I would need to ensure my own Organization
ID is in the list so that I could license the app in Apple Business or School Manager's
Apps & Books listings.
Now, talking through managing iOS and tvOS software…
I wanted to lay out what the platforms support versus what Workspace ONE supports.
As you can see, from an iOS perspective Workspace ONE supports managing all the app types.
You'll also see that Workspace ONE does support tvOS apps, with plans to fully support VPP
and Custom apps for tvOS on our roadmap.
One thing I would like to clarify is that Non-VPP apps aren't supported in the MDM specification,
and therefore not something on our roadmap.
Looking at each iOS app type, we can examine the support for each different kind.
For In-House Enterprise apps, Workspace ONE can assist with delivering application configuration
key-value pairs and APNS certificates.
We can also provide app and provisioning profile updates and help with beta testing and previous
version rollback.
With Volume-Purchased apps (bought through Apple Business or School Manager), Workspace
ONE has a similar set of capabilities, including app config key-value pairs, automatic updates,
metadata refresh, user or device licensing, and SDK profiles.
With Custom Apps, you get critical capabilities such as app config support, automatic updates,
metadata refresh, and user or device licensing.
Let's move over to macOS, and let's look at the landscape there.
It's a bit less complex than the app landscape for iOS.
There are only two types of apps – those delivered outside of the App Store and those
delivered from the app store.
Currently, there's no concept of a "Custom App" for macOS.
That means there's not currently a way to limit distribution of a macOS app to a subset
of Apple Business Manager organization IDs.
Workspace ONE does support delivering both types of apps.
Again, the Apple MDM specification doesn't specifically support delivering public (non-Volume)
applications or custom apps.
This is important to understand as a difference between managing macOS versus iOS applications.
One thing that was announced by Apple at WWDC 2019 was the concept of Notarization.
With Notarization, application developers submit their apps to the Apple Notarization
service, which scans apps for malicious code and security issues.
While not a full application review (like that which happens if you submit apps to the
App store), the Notarization helps demonstrate an attacker has not modified an app binary
or injected malicious dependencies.
This is done when the notarization ticket is checked by GateKeeper against the Notary
Service when an application first launches.
As mentioned, one of the key takeaways is that App Notarization is not a full app review
While this session isn't targeted to developers as an audience, I wanted to cover the topic
briefly and also include links to some resources that could be helpful.
If we look at app notarization from a developer perspective, there are a few key items to
remember.
First, as an app developer, you must adopt the hardened runtime for your app within Xcode.
Next, as you sign and notarize your app, you must do it in the correct way (in what Apple
referred to as "inside out" signing).
Finally, you'll need to submit the app to the Notary service and then staple the notarization
ticket to the bundle you wish to distribute.
This can be done via the Xcode UI, or via command line in a multi-step process.
Let's take a look at what this looks like with a basic app.
If you have your macOS app that you're ready to distribute.
You'll build the archive for the app and then select to Distribute the app.
You'll sign it with your developer ID, and then Xcode will submit the app to the Notarization
service.
As we continue, you can see the app has been uploaded to the Notary service.
We can monitor in Xcode for the app to be ready to distribute (in other words, scanned
by the Notary service).
Once notarized, we'll go back through the distribute App process again, whereby Xcode
staples the notarization ticket to the app and rebuilds the distribution.
You would then be ready to distribute that app outside the App Store.
Now that I've covered macOS Software, let's talk about how Workspace ONE helps with managing
macOS Software.
If you look at non-store apps, you can see that Workspace ONE supports a number of features
to augment application delivery.
Admins can upload new versions of applications and decide when to send those updates to installed
devices.
We also support Custom Settings and Pre and post scripting to help configure distributed
apps.
Desired state management helps ensure that managed apps which get removed by the user
are later re-installed by Workspace ONE.
There are also features to help with blocking apps (apps the would prevent an install from
completing successfully), restarts, and Terms of Use acceptance.
From a Volume Purchased app perspective, we support both manual and automated application
updates.
Custom Settings can also help configure volume purchased apps as well.
Volume purchased apps can be assigned to the user or the device, although we recommend
using device licensing.
Finally, we support adding Terms of Use as a prerequisite for volume licensed app installation
as well.
Digging into how Workspace ONE manages non-store apps, we leverage an open-source tool known
as munki.
However, within Workspace ONE the entire process is headless and serverless, requiring no knowledge
of munki from the Workspace ONE administrator.
To distribute Non-store apps with Workspace ONE, you'll need to leverage a few tools:
The Workspace ONE admin assistant, the workspace one intelligent hub, and then you'll also
need to ensure software management has been enabled for your Organization Group.
The basic process for distributing non-store apps is as follows.
First, use the workspace one admin assistant to generate a plist file, dmg, and icon.
Make any modifications to the plist as you need, then upload them all to Workspace ONE
UEM.
Configure any pre or post scripts, deployment settings, and Terms of Use, and then assign
the app to the appropriate smart groups.
So how does Workspace ONE determine that a non-store app needs installed?
There are three main ways we typically see admins checking for app install status.
First, by using an install check script (In the Workspace ONE UI), you can signify an
app install needs to occur by exiting the script successfully with an exit code of zero.
Just a reminder that any script you paste into the scripts tab needs to include the
interpreter directive (also known as the she-bang statement) at the beginning.
Second, the plist file uploaded to Workspace ONE could contain an installs array which
lists the path and version of the app which is being installed.
Finally, the plist file uploaded to Workspace ONE could specify a receipts array.
This instructs the Intelligent Hub to look for receipts (basically a plist file and bill
of materials file) in the receipts directory at private/var/dB/receipts.
There are a few additional methods which can be used, but these 3 are the most common.
Unfortunately, there isn't a strict rigor as to how developers should version applications
and create app install packages.
As such, you may run into instances where the package or app characteristics prevent
the Workspace ONE admin assistant from creating a workable plist file.
As such, you may run into instances where you need to make a modification.
Some common modifications are as follows: 1) You may wish to change the display name
for the app within the App Catalog so that it is more user friendly.
2) you may occasionally see an app where no specific version is captured, and you'll need
to manually edit the version number.
3).
You may notice during your testing that the installation is looping over and over.
In this case there is most likely a version mismatch between the app and receipts and
you may need to instead use an installs array.
Some additional resources for you to find more detail.
First, if you're new to Workspace ONE do check out the Hands-on Lab, podcasts, and Activity
paths on techzone.vmware.com.
We also have a GitHub repository where we're posting samples related to macOS, Windows,
Unified Access Gateway, and more.
Test Drive allows you to experiment in a sandbox environment.
There's also the flings website, with more proof of concept and helper tools.
Finally, join the discussions happening at the Workspace ONE community on VMware Technology
Network.
One quick reminder that Techzone.vmware.com is the place to go for Workspace ONE and Horizon
content.
Thank you for your time!