All you need to know to shorten iOS/iPadOS deployment projects

iOS/iPadOS-based devices are some of the most secure smartphones and tablets available to consumers. Apple manufactures their own hardware, providing a tight integration with the underlying operating system that runs on the device – also developed by Apple – for the customized, secure experience users have come to expect from Apple hardware and software.

Apple is also known for its innovative new features and forward-thinking approach to how users work and play. This is an underlying principle that continues to this very day, as evidenced by each new device and its accompanying software, which Apple releases on an annual cadence to much fanfare for the estimated billions of iOS/iPadOS users across multiple industries, worldwide.

With so very many devices in use by organizations across the globe – most with specific business needs that see Apple devices as a cornerstone to productivity – it comes as no surprise to end-users and management how integral these devices are to business operations.

IT and Security teams understand this, particularly from the device management and endpoint security perspectives. New operating system updates often include fixes to known security issues. Additionally, new features may be included, allowing users to work smarter, not harder. Unfortunately, other issues may lurk within new, untested updates that may be largely unknown to many users outside IT.

By updating devices prematurely, myriad issues ranging from introducing vulnerabilities, device instability, incompatibility with existing applications and services and/or lowered device performance can be introduced – all of which provide a less than optimal experience at best to a downright insecure and unusable device at worst.

Thankfully, there are several checklist items we’ve included below which can help organizations guide themselves in not only becoming familiar with each new update prior to being released to the general public but also to thoroughly test it against their unique needs and software requirements, and extensively vet security protocols. Doing so will ensure devices receiving the update continue operating efficiently, that data remains protected and provide users the signature experience they’ve come to expect from Apple mobile devices.

We have the facts and we’re voting YES!

First place to start is with the new update itself. After all, how can we possibly formulate a plan if we don’t know anything about what we’re trying to deploy? Which devices will it support, what are the new features, how big is the file size of the new update and what, if any, issues are currently known/features have been modified or otherwise deprecated? These are just some of the questions IT should be familiar with on the road to developing an iOS deployment plan.

Silly question: How can we know the answer to any of these if the update hasn’t been released yet? Not a silly question and luckily, one that has a simple answer. Enter Appleseed, Apple’s beta testing portal aimed at businesses of all types and sizes. The free-to-register service requires nothing more than a valid Apple ID linked to your organization in order to facilitate access to the latest versions of iOS/iPadOS/tvOS, well, all the OSes. It also provides documentation directly from Apple relating to release notes for each version, known bugs/issues that exist and deployment guidance to review when deciding how to best proceed forward with the update process for your entire mobile fleet.

By joining Appleseed, you will not only receive access to all builds of the latest betas but also have access to downloads of the latest first-party software and certificates signed by Apple, which are uploaded to Jamf Pro, allowing centralized management and deployment of beta software across devices earmarked for testing. Also, you’ll gain the ability to file optional reports with Apple to alert them of bugs and other issues common to pre-production software for remediation in future builds.

Know thyself

In this case, knowing thyself is less about you – the IT member – and more about the environment and devices, how they both fit into the grander infrastructure, governance and company policies. In simplest terms, perform an inventory on all your devices to gain insight into what types of equipment your organization has, obtain visibility into the types of applications deployed and their versions, the types of configurations, security settings and policies configured for devices and how they align to company policies and compliance regulations, if applicable.

Obtaining this detailed information is imperative to the lifeblood of the testing process. Because, without this data, how will you know what to test against, or more importantly, quantify the results of your test when there’s no baseline for comparison? For example, each recent iOS update has been known to limit which devices will be able to run the new update. If your organization didn’t assess the hardware versions of its devices, you could conceivably jump through all the required hoops to develop a rock-solid deployment plan…yet, failing to realize that the devices in your fleet do not meet the minimum requirements, such a plan would never succeed as the devices would simply reject the install commands each time they’re run. The objective here is to maximize the time available to plan, test and remediate issues detected so that when the production deployment occurs, risk and errors can be largely mitigated or kept to a minimum resulting in a smooth process for all stakeholders.

Testing, testing, 1-2, 1-2-3

Armed with our inventory data, detailed specifications of the update and our testing devices with the beta profile installed, we are now ready to perform the update process and test our company’s apps, settings and configurations for any anomalies.

Pro Tip: Test everything! Don’t leave anything out as it will only serve to potentially haunt your deployment somewhere down the line. If your organization works with developers to create custom applications, they should already have an Apple Developer account – if not – they can sign up for one and test all custom apps against the latest beta update to ensure that apps continue to work as intended.

It is often a good practice to test iteratively, with feedback provided by other departments and a cross-section of the user base. This feedback proves itself invaluable to IT and Security staff, plus experience has shown that the day-to-day users are most likely to find the kinks in the chainmail sooner, allowing a proactive approach to resolving potential issues before production deployment occurs and the problems of a few spiral into the problems of the many.

“You’re gonna need a bigger boat!”

As Brody remarked after getting his first, up-close look at the massive shark in Jaws. This analogy speaks to the possibility that issues will arise, some larger and more complex to resolve than others, but nonetheless should be documented for posterity and to aid in tackling each problem.

The boat analogy also refers to the potentiality that, given the update’s “newness” relative to its beta status, issues that may present themselves during testing may not be so cut and dry to resolve. This is especially true when the issue(s) stem from applications that do not yet support or have not had their code optimized for the new update. In these cases, working directly with the developer may yield the best results. If only to be provided an estimated release date for when certain apps will be updated to support the latest iOS/iPadOS.

In other instances, your IT department may be asked to work directly with the developer and their technical support team to identify the root causes of issues, leading (hopefully) to a timely resolution. In any case, when testing is performed early enough, organizations are provided ample time to find alternatives for unresolvable issues or perform risk assessments to determine the best path for the organization to take.

If no issues are detected, then good on you! But before toasting to your collective awesomeness, bear in mind that these tests are being performed on beta software – often, several different versions of betas are developed before the final, or gold code is developed for the final release. Through each iteration, many things can and often do change, so be vigilant in testing against each version for the best possible outcome.

Si vis pacem, para bellum

The Latin translation above translates as, “If you want peace, prepare for war.” This doesn’t infer that an iOS enterprise deployment plan equates to war in any shape, but rather to consider all possible pain points that could endanger the success of deploying updates and to work iteratively to resolve them or mitigate the risk they pose. After all, isn’t it better to be fully prepared and not require the use of those resources than to require resources but not be able to obtain them?

The deployment plan represents the sum of the inventory, research and testing work performed in the previous phases. Based on that data captured and the test findings, IT will have clear indication as to which devices will be supported by the latest iOS/iPadOS update, what applications are compatible (and not compatible) and how these devices will perform during and after deployment. Also, consider all changes that need to be made to Jamf Pro to accommodate new features, enhancing security and concerns regarding complying with regulations.

Care should be taken to ensure that the plan itself scales according to demand on resources, related to contention due to many devices making requests. Additional considerations should take into account the Internet connections used by smartphones and tablets, as larger bandwidth connections, like Wi-Fi, typically offer faster download speeds and a better overall upgrade experience compared to cellular connections which contend with network congestion and slower speeds due to larger numbers of users communicating over cell towers and signal strength respectively.

Appetite for Destruction

So, the deployment plan was created based on the data collected and findings of the tests performed. It was executed to the tee…and something (or multiple things) unaccounted for still derailed the deployment from the plan. It’s okay, it happens to the best of us as personified in the Robert Burns quote, “the best-laid plans of mice and men often go awry.”

This is not to expose doom and gloom, but rather to reach the understanding – with some anticipation sprinkled in – that oftentimes, issues occur that one cannot foretell regardless of how much preparation is done. With that said, developing a subsequent contingency plan to address any unforeseen issues that may arise during deployment, providing welcome solace to users and management alike by permitting a rollback to the previous OS version that was stable and compatible with all device and security settings, and apps and services. This type of plan also builds in some leeway for IT (along with related departments and vendor partners) to develop a resolution to address the unforeseen issue, before proceeding with re-testing the solution and moving forward with deployment plan 2.0.

Your users and their ability to continue to be productive in light of deployment woes will thank you!