Each year in June, Apple previews the next major versions of iOS and iPadOS, along with updates to its other software platforms, at its World Wide Developers Conference (WWDC.) At this event, Apple announces and demonstrates a select number of headlining new features, and makes prerelease versions available to developers so they can test the new software and provide feedback before the public release in September.
This is important because when substantial feature additions and changes are made to operating systems as intricate as iOS and iPadOS, many bugs will also be introduced. This can include issues with how third-party apps and accessories interact with the operating system, making thorough testing by developers crucial.
Even if you’re not a developer, however, you may still be interested in testing the new software to check out the new features or see for yourself what’s improved and what needs work. In this guide, I will give an overview of how best to do this with as few headaches as possible, as well as how to give Apple high quality feedback. Note that as this guide is intended to give a broad overview of iOS and iPadOS beta testing, I won’t be going into detail about specific features or bugs in these operating systems.
A “Beta” is a piece of software whose features have been conceived and coded to a basic level of operation, but may have issues that can only be identified by a wider pool of testers from outside of the company who bring diverse experiences and use cases to the table. Thus, the more feedback Apple, or any software developer, receives during a beta testing period, the more stable and refined the public release will likely be.
A “Bug” is something in a piece of software that does not work as the user or developer expects, whereas a “feature” refers to a change that’s been intentionally implemented by the developer and is working as they expect it to. For you, as a user and tester, you should report anything you notice that doesn’t work as you expect, as even if a change is intentional, not all changes Apple makes are good, and they may need to hear from users to get a better idea of a given change’s real world ramifications.
Apple’s software development schedule
While Apple’s precise schedule and behaviors are always fluid, they generally stick to a basic pattern for continually refining iOS and iPadOS.
On the day of the WWDC keynote in June, the first developer betas of Apple’s software platforms are released or “Seeded.” As these betas are primarily intended for developers, they are largely intended for testing of third-party apps and accessories for compatibility, and thus many user-facing features may be unstable or may not work as expected.
As development progresses, Apple will seed new iterations or “Builds” of the software that resolve known issues and gradually improve its overall quality. Once they are confident that the software is stable enough for non-developers to test, they make it available to members of its public beta program. As public betas are intended for a wider pool of testers, software released through this channel is generally more mature and stable than that released exclusively to developers, however serious bugs may still be present. Once public testing has begun, builds that have been seeded to developers will typically become available to public testers either the same day or a day or two later, depending on the extent of known and discovered issues in the software, as well as its overall maturity.
Once the beta cycle is complete, usually in September, Apple will seed a release candidate (RC) to both developers and public testers. Barring any critical bugs, this will be the build that is released to the public. Once a version has completed beta testing and has been released to the public, it is referred to as the shipping version.
After a major version has been released to the public, subsequent updates will be released throughout the year to fix bugs and add minor features and enhancements. These updates will also go through a beta testing period for both developers and public testers, although it is usually shorter than the period for major versions. While not set in stone from year to year, planned minor updates are typically released in October, December, January, March, May, and July, rapping up in the middle of the beta cycle for the next major version.
Is iOS or iPadOS beta testing right for me?
As mentioned earlier, beta versions of iOS and iPadOS, or any piece of software for that matter, are often unstable with many bugs and unpredictable behaviors, and are thus not recommended to be used in production environments. Therefore, especially if you rely on your device for school, work, personal care, or other essential functions, you may want to install the beta on another device specifically designated for beta testing, or have a full and complete backup of your data in case a downgrade from the beta, which involves a full restore of your device, becomes necessary. More detailed instructions on how to downgrade to the shipping version of iOS and iPadOS are given later in this guide.
Important: After downgrading to the shipping version of iOS or iPadOS, restoring from an iCloud backup made with the beta might not work, in which case you must either restore your device from a local backup made before the beta was installed, or set it up as new and manually redownload apps and place your data from another location. For information on how to back up your device to your Mac, check out the Apple Support article “How to back up your iPhone, iPad, and iPod touch with your Mac,” or to back it up to a Windows PC, the Apple Support article “How to back up your iPhone, iPad, or iPod touch with iTunes on your PC.”
Installing the beta
Obtaining an iOS or iPadOS beta involves signing up for either the developer or public beta program, after which an option will appear in Settings > General > Software update to install updates from that channel.
Before installing the beta, verify that your device is supported by the new version of iOS or iPadOS. Apple’s preview page for new versions, accessible after the WWDC keynote has ended, lists which device models are supported by the new version. Once you’ve verified that your device is supported, make sure it’s running the latest shipping version of iOS or iPadOS by going to Settings > General > Software update, and installing any updates if necessary.
Then, go to either developer.apple.com, to obtain the developer beta, or beta.apple.com, to obtain the public beta. You’ll then be prompted to sign in with your Apple ID and agree to a license agreement. After you’ve signed up, go to Settings > General > Software update > beta updates, and select the beta you signed up for. You can then go back one level in Settings, and the beta should appear like any other update that you can download and install.
Once beta updates have been turned on, Feedback Assistant will become visible on your Home Screen. In addition to being the portal for testers to report feedback to Apple, Feedback Assistant also contains release notes that list new features, changes, and new and resolved issues in the current beta build. Therefore, you may wish to review these notes before installing the beta, however not all possible issues, changes, and fixes will be documented.
Using the beta and reporting feedback
Now that you’ve installed the beta, it’s time to put it through its paces. Generally, when testing an iOS or iPadOS beta, you can get the best results by attempting to mimic your workflow (minus any critical work) to determine what’s improved, what could be better, and what is broken.
Especially in the early days of a beta cycle, you will likely find many things that don’t work as expected, or changes that simply baffle you, all things you should report to Apple using Feedback Assistant. If you have questions about something you discover in the beta, or are unsure how to clearly describe a bug or suggestion, you can post to the AppleVis forum for help. Ultimately, however, while this may help you understand a feature or describe a bug, reporting your findings directly to Apple provides the best chance that they will be seen and acted upon. Also, because Apple is more likely to prioritize and address bugs and suggestions if they receive a large number of similar reports, you may want to mention on the forum that you reported something, how you did so, and encourage others who think something isn’t right or could be better to do the same.
When submitting a report via Feedback Assistant, you’re asked a series of questions that, along with relevant diagnostic information that is collected and sent automatically as part of the report, should hopefully explain the bug or suggestion to Apple. In addition, including a screen recording can be helpful when reporting a bug, as Apple can see the bug occurring and how it can be reproduced. To do this, first go to Settings > Control Center and add the “Screen recording” button. Then whenever you want to make a recording, double-tap this button, reproduce the bug, and double-tap the “Screen recording in progress” status bar item to stop the recording; it will then be saved to your photo library.
Note: For best results, you should make sure Screen Curtain is off before starting your recording, and keep VoiceOver at a comfortable volume and speech rate. Also, to protect your privacy, screen recordings should not contain sensitive information, as they are viewable by a large number of people within Apple.
As mentioned previously, Feedback Assistant, also known as Apple Feedback, is the app used for reporting bugs and suggestions, and exchanging information about such reports with Apple. It is visible on any iOS or iPadOS device with beta updates turned on, and for added convenience, the button to compose a new report can be added to Control Center. The layout is similar to that of the Mail app; double-tap a folder or report within a folder to view its contents, and go back using the back button or two-finger scrub gesture.
To create a report, either use the Control Center shortcut mentioned earlier, or open Feedback Assistant manually, double-tap the Compose button, and select “iOS and iPadOS.” Below I explain how best to answer some of the things you may be asked, however the specific prompts you see will depend on the nature of your report.
- Problem area: This is where in the operating system the problem occurs. Generally, if you’re reporting a bug with VoiceOver itself, like speech failing or a feature not working as expected, you should select “Accessibility” as the problem area. However, if you’re reporting an accessibility issue within a specific app, like an unlabeled button, you should select that app as the problem area. If you’re reporting an issue in a third-party app, you should also contact that app’s developer to make them aware of the issue.
- Title: This is a short description, usually one sentence in length, that summarizes the report. An example of a title could be something like “VoiceOver crashes when attempting to [do something],” “[something] is sometimes [what it is],” or “the button to [do something] lacks an accessibility label.” If you’re reporting an unlabeled element whose purpose you don’t know, you could title your report something like “Unlabeled button in [app or context within app].”
- Type: This is a categorization of the report, such as incorrect/unexpected behavior, application crash, application slow/unresponsive, or suggestion. Note that a “Crash” is when the open app quits unexpectedly and returns you to the Home Screen. When VoiceOver crashes, it should immediately restart itself and announce “VoiceOver on” however if it remains silent, this should definitely be reported.
- Description: This is where you describe the bug or suggestion in more detail. Below I list some tips to help create a good description:
- If reporting a bug, describe what you expect to happen in that situation versus what actually happens, as well as steps to reproduce the behavior. If the bug occurs intermittently or inconsistently with no clear cause, mention this in the description and if not asked in other prompts, include the date and time the bug last occurred. Knowing the time an intermittent bug last occurred can help engineers narrow their search of your device’s diagnostic information, increasing the chances that the problem will be effectively identified and addressed.
- If reporting an accessibility bug and it hasn’t been asked in other prompts, information such as the voice or synthesizer in use, presence of voice assets for more than one language, and information about third-party devices in use, like keyboards and braille displays, may be helpful to include in the description.
- If reporting a suggestion, describe the current behavior, where it falls short in your use case, and how your suggestion would make it easier or more intuitive.
To attach a screen recording or other file to your report, Double-tap “Add attachment,” select “photo or video” to attach a screen recording, or “files” to select other files, double-tap the items you want to attach, then double-tap Add. When you’re ready to submit the report, double-tap the Submit button at the top right of the screen.
After your report has been submitted, Apple may request additional information or respond to you if they think a bug has been fixed or suggestion has been taken into account, however as they receive a large number of reports, they can’t respond to every one individually. Generally if Apple responds to a report you submitted, you’ll receive an email notifying you of the message, which you can then view in the “Requests” folder in Feedback Assistant. Once a bug you reported has been fixed, you should let Apple know by opening the report in Feedback Assistant, double-tapping the Actions button, and then double-tapping “Close feedback” in the context menu.
Downgrading to the shipping version
If you find a bug too disruptive to deal with and want to downgrade to the shipping version, you must put your device into Recovery mode, connect it to a computer, and restore it to factory settings. To do this:
- Disable Find My on your device by going to Settings > [your name] > Find My, and Turing off the “Find My” toggle.
- Connect your device to your computer and if it is a Windows PC, open iTunes if it doesn’t open automatically.
Put your device in Recovery mode:
- On iPhones and iPads without a Home button, press and quickly release the volume up button, followed by the volume down button, and then hold down the Side or Top button until a dialog appears on the computer acknowledging that the device is in Recovery mode.
- On iPads with a Home button, press and hold the Home and Sleep/Wake buttons until a dialog appears on the computer acknowledging that the device is in recovery mode.
- In the dialog, click Restore and follow the onscreen instructions to restore the device, which typically involves clicking through a read me, agreeing to a license agreement, and waiting for the restore image to download and install. Note that If it takes more than 15 minutes to download the restore image, your device will exit Recovery mode. If this happens, wait for the download to finish, put your device back in Recovery mode, and click Restore in the dialog; the downloaded iOS or iPadOS restore image should then begin installing immediately.
- Once the restore process has completed, follow the onscreen instructions on your device to set it up as if it was new from the factory.
As I’ve hopefully articulated in this guide, and as you’ll likely see in your own experience, beta testing can be both an incredibly frustrating and rewarding activity. When testing iOS and iPadOS betas, you witness firsthand Apple’s most questionable design decisions and spectacular coding errors. Conversely, as the beta cycle progresses, you may be able to see how bugs you’ve reported have been fixed or things you’ve suggested have been implemented. More information can be found on Apple’s Developer Program website, Apple’s Beta Program website, and the AppleVis forum, and if you have any questions or believe any of the information in this guide is inaccurate, sound off in the comments.