The Importance Of Filing Feedback During Major OS Releases From Apple

Honored Contributor

The following is from a blog post which I think is really important for Mac Admins to read:

It’s not going to be too long before Apple releases macOS Mojave 10.14. They’ve announced it’s release for Fall 2018 at WWDC earlier this year. On August 13, 2018, they released beta 7 and on August 20, 2018 they released beta 8 which indicates they might be making weekly releases up until the general public release of 10.14. Based on previous release dates for macOS, my guess is that Apple will release macOS 10.14 sometime in late September.

Beta testing

If you’ve been part of the beta program and you are in charge of managing Macs in an enterprise environment then hopefully you’ve been providing feedback to Apple about the issues you’ve been running into. If you are not a part of the developer program, then you should join it and provide feedback. You can even have your fee waived for the developer program in certain circumstances. Alternatively, you can also join the Apple Beta Software Program. Even better, if you haven’t already, look into joining the AppleSeed testing program. You can read more about that at Rich Trouton’s blog. There will be differences in how often you get releases and perhaps in the kind of release notes you receive, but it at least gets you access to the beta software.

The next step you need to take is to provide Apple with feedback. In fact, Apple lets you provide feedback for free by going to so long as you have an Apple ID. However, you should ideally use Feedback Assistant especially if you’re in the AppleSeed program.

Unfortunately, due to NDA, I cannot publicly post anything here that isn’t already public. However, the point of this post is to bring some awareness on things that have been made public by Apple that will have a MAJOR impact on any IT administrator managing Macs when macOS 10.14 releases.

Quick recap of changes in macOS 10.13

To give a quick recap, with macOS 10.13, Apple introduced the concept of User Approved MDM (UAMDM). The idea behind this is that devices that have UAMDM can then have their MDM server send out Configuration Profiles that mange specific settings that can only be managed if the device is UAMDM. This can happen one of two ways: 1) the user automatically installs an MDM profile and then approves it, or 2) the device is configured through the Device Enrollment Program.

Apple first started by restricting kernel extensions. Some of those changes during the 10.13 beta were pushed back until better management could be added to the public release. That management feature was the introduction of the User Approved Kernel Extension Loading. You can read more about that at Rich Trouton’s blog. If you notice a trend, Apple has been releasing more and more restrictions with each release of macOS in the name of security. UAMDM is here to stay and more MDM features will probably require it.

Upcoming changes in macOS 10.14

With macOS 10.14, Apple is introducing even more restrictions to what applications can do. I strongly recommend you watch the WWDC full video. The idea of user consent for certain actions taking place by apps or scripts make sense from a security standpoint. This has even bigger implications for IT administrators because often we rely on management tools that may access certain paths that may now require user consent. That’s what the beta is for, right? We can test these new features and the management tools that go with it and provide Apple with valuable feedback.

Unfortunately, although Apple announced these changes to macOS 10.14 on June 5, 2018, the MDM documentation was released August 13, 2018, exactly 69 days later. The relevant change that you will be looking for is Privacy Preferences Policy Control Payload (which according to the revision history was added to that PDF on August 6th, but that’s just not true). That means IT administrators have about 5-6 weeks until late September to test this out. This is absolutely very short notice on Apple’s part to put it mildly. Even more importantly, MDM vendors have 5-6 weeks for Apple to add this new payload (among other new MDM-related changes they’ve made). That means that in order to test this, you need to 1) manually create a Configuration Profile and upload it to your 2) MDM server to push out to your clients which will need 3) UAMDM.

How do I know if I’m impacted?

If you have no idea whether this will impact you, then I recommend the following: get access to macOS 10.14 beta with one of the methods discussed earlier. Run through an installation of macOS 10.14 on a computer and go through your provisioning process for Macs. Run all your tools and scripts that you normally use. Take note of the errors that you start getting and provide that feedback to Apple.

Just to give you an example, here is one discussion on the Apple developer forums on how these changes are effecting IT administrators already.

What do I need to do?

It’s important to provide that feedback to Apple because as it stands they are going to absolutely release these new security and management features in 10.14 as announced without providing sufficient time to test and have IT administrators give them feedback on what works and what doesn’t.

Here is a good example of feedback provided by a fellow Mac administrator on Slack:

macOS 10.14 – AppleSeed for IT
 – Problem Report

Basic Information Please provide a descriptive title for your feedback: Please delay the release of the new TCC security settings to the Sprint Release

Which area are you seeing an issue with? Client Management

What type of issue are you reporting? Suggestion


Description Please describe the issue and what steps we can take to reproduce it:

Yesterday Apple released Mojave beta 7, and also “silently” updated the MDM documentation to finally describe how to manage these new policies.

This is problematic for a few reasons.

1. We can only submit regressions/enhancements now, which means there is a high likelihood that they will not be fixed until after the GM release

2. Given Apple’s track record of releases in the past few years, this gives us less than 5 weeks to adequately test the impact this will have to our environment, our internal tools and any developer applications/tools we could deploy

3. This also gives MDM vendors less than 5 weeks to offer support for this

4. There is no documentation on what Apple deems protected vs unprotected (See Feedback 4813904)

This is very similar to what happened last year with High Sierra, User-Approved MDM and User-Approved Secure Kernel Extensions.

This documentation should have been available immediately following the session “Your Apps and the Future of macOS Security” – – This session was live streamed on June 5th, 2018 and the MDM documentation was released August 13th, exactly 69 days later.

In which build did you encounter this bug? macOS 10.14 – Beta 7 (18A365a)

As an aside, you should contact your MDM vendor to ensure they are aware of this important Configuration Profile payload feature that will be necessary for macOS 10.14. You can link them to the Configuration Profile Reference.

A special note for Jamf Pro customers: please sign your Configuration Profile when you upload it to Jamf Pro to avoid Jamf Pro messing with.... Also, if you’re a Jamf Pro customer, I’ve already made a feature request for them to support this new payload. I’m not entirely sure whether they will be able to release it by macOS 10.14’s release date, but at least it’s on their radar and marked as planned. Another thing to keep in mind: extension attributes are scripts in Jamf Pro that are meant to often collect data. Make sure these scripts/Extension Attributes are running properly in 10.14.

What else can I do?

You can participate in the Apple Developer Forums. There are also a few Mac administrators on Slack speaking about the changes which you can join for free: in #tcc channel. (Did you know TCC stands for Transparency, Consent, Control?) You can encourage other Mac administrators to spread the word and file feedback and bug reports with Apple so that they can understand how poorly timed their documentation on this has been for testing. Blog about this. Reach out to your Apple account reps. Basically, you need to do whatever you can so that Apple is aware that these changes are going to be absolutely showstopping for a lot of organizations that have been given little time to test these new features.

What’s the ideal outcome?

In a perfect world, Apple would have released these features and documentation in the very first beta. However, given how late it is now in the beta testing cycle, the next best thing that Apple can do is 1) fix whatever outstanding issues may exist with these new management features, 2) provide a complete whitelist for all UAMDM devices until it can be properly implemented, and 3) properly document what specific areas of the operating system will now require user consent. They’ve done this before with UAKEL where all Kernel Extensions were completely whitelisted in High Sierra until macOS 10.13.4 at which point you could whitelist specific Kernel Extensions.

IT administrators and MDM vendors simply need a little bit more time to these these out. In essence, give us at least those 69 days that you stole from our testing back. I’m not a fan of a moving target on major features in the middle of a major OS release, but at least this would provide organizations time to thoroughly test these features out. This is just my opinion of course. Comments welcomed below. You are more than welcome to provide a differing opinion on this as long as you provide feedback to Apple!

And hopefully for whatever Apple is planning in macOS 10.15, they will plan accordingly and release those management features in the very first beta for IT administrators and MDM vendors to test.


Valued Contributor II

Thanks, @bpavlov.

Honored Contributor

Another sneak peak as to how you might be effected in macOS 10.14 should you not test and file feedback to Apple: