When Swift went open source, Apple also open sourced the process by which Swift changes: the swift-evolution mailing list and corresponding git repository. This is huge because not only does the team share what they plan to do to Swift in the future, they’re also actively asking for feedback from and talking with the greater developer community about it.
Apple clearly wants Swift to be the programming language for the coming decades, not just for its own platforms, but for systems and application programming everywhere. And so to help it achieve this, Apple is open and listening for feedback on the mailing lists.
There is one problem with this though: the mailing list is self-selecting. Generally speaking, if you’re an active participant of the the swift-evolution list, you’re already quite bought in on Swift. This is generally a good thing, since being bought in on Swift means you care a lot about its future, and you have a lot of context from working with current Swift, too.
But by only getting suggestions and feedback about Swift’s evolution from those bought in on Swift, the Swift team is largely neglecting those who are not already on board with Swift. This includes those holding out with Objective C on Apple’s platforms, and those using different languages on other platforms too. These groups have largely no influence on Swift’s future.
Let’s take a recent example: the “Swiftification” of Cocoa APIs. The basic premise, “Cocoa, the Swift standard library, maybe even your own types and methods—it’s all about to change” might be good for Swift programmers, but I imagine stuff like this is the exact reason many Objective C programmers avoid Swift in the first place: they quite like how Objective C APIs read. Although the Swift team is actively asking for feedback, my guess is many Objective C developers’ reactions to this would be immediate rejection. And that sort of thing doesn’t bode well for providing feedback on swift-evolution. And thus, Swift becomes less likeable to these Objective C developers.
What to do? I’m not entirely sure, but the first thing that springs to mind isn’t a swift-evolution, but an apple-platforms-evolution list. If Apple eventually wants to get Objective C programmers using Swift, I think the discussions about Swift’s future needs to better include them.