Swift manages to be technically open-source while not really being true to the idea of open-source. To me, it always seems as if somebody at Apple saw that companies like Microsoft going open source was good publicity and decided that they should do it now too, without really understanding what "open source" means.
Some examples of this IMHO include:
- While Swift itself is open-source, "Foundation" (which is something of a stdlib of Swift and provides many key pieces of functionality) is not open source - at least on macOS. There is a reimplementation of Foundation for Linux which is open source but, surprise, surprise, the two sometimes have different behaviour...
- Swift releases are weirdly coupled to XCode releases, a closed-source IDE. Moreover, while technically possible, most people on macOS don't install Swift on its own, but always through XCode, and the two are quite tightly coupled (you can technically change the toolchain, but it's quite an opaque setting IMHO). This leads to a lot of "I updated XCode and now the code is not working anymore" issues, especially with more junior developers.
- Tooling outside of XCode (itself not the greatest of IDE of all times...) is extremely ... limited. For example, XCTest's (the test framework's) console output is almost unreadable and there are actually (half-abandoned) third-party tools that try to parse it and format it nicely (while introducing tons of weird bugs), something that test frameworks for other languages can just do for free. The package manager has, I think, one maintainer, and is so underpowered that most iOS developers don't really use it yet (despite it now being a couple of years old). And in terms of editor/IDE support there is now technically a LSP implementation, but last I tried, I couldn't even manage to set it up properly.
- There is no clear roadmap or even mission statement for Swift. Many other languages try to be clear about where they're headed and also what kinds of things they don't want to support, but Swift development is this weird mixture between a) a "community process" that often just leads to very different parties bringing their own very special concepts, syntax sugar, etc. into the language development without there seeming to be any overarching idea of where this all is headed, and b) some things just seemingly being implemented because it's useful for some shiny Apple feature ("function builders" which is mainly meant to support SwiftUI and which many people have been very skeptical about). Meanwhile long-standing proposals like properly fixing generics ("Generics Manifesto") are being pushed back indefinitely. It seems to me sometimes that Swift developers are willing to let the community bikeshed on trivial matters (e.g. syntax sugar), but when it comes to more important, long-term concerns (should we implement function builders or rather invest in some more generally reusable macro-like / code generation feature), are being unilaterally decided without really consulting the community.
At the very least extensions of structural types, which I believe requires also variadic generics. Tuples are completely broken in Swift due to the fact that they're not Equatable - you can compare single tuples, since == is implemented for them, but you can't compare arrays of tuples. This makes some kinds of tests incredibly awkward to write and had lead my team to move away from tuples to nominal types a number of times.
Also, there are some annoying restrictions around existentials, and documentation of Generics and other advanced type machinery could be a lot better in general.
Some examples of this IMHO include:
- While Swift itself is open-source, "Foundation" (which is something of a stdlib of Swift and provides many key pieces of functionality) is not open source - at least on macOS. There is a reimplementation of Foundation for Linux which is open source but, surprise, surprise, the two sometimes have different behaviour...
- Swift releases are weirdly coupled to XCode releases, a closed-source IDE. Moreover, while technically possible, most people on macOS don't install Swift on its own, but always through XCode, and the two are quite tightly coupled (you can technically change the toolchain, but it's quite an opaque setting IMHO). This leads to a lot of "I updated XCode and now the code is not working anymore" issues, especially with more junior developers.
- Tooling outside of XCode (itself not the greatest of IDE of all times...) is extremely ... limited. For example, XCTest's (the test framework's) console output is almost unreadable and there are actually (half-abandoned) third-party tools that try to parse it and format it nicely (while introducing tons of weird bugs), something that test frameworks for other languages can just do for free. The package manager has, I think, one maintainer, and is so underpowered that most iOS developers don't really use it yet (despite it now being a couple of years old). And in terms of editor/IDE support there is now technically a LSP implementation, but last I tried, I couldn't even manage to set it up properly.
- There is no clear roadmap or even mission statement for Swift. Many other languages try to be clear about where they're headed and also what kinds of things they don't want to support, but Swift development is this weird mixture between a) a "community process" that often just leads to very different parties bringing their own very special concepts, syntax sugar, etc. into the language development without there seeming to be any overarching idea of where this all is headed, and b) some things just seemingly being implemented because it's useful for some shiny Apple feature ("function builders" which is mainly meant to support SwiftUI and which many people have been very skeptical about). Meanwhile long-standing proposals like properly fixing generics ("Generics Manifesto") are being pushed back indefinitely. It seems to me sometimes that Swift developers are willing to let the community bikeshed on trivial matters (e.g. syntax sugar), but when it comes to more important, long-term concerns (should we implement function builders or rather invest in some more generally reusable macro-like / code generation feature), are being unilaterally decided without really consulting the community.