App black- and whitelisting for ALL apps arrives on iOS soon

My colleague Detlev blogged yesterday already about the capability of hiding iOS system apps coming with iOS 9.3 (in beta at the moment, originally posted on CultOfMac and Reddit).

After some further analysis I’ve to wider the target for that: the new feature will allow you to much more!

By going through the specs and doing some testing it is obvious that you can allow/disallow any app on an iOS device soon. Which means in fact that you’ll have full capabilities for app black- and whitelisting. There is one pre-condition: the device needs to be in supervision.

How is an app identified on an iOS device?

An app on iOS is identified by a so called “Bundle Identifier”. The bundle identifier is a unique string, normally in reverse DNS order, that represents the technical identification id for an app. For example the identifier for our app midpoints traveler.rules is de.midpoints.travelerrules.

What are the new capabilities?

According to the specifications Apple has defined three kinds of different settings:

• Allow all apps
• Allow only selected apps
• Disallow selected apps

The setting “Allow all apps” is pretty much what you know from a current iOS device. Nothing new here. But the fun will come up with the other two settings.

“Allow only selected apps” will only show the apps that you have defined as allowed. For that you can either define the exact bundle identifier or only a partial match of the identifier.

The same identification applies for “Disallow selected apps”. Where in this case the selected apps are disallowed as the name says.

How is the effect on a real device?

The usage is pretty simple:

If you allow only selected apps everything else won’t be visible on the home screen. So when you deploy a policy of this kind for only apps that have “winkelmeyer” as part of their bundle identifier, all other apps (including the iOS system apps!!!) will be hidden. You can still install an app from the iOS App Store that doesn’t contain “winkelmeyer” in their bundle identifier - but it won’t show up afterwards.

The same applies vice versa if you disallow selected apps. An app that matches (partially) in the bundle identifier won’t be longer visible on the home screen and you cannot install it on the device.

You can bundle one “restriction payload” with multiple allowed apps. If you deploy more than one “restriction payload” with allowed apps your screen they’ll be concurrent, so that none is visible. Contrary to that you can have multiple “Disallow” configurations deployed. They are active at the same time on a device.

Want some evidence? This screenshot shows my iPad where I’ve only allowed our app midpoints doc.Store.

The use cases

There are lots of use cases that can be fulfilled with these upcoming restriction. As usual the main target audience are enterprises and educational institutions.

• You can hand out devices that only have the app icons for your inhouse applications (identified by using com.yourcorp as part of the bundle identifier).
• Having privacy concerns regarding some apps? No problem, you can disallow them so they cannot be used on the devices.
• You’re offering “company recommended” apps through your inhouse app store and want to disallow the installation of any other app? There you go - allow only those.
• Want to hide several iOS system apps like “iCloud Drive” or “Stocks”? No problem.

Add this new feature to the already available stuff from iOS 9 like Volume Purchasing Licenses on a per-device-base or allowing app installation without the iTunes App Store.

As usual: it’s a beta version, so content may change.