From WWDC to Release: An Engineering Manager’s Guide

Getting the most out of the timeline between WWDC keynote and the launch of iOS 17 this Fall

One of the most highly anticipated events in any mobile teams calendar is Apples Worldwide Developers Conference (WWDC). With major releases of all Apple operating systems being announced (as well as the occasional hardware refresh or reveal), effectively planning for WWDC can enhance collaboration, foster team spirit, and empower developers to leverage new advancements in their work. This article will outline a few key strategies for engineering managers to make the most out of the timeline between the WWDC keynote and iOS 17 launch day, in the Fall.

Community

While previously 5,000 or so people could attend live, in person presentations spread over 5 days in California, WWDC has changed its format to a single day live event with an in-person cap at around 500. The rest of the week has moved from live presentations, to slick pre-recorded online-only sessions.

With little chance that your whole team will be able to attend the physical event, this is a great time for your team to connect in and watch the initial updates together as they are announced.

There are a couple of really important sessions that are great to watch together with your engineering team.

The keynote

The WWDC keynote is the flagship event that unveils Apple’s major announcements and sets the tone for the conference. As an engineering manager, consider turning the keynote into a community event by gathering your developer team to watch it together. This collective experience not only creates excitement but also inspires open discussion and brainstorming.

Encourage team members to share their insights, ideas, and thoughts on the potential implications of the announcements. This communal approach cultivates a sense of unity and shared purpose among the team. It also gives you some insight into any particular element a team member is jazzed about, which will be useful when allocating feature design and learning later on.

The State of the Union

The State of the Union session, held on the same day as the keynote, delves deeper into the technical details of the announcements. This is a must for any hands-on developer, so encourage your team to watch this session to gain an understanding of the high-level feature from a practical level.

Although these initial sessions are more of a summary of the announcements, these two events are going to give you the biggest indicator as to what the engineering scope could be for your app ahead of the Fall release of iOS 17.

Timetable

Prior to the keynote, Apple releases a timetable of the weeks sessions, these are given fake names to avoid any give aways to the announcements. Once the Keynote is out of the way, the real session names are published. Although you will likely have a reasonable idea on the content and importance of each session, I would encourage you to wait until after the State of the Union has completed to begin any planning. Once the State of the Union session is over, it’s time to review the session titles and descriptions, then prioritise topics that directly impact your team’s work. Create a shared document that the engineering team has access to and list out the session of interest with the appropriate links, I usually sort these into the follow categories for ease:

• New API features
• Swift
• UI (SwiftUI / UIKit)
• Dev Tools
• Performance / Debugging
• Accessibility

Continuous Learning

Depending on the quantity of the new features and the size of your team, look to allocate dedicated reoccurring training slots in your team members calendars (I actively encourage at least an hour per sprint in non WWDC times to enable to team space to continuously learn). I would advocate setting up a Slack channel solely for WWDC and encouraging each team member to contribute Tweet sized key takeaways from each session they watch (this also works in a Sprint ceremony format too). This helps to promote conversation as well as share key insights. This collaborative approach ensures that the team benefits from a broader knowledge base and avoids missing some key information.

Connecting, Communicating, and Aligning

With a host of new capabilities freshly announced, it's also great time to connect with the product / business side of your organisation. Every Org varies in their structure, but it’s the perfect time to engage and communicate new announcements to those that did not catch the keynote. Equally it’s just as important (if not more) to run through what the announcements mean in terms of technical feasibility. The period following WWDC often generates significant excitement about new features. However, it is important to note that some of these features may not necessarily be feasible for developers outside of Apple or for your specific application.

Since most product teams primarily rely on the Keynote for information, there is a chance that certain features or APIs might not have been highlighted as major announcements. Additionally, the Keynote tends to focus on specific use cases for new features, but the APIs and subsequent sessions can unveil additional opportunities or use cases that the broader business might not be aware of. The initial weeks following WWDC are crucial for establishing a strong feedback loop with the product team. This ensures that everyone involved gains a comprehensive understanding of both the potential possibilities and how these developments align with the product roadmap and resource planning.

Bugs or Features

With the keynote announcements out of the way and a release date a few months away, there are two main options to consider for a release strategy.

1. Fixing bugs on the current version: One approach is to address bugs in your existing app by building against the current version of iOS, but testing on the Beta OS. This does mean you are somewhat “kicking the can down the road” in terms of prolonging fixing some bugs, compiler errors, etc to when you do eventually build against the newer target OS. This will also mean you can’t take advantage of any new UI components or features.
2. Embracing the new version: Alternatively, you can begin a workstream to build using the new beta version of Xcode and develop against the new version of iOS. This means fixing compiler issues and warnings, but grants you the opportunity to take advantage of new UI components, features and APIs.

One advantage of shipping your app with new OS features on the launch day is that Apple often highlights apps that make use of the latest features and APIs.

Testing

With both a product and an engineering plan in place, it’s crucial to shift focus towards the practical aspects of the beta software.

Following the Keynote, beta versions of Xcode and iOS will become available. However, it’s important to exercise caution when it comes to installation. It is recommended to install the beta iOS solely on test devices, as this version may not be stable and could potentially break many of your apps. On the other hand, installing the beta version of Xcode is generally safe, as it can coexist and run alongside your existing version without causing conflicts.

Public Beta

Although the Beta’s are only available to enrolled developers, the general public can register for the Public Beta program. This introduces the risk that your existing application may not function correctly on members of this program and while this is a small number of people (relatively speaking) this should be your first port of call for testing and bug fixes. This should be done built on the current version of Xcode and ran on the Beta version of iOS and should be repeated for every Beta version of iOS.

• Note of caution here, before you go on a crusade to fix a bug, exercise caution and double-check within Apple developer forums and platforms like Stack Overflow to confirm whether the issue you encounter is a bug specific to your app, or an inherent flaw in the beta software itself. Additionally, consider the severity of the bug and the impact it has, as the user base affected by it will be relatively smaller. If you come across any bugs that are related to the operating system, it is highly encouraged to raise feedback otherwise you could end up seeing these bugs make their way to release.

Building for the new OS

With the team enthused and chomping at the bit to try out all the new and shiny things they have been learning about, here are some important initial tasks to address:

• New OS branch: This will be your new baseline branch for everything related to the new OS. This should be regularly updated from your develop / main branch right up to release, to ensure it doesn’t get stale.
• Address Build Warnings and Errors: Prioritise resolving any warnings or build errors in your app before diving into feature development or bug fixes. After addressing these issues, give the app an initial run-through and create tickets for any initial bugs you encounter. These changes should be included in a pull request (PR) to merge them into your new core branch.
• Pipeline Considerations: Take into account that in order to generate IPA files for the new build targets, the build machine must be running the Beta version of Xcode. Initially, it may be easier to perform a local build and archive for the initial test build while you set up the pipeline for the beta version.
• QA/QE Build: Produce a build specifically for Quality Assurance/Quality Engineering (QA/QE) and distribute it to them for initial testing and regression.
• Features: New features should follow your existing branching/QA strategy, but ensuring that your new core branch is your source of truth

Beta Timeline: Managing Releases and Ticketing

The beta timeline for iOS typically unfolds as follows:

1. Initial Developer Beta: The first beta is released exclusively to developers during the Keynote event.
2. Public Beta: In July, the public beta program opens, allowing non-developers to access and test the beta version.
3. Frequent Beta Releases: Between June and September, Apple releases frequent updates with new beta versions of iOS. The number of releases varies, typically ranging between 5 and 8, depending on the volume of bugs reported and fixed.
4. Release Cadence: While the exact timing of beta releases can vary, it is a good practice to assume a new release every two weeks. Therefore, it is recommended to create a ticket per Sprint to accommodate these anticipated releases.

By anticipating the regular release cycle and incorporating it into your project management approach, such as creating tickets per Sprint, you can effectively adapt to the evolving beta versions and ensure a streamlined development process.

Release

Following the regular cadence of beta releases and test cycles, it will help to ensure you are as ready as can be for hitting the Fall release. This approach ensures that your user base will experience a well-tested version of your app, leveraging the latest features and benefits offered by the new iOS version.

As the Fall release approaches, Apple typically sends out an email notification, usually a couple of weeks prior to the official public rollout of the new iOS version. This email advises developers to begin submitting their apps for review. This step marks an important milestone in the release process, as it initiates the final stages of preparing your app for distribution.

By fostering teamwork, continuous learning, and effective communication, your team can harness the latest advancements and create a polished app that takes full advantage of new features. With careful planning, bug fixing, and thorough testing, you’ll be on track for a successful launch and ensure your users have the best experience. As the Fall release draws near, keep an eye out for Apple’s notifications and take the final steps to get your app ready for distribution. Follow these guidelines, and you’ll lead your team to a successful WWDC-to-release journey, delivering an awesome product to your users.

Additional Tips for a Smooth Beta Experience

1. Keep your Operating System (OS) Updated: It is essential to ensure that your OS is up to date, as beta versions of Xcode may not work on older versions of macOS. Make sure you have the latest macOS installed to ensure compatibility.
2. Update Test Devices: Before downloading the first beta version, ensure that your test device is also up to date. Keeping your test device’s software updated prior to downloading betas helps ensure a seamless installation and testing process.
3. Explore Documentation and Release Notes: Take the time to thoroughly review the documentation and release notes provided by Apple for the beta versions. This will help you understand the new features, changes, and potential issues that you may encounter during development.
4. Test Compatibility with Third-Party Libraries and SDKs: Ensure that any third-party libraries or software development kits (SDKs) used in your app are compatible with the beta versions of iOS and Xcode. Update them if necessary or reach out to the respective developers for any updates or guidance.

Remember, working with beta software can introduce unexpected issues, so it’s essential to approach it with a diligent and exploratory mindset. Stay informed, stay connected with the developer community, and be prepared to adapt your development process as needed.