Please Don't File Duplicate Feature Requests for Swift

Chris Lattner, the creator of Swift, has recently asked developers to not intentionally file duplicate feature requests for Swift. The Swift team does not consider how many people have filed a request when prioritizing features, and processing duplicate requests take time away from development. However, he did encourage developers to always file bug reports, even if they think they might be duplicates, to ensure that no bugs are missed.

In my post arguing for message passing in Swift, I encouraged readers to file duplicate feature requests for the radars listed in that post. I have now updated that post to discourage duplicate feature requests. Please do not duplicate the radars in that post.

Third-party developers have often filed duplicate radars, at the encouragement of Apple engineers, as a way of voting on which bugs and feature requests are important to them. There have been public campaigns within the community to get developers to duplicate certain radars, like this campaign to support dynamic libraries and frameworks on iOS. (Apple announced framework support on iOS at WWDC 2014.)

Filing duplicates has always been inefficient. Those filing the radars have to take the time to describe the problem, and Apple employees need to read the radars and match them up to the correct duplicate. Many developers have asked Apple to open up the Radar system and allow them to vote directly on radars. The only response to this suggestion that I have ever heard from an Apple employee was that they understand that filing radars is not ideal for third-party developers, but that Apple needed Radar to remain somewhat opaque to non-employees.

After years of living with these limitations, filing radars, and talking with Apple employees, the third-party developer community has internalized the following two ideas about Radar.

1. If it’s not in a radar, Apple won’t work on it. Filing radars is difficult and time-consuming, but it’s the only option if you want Apple to change something.
2. Radars with more duplicates get more attention. Duplicates are how Apple knows how many people a radar is important to.

Although not filing duplicates is a change for the community, it’s important to honor Chris’s request. As anyone who has worked in a large organization knows, what works for one team may not work for another. Swift is very different than most of the other products Apple produces, and may require different development policies. Filing duplicate radars isn’t going to change how the team prioritizes features, and it reduces the time they have to work on the features you want in the language.

This does make filing radars even harder on third-party developers. Before, Radar abstracted away the fact that there are many diverse teams within Apple, and allowed developers to treat the company as if it was just one entity with uniform policies. I hope Apple will do something to clarify which teams want duplicate feature requests and which teams do not

In the meantime, please help to spread the word to the community that the Swift team doesn’t want intentionally duplicate feature requests. Filing duplicate radars is a well-engrained bit of institutional knowledge, and it’s going to require a lot of us blogging, tweeting and talking about it to change our behavior.