Anyone who pays any attention at all to Apple is familiar with the company’s cyclical nature. In late spring, they have their big conference wherein they announce major updates to most, if not all of their various platforms. Apple then tells the world that these new versions will be available to the public in early fall. Finally, the company releases their updated operating systems in late September (or at latest mid-October.) The annual cycle lets Apple surprise and delight the world every year at WWDC while keeping their platforms moving forward, but more and more(and more and more), this adherence to the annual cycle seems to be a recipe for what I’ve been calling “unforced errors.” It’s a term that comes from sports, which the system dictionary accurately defines as:

A mistake in play that is attributed to one’s own mistake rather than to the skill or effort of one’s opponent

Take iCloud Folder Sharing as an example. While the feature was announced at WWDC in 2019 and expected to ship in September, it was pulled due to issues with reliability. Only now, six months later, did the feature finally ship in a point release.

Software being delayed is nothing new and I would argue not even an error. What makes the above an error is that iCloud Folder Sharing was given a release date that it seemingly could not possibly meet. What makes that error unforced is that while folder sharing was anticipated, there was no real pressure on Apple to announce the feature.¹ Apple didn’t have to announce iCloud Folder Sharing at WWDC last June and doing so set expectations that the feature was close to ready, which then risked its reputation when it wasn’t.

The obvious counter-argument is that the likely very smart people involved thought iCloud Folder Sharing was close to ready, and that its delay is more likely a consequence of some unforeseeable issue that required feedback from betas to unearth. That’s possible and if true only further illustrates the problem of strictly adhering to the annual cycle. Furthermore, iCloud Folder Sharing was just one of the numerous issues in Catalina (not to mention iOS 13) that seemed to be rushed to completion for the strict fall deadline.

I don’t even think the smart people involved need to knowingly underestimate the remaining work. In my experience unforced errors very often stem merely from being too optimistic. Product people are ambitious and engineers are confident, and nearly every one of them has underestimated at some point in their careers. Furthermore, by pre-announcing features at a big prestigious event four months prior to release, Apple effectively incentivizes this kind of optimism bias. Who wouldn’t want some feature they’ve been working on for months (if not years) to get its time at WWDC? No one.

Before this stricter annual cycle, Apple would present the next version of Mac OS X at Macworld or WWDC, then ship it after some truly indeterminate amount of months. I am sure they tried to make some deadline, but ultimately waited for the software to meet some definition of done-ness. I am not advocating that Apple go back to that good ol’ 18 to 24 month release cycle. I don’t think more time necessarily makes for higher quality software. Furthermore, longer cycles have less value in an era when software doesn’t literally have to ship. If anything, I think Apple should do the opposite — release features as they are truly ready on a more frequent cadence. To do this, I have three suggestions:

1. Only announce “complete” features at WWDC.
2. Release more features in point releases.
3. Lean into point release betas for features that require more feedback.

My definition of a “completed” feature is one that has no known issues that would block it from being released. The features announced at WWDC wouldn’t be “done”, rather the teams responsible for them would be primarily focused on handling edge cases discovered in the summer betas. Done-ness can be determine based on the amount and nature of issues and feedback.

Features that are either near completion or require more feedback to get an acceptable level of done-ness should just be slated for point releases. This has a few benefits.

Near-done features don’t have to wait a whole year to ship so teams involved will be less pressured or incentivized to release their work prematurely. Additionally, developer betas of point releases tend to be limited to actual developers so features can be tested more quietly with a smaller and more forgiving sample size than the summer betas of major releases, which are publicly scrutinized and prematurely installed by eager idiots (like me). Finally, there is less expectation that a feature has to ship in the beta of the point release where it was introduced.

I also believe that features released mid-cycle can still surprise and delight. iPad Cursor support was met with near unanimous delight when it magically showed up in March. Even features that do lose a bit of their surprise by requiring more feedback from betas can still delight. Imagine if a much more stable iCloud Folder Sharing just appeared in betas sometime in February. Those who have been waiting for the feature would have been totally jazzed instead of being reasonably trepidatious after a truly rocky summer.

I still love Apple’s annual cycle in that I look forward to WWDC and September every year, but I think strictly adhering to it has led to unforced errors. I have faith Apple can still surprise and delight at those events, while still being able to delight with more flexible feature releases outside of the annual cycle even when doing so inevitably comes at the expense of some surprise.