Apple's next operating systems: How and why to test them now

We say it every year at this time: Now that Apple’s beta software programs for its next operating systems are open, it’s time for you as an Apple admin to begin testing them. The earlier you test, the more time you give Apple to fix the problems you report.

The reason is simple: You need to evaluate a new OS before deploying it widely, so you know how well your existing technical infrastructure will get along with it.

But it’s one thing to know you need to test and another to get that testing done. Here are a few guidelines to ensure that you’ll be ready when those OSes ship in a couple of months.

The next major versions of operating systems for all Apple platforms are iOS 27, iPadOS 27, macOS 27 Golden Gate, tvOS 27, visionOS 27, and watchOS 27. The final versions of these new operating systems won’t actually ship for customers until sometime this fall.

Getting access to prerelease operating systems

First of all, Apple has several programs to distribute beta versions of its software. For all of them, in return for letting you test-drive those new versions, Apple requests that you provide feedback to let them know what problems you run into so they can fix them for future releases.

If you have access to a Managed Apple Account (formerly known as a Managed Apple ID) in your organization’s Apple School Manager or Apple Business, go directly to AppleSeed for IT and sign in with your Managed Apple Account. That’s probably the right program for most IT professionals and technology managers. If your organization is already enrolled with Apple School Manager or Apple Business, you automatically have access to it.

AppleSeed for IT is specifically designed for IT admins who need to test new versions of Apple beta software in managed environments. Participating in AppleSeed is the best way to prepare your organization for success when the latest OSes are released.

AppleSeed for IT provides:

• Access to prerelease software: AppleSeed for IT lets you test operating systems and some Apple apps in your organization’s environment before they’re released.
• Detailed test plans and documentation: Apple supplies test plans—including regression and new-feature tests—to help you evaluate the compatibility of prerelease software with your current environment.
• Dedicated review queue: When you submit feedback through AppleSeed for IT, it’s funneled to a dedicated review queue to ensure that bug submissions and enhancement requests reach the right people at Apple as soon as possible.
• Discussion forums: When you join AppleSeed for IT, you gain access to its exclusive discussion forums. These are great places to post questions, help other participants, and discuss other IT topics.
• Debug profiles: In addition to the debug profiles available to everyone on the Apple Developer website, AppleSeed for IT occasionally offers additional debug profiles for specific technologies on which they would like to focus testing.

To learn more about AppleSeed for IT and to find out how to access these services and tools, go to the AppleSeed site, sign in with your Managed Apple Account, and agree to the terms and conditions.

According to the terms and conditions, you should not share software you download from AppleSeed with anyone else—even in your organization. The best way to have others participate in testing is to have them sign in and download the software using their own Managed Apple Accounts. (More on that in a moment.)

By default, anyone in your organization who has a Managed Apple Account can participate (except for those with a Student role under Apple School Manager). But you can control that; check out the Apple Support article, Customize user access to apps and services using Apple Business. It’s pretty easy to configure whether people can use their Managed Apple Account to access content from Apple Developer and from AppleSeed for IT.

Speaking of non-IT admins accessing beta software, here’s a heads-up that individuals in your organization might sign up for the Apple Beta Software Program without your knowledge. It lets general users test software before the official release. Anyone can sign up at beta.apple.com; all they need to provide is a (personal) Apple Account. Generally, software updates in this program are less frequent than in others.

Apple also offers programs for developers, who are more interested in testing the apps that they develop in the new operating systems. And for organizations that need to test apps that they build for use in-house, there’s the Apple Developer Enterprise Program.

Finally, you might also see references to a legacy program, AppleSeed (not to be confused with AppleSeed for IT), that lets customers test beta software to provide Apple with functionality feedback. AppleSeed was an invitation-only program.

Even though it’s an old resource by now, Apple has a great video, Discover AppleSeed for IT and Managed Software Updates, that explains AppleSeed for IT in more detail.

One last tip about AppleSeed for IT: it’s pretty common to mistakenly enter the URL beta.apple.com/it or appleseed.apple.com/it - but these open the Apple Public Beta site—in Italian—instead of the AppleSeed for IT site. Fortunatamente, that page in Italian displays a banner in English near the top of that page asking if you really meant to go to beta.apple.com/for-it with a link.

Installing Beta Software

After you enroll in the appropriate beta program, there are two main ways to get a device upgraded to the prelease version of the OS, depending on the platform:

• Enroll a device into a beta program then use Software Update settings
• Use an ipsw file to erase the device and restore a beta version of the OS

Using Software Update Settings

For the Software Update settings path, first, enroll your device: sign in to iCloud with either:

• your Managed Apple Account that you use to sign in to Apple School Manager, Apple Business, or the Apple Developer site; or
• your Apple Account that you use to sign in to the Apple Developer or the Apple Public Beta site

After the device is enrolled, the next step depends on the platform:

• For Mac: Open System Settings > General > Software Update, then click the info (i) button next to Beta Updates.
• For iPhone, iPad, and Apple Vision Pro: Open Settings > General > Software Update > Beta Updates.
• For Apple TV: Open Settings > System > Software Updates > Beta Updates.
• For Apple Watch: On your enrolled iPhone, open the Watch app, and open General > Software Update > Beta Updates.

From here, choose the Developer Beta for the upcoming operating system for the device. This will allow you to install the latest beta over the air. Subsequent betas will be available on the device when Apple releases them.

If your device management service supports it, you can automatically enroll devices into a beta program, and skip the requirement of signing in to iCloud on the device. Apple allows a device management service to automatically enroll supported iPhone, iPad, and Mac devices during Setup Assistant (if using Automated Device Enrollment). And to automatically enroll supervised devices at any point. The feature also allows you to unenroll iPhone and iPad devices from the beta program. Iru will add support for this feature in an upcoming release.

Using Apple Configurator

The second method allows you to test on a completely clean system (i.e. one with nothing but the current OS on it). Download the appropriate ipsw file from Apple, then use Apple Configurator to erase the device and install the beta version of the OS. We’ve had the best results by installing the latest beta version of macOS or Xcode on the Mac that you use for Apple Configurator for this task. Although the ipsw method isn’t valid for an Intel-based Mac, macOS 27 Golden Gate is the first version of macOS that drops support for Intel-based Mac, so you’re golden.

Whichever operating system you’re testing, don’t install it on production Apple devices.

Planning your testing

What’s the best way to test a prerelease OS? The answer obviously depends on your specific circumstances: the kinds and quantity of Apple hardware you manage, the apps and services your organization uses, how much time you have, and so on. But here are some general guidelines to think through.

1) Use multiple platforms

Before you do any testing, you need to settle on a test platform—or, more accurately, platforms. Our recommendation: Do it in stages.

Start by installing the new OS on a clean, erased device. These systems should be dedicated to testing, not in production use. As much as possible, configure the test platform as you would any new production computer or device, with your standard Wi-Fi and other settings, then run it through your suite of tests.

That done, try upgrading a test system that’s currently running the last-generation OS: from macOS 26 Tahoe to macOS 27 Golden Gate on the Mac, from iOS or iPadOS 26 to 27 on iPhone or iPad. Once again, configure these devices as you would a production system, then run them through your test suite. Make use of the AppleSeed for IT test plans.

In the past, many admins used virtual machines (VMs) to test beta OSes. But we want to caution that VMs have their limits and don’t always produce complete and reliable results. We recommend not skipping using actual hardware in your testing.

2) Start with the OS itself

You want to take a tiered approach for each platform, starting with the new operating system itself. Does it install? Does it work? Can you connect to local networks (wired and wireless) and the internet? Does Bluetooth work?

If the new OS doesn’t work on a clean Mac, there might be a known issue on the Apple side. Check the release notes on AppleSeed for IT to see if anything there might explain the problem, then provide feedback (see below).

3) Test Your Apps

Once you are comfortable with the operating system’s fundamentals, it’s time to test applications. What are your organization’s five most critical user-facing tools? Focus on productivity apps—the Adobe Creative suite, for example—on which your organization relies. Avoid email and calendaring for now, as they depend on back-end infrastructure, which you’ll test next.

Install these apps on your test hardware and run them through their paces. Does the app install and launch under the new OS? Does it work as you expect? If either of those answers is no, contact the developer of the app in question and let them know. File feedback with Apple, as well.

4) Check your infrastructure

Next, test the more complex apps and services that your organization relies on.

Can the test system successfully connect to your email services? If you use Exchange, for example, does it function as expected? What about other cloud services, such as your VPN and your identity provider? Do your security tools work? Security apps, in particular, frequently break with new operating systems.

One special component of that infrastructure that you should test: Your device management service solution. Does the test device with the beta OS enroll correctly? Try deploying a current configuration. Does it all work?

Generally, whatever worked with the previous operating system should work with the upcoming one unless a particular feature has been intentionally removed. If that isn’t the case, you should report the unexpected behavior to Apple and your device management service vendor. Most such vendors don’t make functionality that is new to the upcoming OSes available until Apple officially ships those operating systems. That can make it difficult to test new features. But remember most device management services allow you to distribute a custom profile that you craft with a tool like iMazing Profile Editor.

Test plans from Apple

One great resource for test plans is Apple itself. The company supplies sample plans as part of its AppleSeed for IT program. On the AppleSeed site, click Resources, then navigate to the Test Plans & Documentation section.

Apple Platform Testing Template

There is a zipped Excel spreadsheet containing outlines for a wide variety of testing scenarios, from the deployment and management of Apple devices to office infrastructure. The sheet includes test cases that fill in some of the details for you; they’re incredibly thorough. New plans often appear later in the beta cycle, so it is worth checking this site periodically.

You will likely find items in Apple’s plans you’ve never even considered testing. Even if you don’t need to test the specific scenarios or conditions covered by Apple’s test plans, they’re excellent templates to use in planning tests of your own.

How much testing should you do?

If your time or resources are limited, keep your plan simple: Test the new OS to see whether it installs correctly on your hardware. See if you can create a new user and enroll in your device management service. If you can take care of those basics, that might be enough for now.

We can’t stress enough how important it is to do as much testing as you can before you roll out a new OS to your users. But if you absolutely don’t have the time or resources for even the most minimal testing program, the fallback is to wait for the OS to be released to the public. When it is, install it on one Mac, and see what (if anything) breaks. In the meantime, keep an eye on public forums to see what your peers are saying. And in Mac Admins Slack, check out the pinned item in the #appleseed channel for instructions on joining a more private channel.

Ideally, you wouldn’t do the testing by yourself. If possible, it’s wise to assemble a testing group—including trusted end-users as well as members of your IT team—to download and test the software themselves. 

At the same time, it’s wise to send a message to your organization as a whole warning anyone outside your chosen testing group against downloading pre-release software independently. Your device management solution may be able to help with that, too. Here’s how to restrict access to beta OS releases in Iru.

Providing feedback

While your main goal of prerelease testing is to check the forthcoming operating systems against your existing hardware and software, there’s another important one: Providing feedback to Apple. For that, your best bet is AppleSeed for IT.

When to submit feedback? Whenever an app or service you’ve used in the past doesn’t work or behaves oddly—crashing, hanging, or being so slow as to be unusable—under the new OS.

Feedback provided to Apple and app vendors earlier in the beta cycle is more valuable than feedback provided later. It gives Apple and ISVs more time to diagnose and address problems, making it more likely those problems won’t be present in the shipping operating system.

You submit that feedback to Apple through the Feedback Assistant app that’s built into the prerelease OSes. Sign in to Feedback Assistant using the same Managed Apple Account you use to sign in to AppleSeed for IT. File feedback for your organization (rather than Personal) to ensure it gets routed to the AppleSeed for IT triage team. You should be prepared to submit device logs along with any feedback you provide. Along with your description of the problem and the time you encountered it, this gives Apple’s software engineers a starting point for diagnosing the problem.

When you file feedback, make it useful. The more information you can provide, the more likely your bug will get fixed fast and won’t require a lot of follow-up. As a start, include a detailed, descriptive title when filing the report, following the rubrics “[[service or app]] [[is doing this weird thing]]” or “[[can’t do this]] in [[service or app]].” Screenshots are also really helpful. For more, see Apple’s article on how to file great bug reports. If at all possible, for the question, “Which area are you seeing an issue with,” choose one of the existing options, and never choose “Something else not on this list” (if nothing in the list fits exactly, you’re managing the device, so choose Device Management).

If the problem you’ve identified involves third-party software, make sure to use that vendor’s feedback mechanism as well. It can be difficult at this stage to tell whether a problem is with the operating system or the app, so you’re better off filing a report with both Apple and the ISV.

As mentioned above, if you file feedback using your organization credentials, it will be routed to a special AppleSeed for IT queue. That means your bug submissions and enhancement requests will go to people at Apple who can actually do something about them.

If you do submit an issue, note the Feedback ID number you receive; it will be used in any follow-up between you and Apple. You can review the feedback you’ve filed or drafted in Feedback Assistant and on the AppleSeed website. Apple will often ask for additional information. These conversations will happen in Feedback Assistant. Your prompt response to their questions makes it more likely that issues can be addressed before release.

One thing to keep in mind when considering whether to file feedback is that when you do so, you’re helping yourself and the community of Apple admins and users. Multiple reports of a problem may help Apple prioritize one issue over another. You may find an issue that another admin didn’t but which will affect them later. Apple has these pre-release periods both to give customers time to react and adapt to changes and to ensure software quality. Your feedback is critical to the company’s efforts.

One final note: Just because this is the beta season for Apple’s next generation of operating systems doesn’t mean this is the only time you should be testing upcoming releases. Apple is releasing updates to its OSes year-round. You should make testing them before deploying them part of your regular routine.

About Iru

By testing betas and leveraging a device management service, you can ensure your organization’s transition to the new operating systems is smooth. With powerful features like zero-touch deployment, one-click compliance, threat detection, vulnerability response, offline remediation, passwordless identity, and compliance automation, Iru has everything you need to enroll, configure, and secure your devices, and prove it.