A few months ago the Swift on Server Workgroup invited you all to participate in a survey focused on the server-side of the Swift developer community.
We're incredibly thankful for the many hundreds of responses and detailed answers in some of the long-form open-ended questions. These surveys, help us understand the shape and needs of the community in ways other than through the usual online and in-person interactions, and help gain deeper insights on where the community is at, and where the SSWG need to be focusing on in the future. The input from the survey was taken into account when preparing this year's SSWG goals which were posted on the Swift blog.
What follows is a short summary of the survey, along with some light analysis.
Respondents
While most respondents to this survey self-described themselves as iOS/mobile developers (58%), a large chunk can be attributed to backend and full-stack developers (~35%). The other kinds of roles respondents described themselfes as were primarily managers, team leaders, but there was a nice amount of fairly low-level programming roles represented, including network, embedded or distributed system engineers.
Q: I would primarily desribe myself as:
The majority (40%) is already using Swift for hobby projects, and 29% are using it in production/professional capacity. Another 28% is not using Swift yet, but are interested in using it in the future.
When asked about next year's plans with regards to using Swift, 47% intend to use it in hobby/non-production projects (7% up), and 43% intend to use it in productionâwhich would mean an increase by 15%, which is excellent news on the pace of Swift adoption in production.
While most respondents "already know Swift and want to use it on the server" (73%), as many as 25% of all respondents may have prior server-side development experience, but are new to Swift!
We hope that that those interested in Swift will give it a try in the new year! There's never been a better time to start out with Swift than now, with the concurrency story maturing, C++ interop and the macros support opening up new horizons for what is possible with Swift.
Swift Language
A great thing in server-side development with Swift is that upgrading your dependencies and Swift versions can often be done pretty easily, as there is no "long tail" of end-user's with older operating systems to support. Organizations are free to update to latest versions, or even try nightly toolchains whenever they feel ready to do so.
This is reflected in the responses to the "Currently used Swift version" question in the survey:
Q: What Swift versions are you currently using for server-side applications?
At the time of collecting the survey data, Swift 5.10 was not released yet and 5.9 was under development, releasing nightly snapshots.
The vast majority of developers (49%) use the current (at time of posting the survey) Swift release, with the second dominant groupt (at 18%) actively using snapshot releases of the "next" version to verify their systems.
The server ecosystem generally supports actively three versions of Swift, the "current", and "two previous" versions. At the time of posting this survey in September, the current version was Swift 5.8, with the 5.7 and 5.6 releases still supported by the majority of SSWG libraries. The survey shows that the community is very good about moving forward along with releases, although some stragglers remain.
The snapshot usage may seem concerning, however we asked to clarify where the snapshot versions are used, and it is primarily in development (15% of total respondents), followed by CI (6%), usually by adding a secondary CI job testing with the upcoming Swift version. And lastly a bleeding-edge of 4% actually running snapshot releases in production. This shows a vibrant and eager to verify future features before they actually ship communityâwe're very thankful for the consistent feedback we receive from those (very) early adopters!
In general, the eagerness to update Swift and library versions in the server ecosystem is rather high, with most developers updating Swift as-soon-as-possible (41%), or just one month after release (24%):
Q: How often / early do you upgrade the Swift toolchain?
A similar pattern shows up in the update curve of libraries, with most developers updating libraries quickly:
Q: How often / early do you upgrade your project dependencies?
A significant potion of respondents did choose "Whenever I work on a project and notice updated dependencies." Which is perhaps an area we could improve upon, dormant non-updated project dependencies may pose security risks, and we should offer ways to notify developers about updates being available. There exist tools to automatically detect and update dependencies, but perhaps they are not well known in the community.
Concurrency Adoption
We also asked about utilized Swift Concurrency features, to judge how far along the adoption of this new and important paradigm is along in the server community.
Q: Are you using Swift's built-in concurrency features for server-side development (async/await, actors, tasks etc.)?
The vast majority (85%) already are using Swift Concurrency, including tasks, async await, actors, and even some respondents indicating their use of distributed actors! Another 13% are planning adoption soon. We were interested in the reasons why the 2% are not planning to adopt concurrency, and the reasons listed were aroud performance concerns, or difficulty in adopting Sendable, or managing blocking code. All of which we have made significant progress on during the work towards the next Swift release, so we hope to eventually get everyone on board here.
Some developers are still using Dispatch in tandem with Swift Concurrency primitives, but these usages are mostly driven by code accepding DispatchQueues or not having async-versions yet. It is nice to see though that the majority is able to get their daily work done already primarily using plain async/await rather than previous concurrency abstractions:
Q: If you are using concurrency and async code in development, are also you still using Future based APIs (NIO, PromiseKit, etc)?
And we believe the SSWG's and Swift team's continued work on making Swift Concurrency more prevasive and accessible to developers will help keep this trend going until most applications can rely on structured concurrency "all the way".
Tools and IDEs
Most respondents use Xcode (70%), however a large number also use VSCode (55%). Other tools like Sublime Text, Vim or others roughly received ~10% each. Since this was a multiple choice question it is expected that those numbers add up to more than 100%, and it is expected that a single developer may be using multiple editors at the same time.
When asked about future improvements in IDEs, the percentages reflected current usage, with Xcode and VSCode dominating the IDE's developers would like to see more improvements in.
Since VSCode and the other mentioned editors rely on sourcekit-lsp, we believe that this confirms our investments into Swift's language server protocol implementation.
Among tools questions, replies about a formatting tool also were interesting:
- 44% are not using any external formatting tool (relying on their editor),
- 28% are using nicklockwood/SwiftFormat,
- and another 24% are using the apple/swift-format.
Replies to "Would you like there to be a standard formatting tool for Swift code?" were also quite revealing, with a strong 84% replying favorably, and 11% remaining unsure, and only 4% against such standarization.
As well as a similar amount of support for standard formatting rules: 75% in support, 14% not sure, 11% against.
We are happy to report that progress has been made on the formatting front, and nightly toolchains now include apple/swift-format. Using it is entirely optional, but we do expect its availability with distributed toolchains will make it easier to adopt, and not rely on IDE specific formatters. We anticipate plenty future discussions about formatting rules and futher discussion with the community on this topic. This will fall beyond the scope of the SSWG though, and wider community discussion will surely take place. We are very happy about the high interest in this from the server community!
The linting landscape is primarily dominated by realm/SwiftLint, with 55% respondents using it in their projects. The reminder do not use linting tools, though a few replies indicated using apple/swift-format in linting mode.
Tools: Documentation
Documentation tooling is seeing great improvements, with DocC leading adoption and the documentation workgroup making tooling and documentation improvements more community driven and accessible. This is reflected in our survey with a strong 53% adoption of DocC, followed by 40% which do not use a documentation tool at all. Other documentation tools with significant user bases are swift-doc (8%), and Jazzy (4%).
As far as why developers have not adopted DocC yet, the majority of responses listed "time to learn" or needing more tutorials as an issue, followed by difficulty in setting it up, and easily generating static HTML that can be published.
Nevertheless, we think this shows a good trajectory of DocC adoption and the documentation workgroup's efforts.
Tools: Builds
Not unexpected, but SwiftPM is the primary tool developers use on the server side to build their projects, which shows in a strong 87% adoption rate in the survey:
Q: Do you use any tools besides SwiftPM for dependency management of server-side Swift projects?
SwiftPM plugins are listed as a great feature, yet sometimes still insufficient in power, which is why some developers still reach for custom scripts (2%). The CMake use is primarily for developers interoperating Swift with existing codebases which are primarily C or C++, and in a way this (2%) use of CMake is an interesting win for Swiftâit means adoption of Swift where previously memory-unsafe languages were used! CocoaPods use remains at around 7% and is primarily motivated by legacy reasons, such as an old codebase or using dependencies which do not support SwiftPM.
Libraries & Frameworks
As far as web frameworks go, Vapor has the most mind-share across respondents, with a large 78% percent user base. The relatively fresh Hummingbird being a smaller focused library than the very batteries-included Vapor is also seeing nice adoption at 12%, and Smoke as well as Kitura are seeing ~3% percent usage in this survey.
We also did ask for what libraries developers would like to see supported, and especially database or message queue libraries. The answers were incredibly varied, some mentioned already existing libraries like Redis, PostgresNIO, SQLiteNIO or Kafka etc.
Deployment and Platforms
As this was a server focused survey, when the survey asked questions about "platforms" this intended to measure server-side and non-Apple platform targets. The versions iOS, macOS and other Apple platforms are not being measured in this specific survey.
The vast majority of developers (78%) currently deploy to officially support platforms (Ubuntu, CentOS, AmazonLinux2 and Red Hat UBI, which you can learn about here: Platform Support). While this survey was mostly biased towards server-side systems, the number of Developers mentioning Windows as a target platform was at a reasonable 5%. For Windows users, we thought the recentpu published Swift, meet WinRT might be of interest.
When asked about future plans, where developers would want to deploy aplications, the majority of 64% indicated existing Linux systems, however there is a noticable rise in interest in WASI/Wasm (at around 16%), Windows (9%), as well as Android (7%). This survey was mostly intended for server-side applications, so it is a little unclear if those applications would truly be "server-side systems", or rather, Swift components of a larger application ecosystem written in Swift.
Deployments are usually made using Docker (53%), bare metal (30%) or other PaaS services (18%), generally reflecting similar industry-wide trends:
Q: How do you deploy your server-side Swift applications?
What should the server-ecosystem focus on improving?
The final question was an open-ended "what would you like to see improved in the server ecosystem?", and the replies were very varied and detailed. We would like to thank everyone for writing up all their thoughts here!
Overall the replies here could be distilled into a few focus areas:
- documentation and accessibility: especially with focus on on-boarding non-Apple developers, and help understanding the Swift ecosystem.
- increased adoption: many replies conveyed a strong desire for increase adoption, promotion and wider recognition of Swift as a viable server development language. Wider recognition also makes it easier to adopt and argue for a technology such as Swift in existing organizations, so this is definitely an area to focus on in the next year.
- improved tooling and IDE support: many of the respondents requested better IDE support, which we believe further investment in sourcekit-lsp should bring about. Especially while increasing adoption of Swift with an eye towards to developers outside of the Apple ecosystem, support of various build tools and IDEs will be crucial.
- performance: multiple respondents mentioned performance as a topic, however most were coming at it from different angles. Primarily it seems providing better guides, tools, and built-in metrics to diagnose and fix performance problems would be useful, especially as many developers new to Swift are not used to native performance tracing tools (such as perf etc.)
We have read through every single of the replies and taken them into account when planning the next yearâs goals for the SSWG. You can read more about the goals on the blog post on the Swift blog. We would again like to thank for all the detailed writeups and your time spent with the survey!
Thank you!
Last and not least, we would like to thank everyone who participated in the survey and shared your thoughts.
This has been a useful and informative new way to gather input from the community and we hope to repeat this in the future.
On behalf of the SSWG and the entire Swift community, thank you!
