Crowdfunding world domination

The Core Team believes that great cross-platform support remains a critical aspect of Swift’s charter and long-term success. This goal encompasses a variety of things, including:

  • An excellent core implementation of the language that works cross-platform.

  • High-quality high-level tooling for Swift developers who are not doing their development on Apple platforms (e.g., good editor support potentially via the Language Server Protocol). This implies supporting Swift in a large number of existing editors and IDEs, and not necessarily creating a cross-platform one from whole cloth. Swift needs to be viable in the places and ways people are doing their development today.

  • Great low-level tooling support from the debugger, sanitizers, etc.

  • Powerful capabilities in the Swift Package Manager (and likely a package index) to empower developers to build and utilize a rich ecosystem of Swift libraries.

  • Rich documentation — hosted on a central place such as — to support Swift users on all platforms to get started with Swift and be productive.

  • Well-architected and maintained ways to distribute and install Swift, including installable packages for more Linux distributions, containers, and other platforms as Swift is ported to them (e.g., Windows).

  • Further facilities in the language to amplify the language’s provided toolset to address core programming tasks, such as a first-class concurrency model.

This thread has raised lots of interesting ideas, and it's great to see open discussion about potential paths forward. Everyone on this thread is excited to see Swift succeed as a cross-platform programming language. While there is a lot more to do to fully realize that aspiration, a lot of good stuff is already happening that we can build on:

  • Apple — and many others — continue to contribute to Linux and other cross-platform support via various efforts: the Swift Core Libraries, SwiftNIO, various Swift on Server frameworks, etc.

  • Engineering teams outside of Apple are pushing the Swift project forward in important ways beyond it being a great language for macOS/iOS app development. The Swift for TensorFlow effort is a great example.

  • The project is actively fostering development of Swift beyond just the concerns of Apple platforms in various ways such as the creation of the Forums with “Related Projects”, the community-hosted CI to extend the set of platforms tested, etc.

  • Apple is actively engaging in Swift conferences — organized by the broader community — to help foster engagement in open source development of Swift. The open source workshop at try Swift San Jose was also well-attended by Apple engineers as part of helping onboard more folks to contributing changes to Swift. These gatherings of the community are great opportunities for the open source community to push on increased collaboration on driving forward great cross-platform support for Swift.

Ultimately, the Swift project needs to have more contributors in many spaces to help drive Linux, Windows, and the various other aspects of Swift forward. Anyone interested in contributing but running into roadblocks are encouraged to ask for help on the Forums. It all comes down to people having the time, energy and focus to push Swift forward in small and large ways. Some of that energy will likely need to come from entities with engineering resources they want to commit to the project (e.g., Apple) but a lot of that can and should come from the general community.

One of the challenges we face as a community — which is possibly one of the key underlying concerns motivating this thread — is the need to better organize and harness the energy that's already in the project today and remove roadblocks for those who want to help. For example, I’ve often seen folks answering each others questions (e.g., how to get Swift building on a specific Linux distribution) on the forum threads; while it's great to see that, a really valuable next step would be to open a PR against the project’s documentation to incorporate that information so that it can benefit the broader community.

The best way for the project to make progress is to start with a clear understanding of what problems we need to solve as a community, and then look for ways to best support addressing them. The Core Team suggests starting with concrete discussions on how to achieve some of the most pressing pieces for a great cross-platform story, such as:

This isn't an exhaustive list of everything we need to talk about, but it seems like a good beginning. The Core Team will proceed with kicking off those threads.

NOTE: This post will later be edited to include links to those threads.

With regards to a non-profit organization ("Swift foundation") focused on supporting Swift, such an organization could potentially help with accelerating Swift’s greater success. Ultimately, however, the success of such an organization comes down to:

  1. Figuring out how that organization can best help with the challenges faced by the community.

  2. Having dedicated people with a vision to run that organization.

Opinions will vary on where such an organization could have the most impact. The Core Team feels that a non-profit organization could potentially help to foster development of the community, but is unlikely to be able to fund and support major engineering operations. Regardless of what it does, the organization would still need vision and stewardship on what problems to focus on addressing. That vision really needs to come from active participants in the community who are already motivated to focus on those problems.

The Core Team believes that — presently — the best investment from the community is to focus on meeting the near-term challenges we've talked about in this thread. By working together and harnessing the energy that already exists in the community, we can make a lot of progress and build momentum to address the longer-term problems. That will put us in a far better place to see and have a clear conversation about how organizational support, such as a non-profit, can best help further our shared goals as a project.


i don’t want to be annoying, but in the interest of getting real, concrete solutions to these problems implemented, do you or anyone you know know how to get around this issue with SourceKit? I asked a month ago and no one answered. It’s one of really two longstanding blockers in the way of getting Swift syntax highlighting working in the Atom editor (as well as any other editor that works in terms of 2D character grids, which i expect, is most of them.)

1 Like

I wasn't aware of that post. I've CC'ed some knowledgeable folks on that thread and have encouraged them to chime in.


One thing potentially relevant to this thread is the question:
Should the principle version of the swift repositories remain in Apple's GitHub?
If not, where else?
If so, for how long?

1 Like

Can you add a syntax highlighting grammar to that? LSP is only part of the issue. Editors that use LSP tend to rely on regular expressions for syntax highlighting. All editors I've tried so far have the same syntax highlighting issues, because no-one ever writes a proper one and just clones what's out there (and outdated). Having an official grammar that is updated when the language is updated would go a long way towards better syntax highlighting for Swift.


It looks like LSP is working towards including syntax highlighting, which would be convenient.

If SourceKit could be used to implement that part, that would be awesome indeed.

I'll admit to being slightly disappointed by that post.

The idea that the problems with Swift currently are not well-known seems weird to me. The problems are being discussed on this forum each and every day.

The way I interpret this thread and a lot of discussion that happened here is that there was an awareness of the problems but also the recognition that the amount of resources that are currently being invested in cross-platform Swift are not nearly enough. For example, the SPM seems to have basically a single contributor. In addition, the big problems that Swift currently has are often not things that are interesting to implement, but "boring" stuff like improving the Linux installation story, making it easier to compile the Swift toolchain, making the REPL more fully featured, etc., which is not something that many people like doing in their spare time (even less so if getting the Swift toolchain compiled is so hard in the first place).

Obviously, I'm in no place to make demands, Swift is free and everything, but as @svanimpe already pointed out: Swift is losing the fight for cross-platform developers. There is almost zero incentive for your run-of-the-mill webdev to choose Swift for their backend application, unless:
a) they're moving an existing mobile app onto the server,
b) they only know Swift and refuse to learn anything new

Maybe Apple is ok with Swift being iOS/macOS-only, that's fine, but if the stated goal is for Swift to be cross-platform, it's doing a bad job at this.


I agree 100% that the current investment of resources in cross-platform Swift are not sufficient to achieve the goals of Swift as a great cross-platform language. My post was not intended to belie that reality, and perhaps I should have said more to acknowledge that particular point. Your candid feedback and skepticism is very much appreciated. My intent is to do more here. The post is just a start.


Fair enough, then I might have misunderstood. Thanks for clarifying.

LSP doesn’t handle syntax highlighting, it’s a separate thing. LSP handles things like code completion and symbol lookup. I created atomic-blonde for Atom to solve the regex highlighting issue, though installing it is v problematic and probably won’t be resolved until Swift is in an official Ubuntu package repo (because it depends on the SourceKit .so lib that comes with the swift compiler, which can’t be reliably located). In theory SourceKit could be distributed with the highlighter, but the binary is well over 80 MB and exposes you to the problem where the highlighter might be highlighting for a different version of Swift than you are compiling with.

1 Like

Hi @taylorswift and @svanimpe,

Owensd had already made some work related to this topic.

With your we might already have all the basic pieces needed in order to move forward on this since most of libSyntax seems to be implemented .


@akyrtzi, @blangmuir and I have also been recently discussing offline LSP and evaluating potential strategies. We'll start a thread soon once we've put those thoughts in order; should be soon.


I forgot to add.

It could be great if was on a repository on its own and be available in SPM in order to simplify and broaden its usage.

Yes, this is the direction we want to go, see my comments here: Supporting SwiftSyntax on more targets

1 Like

Jetbrains just announced support for the swift package manager in CLion

They are moving faster than Apple


And still with Linux support! only Windows is missing, come on Apple !!!!!


Kotlin has such a Foundation now:


I'm so excited about this. I've been using AppCode all the while and will consider switching to CLion (hopefully they'll be able to migrate my subscription) if I find that the support works well.

Looks like a game changer to me.

1 Like

For some of us, it will be. I've been playing around with the Swift plugin for quite a while now, and the recent update is really big. There's a lot more improvements in there than just SPM support. There's a few issues remaining, but I'm hopeful.

I look forward to being able to teach Swift to my colleagues and students now that we have a proper IDE on Linux.

1 Like

I just tried it out a little. I noticed two issues:

a. if you have imported the project into AppCode before, it won't build and behave weirdly, see Deleting the .idea folder didn't help, so I just checked out the repo again and set it up newly for CLion, now it builds fine.
b. XCTest integration is a bit rudimentary. The output is just the standard swift test output, whereas it was much nicer in AppCode. Also, it doesn't seem like there is a way currently to run single tests.

But otherwise, I'm really excited about it. :slight_smile:

Terms of Service

Privacy Policy

Cookie Policy