In order to be up front on changes in operating system, like iOS, iPadOS, macOS and tvOS, Apple has a certain structure they follow. This is very handy to know if certain apps are business critical, and it needs to be known if it is working on a new release.
I would call it a flow of OS updates that is in constant movement.
Typically major new OS releases are announced at WWDC (World Wide Developer Conference) in June, and the first beta is released at this time. Then these betas gets updated regularly until “1.0” release in September/October the same year. At this release Apple will soon after release “1.1beta”, and when that is done, a new beta cycle starts for “1.2” a so on. Sometimes a “1.1.1” or “1.2.1“ is released in between, but those are usually special very fast bug fixes or security release.
Apple recommends to follow the beta-program if critical apps are used, so the chance of an OS update stopping the business is minimized.
Delay OS updates
If Apple devices are managed, then we can delay that the devices will update to the latest version. It can be delayed up to 90 days, and if this feature is used, Apple recommends only up to 30 days. But after this time, the device can be updated.
This delay means that security patches and updates will also be delayed, and those might be really important for security reasons.
Looking at the delay time in itself; if a software is not ready for the new OS within 90 days, then it can become a critical part of the toolbox, and should be reevaluated for use in the organization.
As of this writing (April 2021), in the time of this writing, we are more than 6 months after the Big Sur release (Sep 2020). One of the new things in Big Sur was the discontinuation of kernel extensions, as well as the introduction of a new Apple SiliconMacs.
When Apple released Catalina in Sep 2019 they also announced that Catalina would be the last OS to run kernel extensions. In June 2020 they release the first beta version of big Sur, showing the new System Extensions that should be used instead.
From a security stand point a kernel extension is a direct line to the kernel, and if any hacking could be done on the software with a kernel extension, that can more easily spread to the entire system. This is the major reason that software with kernel extensions should be avoided.
Most AV software rely on kernel extensions, as they need internal system access to all files opened and closed in the system.
So Apple invented System Extensions, that will run in user space only, and not be a security problem.
Many of these AV solutions are still not ready, more than a year and a half later than the original announcement.
Are they really security products for Apple devices, if they can’t follow the pace in which Apple is releasing new products?
Apple is tough to develop software for. They announce a feature change, and they implement it. It’s not something that changes or go away (OK, no rule without exceptions). So whenever Apple announce that APIs (the calls in the programmers toolbox) are announced to be changed or discontinued, then it is time to handle that. Sooner rather than later.
An example is the release of the M1 Macs in the fall of 2020. Some software was ready with a native arm version very fast, and some is still not ready (almost half a year later). The developers that followed Apples announced changes continuously the past years can way more easily make the needed changes for M1 and then thoir app is native. So following Apples guidelines like this makes your apps better.
When Apple release a new OS version it also contains security updates, and often those will be described in the open, for everyone to abuse, at that exact moment of release. So maybe the device was insecure before, but after the OS release it is even more insecure. That makes delayed OS updates even more uninteresting.
Recommendation us to update to the latest, be part of the beta cycle if critical apps should be verified for compatibility, and plan and execute on the announced changes that Apple roll out.
Don’t put the security of your devices at risk, and make sure to not get too much behind in this technical race.
Remember this when evaluating all sorts of software, whether or not it is security solutions, VPN applications, internal developed apps, productivity apps or critical production apps.
So how do you get access to beta version, you ask?
Apple made in easily to be part of this. Make sure that you have an Apple business Manager (business.apple.com)or Apple School Manager (school.apple.com) account, and use an Apple ID from one of those to log in on this page:
On Mac there is also a Feedback Assistant app, where problems can be reported (but be aware, that Apple can take a long time for a reply). Apple will answer the inquiry (eventually), and if they recognize it as a bug, they will report back, when they think they have fixed it, so it can be tested.
It’s better to be prepared through the beta releases, than to get surprised when Apple actually make the final release and users can upgrade to a disaster. It is, however, not guaranteed that no surprises could occur, but it is the safest method available.
Some organizations have very critical workflows with iPads as part of the production workflow. In these circumstances a critical evaluation has to be done, and it could very well be well invested to follow the betas.
A pragmatic solution could be to delay software updates with 7 days for users, and let IT update right away, and let them test the new release (and maybe delay users updates even further if a problem is found).
In practice I would expect problems to be minor for most organizations. If one app is out that is rarely very critical, as it would work on another device etc. for the users. In these case I would not delay anything, but recommend IT to upgrade as soon as possible, and hope that not too many users have upgraded if a problem was found.